kytv/I2P_Website
1
0
Fork 0
forked from I2P_Developers/i2p.www
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

proposal 123 updates

Browse Source
This commit is contained in:
zzz
2018-08-06 21:48:47 +00:00
parent dce84f7b9e
commit 3c0863f2ed
1 changed files with 184 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files

226
i2p2www/spec/proposals/123-new-netdb-entries.rst
View File

@ -5,7 +5,7 @@ New netDB Entries
:author: zzz
:created: 2016-01-16
:thread: http://zzz.i2p/topics/2051
:lastupdated: 2017-11-12
:lastupdated: 2018-08-06
:status: Open
:supercedes: 110, 120, 121, 122
@ -66,25 +66,57 @@ Types 2-4 may be returned in response to a standard leaseset lookup (type 1).
Type 5 is never returned in response to a lookup.
Types 6 is returned in response to a new service lookup type (type 2).
Only type 2 may be sent in a client-to-client Garlic message.
Format
------
Types 2-5 all have a common format::
Types 2, 4, and 5 all have a common format::
Standard LS2 Header
- as defined below
Type-Specific Part
- as defined below in each part
Standard LS2 Signature:
- Length as implied by sig type of signing key
Type 3 (Encrypted) does not start with a Destination and has a
different format. See below.
Type 6 (Service List) is an aggregation of several Service Records and has a
different format. See below.
Standard LS2 Header
===================
Types 2, 4, and 5 use the standard LS2 header, specified below:
Format
``````
::
Standard LS2 Header:
- Destination (387+ bytes)
- Published timestamp (8 bytes)
- Expires (4 bytes) (offset from published in ms)
- Flags (2 bytes) (see details for each type below)
- Flags (2 bytes)
Bit order: 15 14 ... 3 2 1 0
Bit 0: If 0, no offline keys; if 1, offline keys
Other bits: set to 0 for compatibility with future uses
- If flag indicates offline keys:
Transient sig type (2 bytes)
Transient signing public key (length as implied by sig type)
Signature of transient sig type and public key, by the destination public key,
length as implied by destination public key sig type
Type-Specific Part
- as defined below
Standard LS2 Signature:
- Signature (40+ bytes)
Type 6 (Service List) is an aggregation of several Service Records and has a
different format. See below.
New DatabaseEntry types
@ -104,6 +136,8 @@ Lookup with:
Standard LS flag (1)
Store with:
Standard LS2 type (2)
Store at:
Hash of destination, with daily rotation, as for LS 1
Typical expiration:
10 minutes, as in a regular LS.
Published by:
@ -113,11 +147,7 @@ Format
``````
::
Standard LS2 Header:
- Destination (387+ bytes)
- Published timestamp (8 bytes)
- Expires (4 bytes) (offset from published in ms)
- Flags (2 bytes)
Standard LS2 Header as specified above
Standard LS2 Type-Specific Part
- Encryption type (2 bytes)
@ -127,7 +157,10 @@ Format
- Properties (2 bytes if none)
Standard LS2 Signature:
- Signature (40+ bytes)
- Signature
If flag indicates offline keys, this is signed by the transient pubkey, otherwise, by the destination pubkey
Length as implied by sig type of signing key
Flag definition::
@ -205,6 +238,22 @@ Notes
Encrypted LS2
-------------
Goals:
- Add blinding
- Allow multiple sig types
- Don't require any new crypto primitives
- Optionally encrypt to each recipient, revokable
- Support encryption of Standard LS2 and Meta LS2 only
Encrypted LS2 is never sent in an end-to-end garlic message.
Use the standard LS2 as above.
You can't use a b32 for an encrypted LS2, as you don't have the non-blinded public key.
We need a new "b33" format, or use one of the four unused bits at the end of b32 to indicate it's blinded.
You can't use an encrypted LS2 for bittorrent, because of compact announce replies.
Changes from existing encrypted LeaseSet:
- Encrypt the whole thing for security
@ -215,33 +264,66 @@ Lookup with:
Standard LS flag (1)
Store with:
Encrypted LS2 type (3)
Store at:
Hash of blinded sig type and public key, with daily rotation
Typical expiration:
10 minutes, as in a regular LS.
Published by:
Destination
Format
``````
Note that encrypted LS2 is blinded. The Destination is not in the header.
DHT storage location is SHA-256(sig type || blinded public key), and rotated daily.
Blinding is only defined for Ed25519 signing keys (sig type 7).
Blinding is rougly as specified in Tor's rend-spec-v3 appendices A.1 and A.2.
Exact specification including KDF is TBD.
::
Standard LS2 Header:
- Destination (387+ bytes)
- Blinded Public Key Sig Type (2 bytes)
- Blinded Public Key (length as implied by sig type)
- Signature of destination by blinded public key?
- Published timestamp (8 bytes)
- Expires (4 bytes) (offset from published in ms)
- Flags (2 bytes)
Encrypted LS2 Type-Specific Part
- Length of encrypted data (2 bytes)
- Encrypted data
Format TBD and application-specific.
When decrypted, the LS2 Type-Specific part
Standard LS2 Signature:
- Signature (40+ bytes)
Bit order: 15 14 ... 3 2 1 0
Bit 0: If 0, no offline keys; if 1, offline keys
Other bits: set to 0 for compatibility with future uses
- If flag indicates offline keys:
Transient sig type (2 bytes)
Transient signing public key (length as implied by sig type)
Signature of transient sig type and public key, by the destination public key,
length as implied by destination public key sig type
- Length of IV + encrypted data (2 bytes)
- IV (8 bytes)
- Outer Encrypted data (AEAD ChaCha/Poly1305)
Published timestamp is the nonce
Do we need HMAC or ChaCha only? Probably don't need HMAC, everything is signed.
KDF TBD, uses Destination
When decrypted, contains:
1) Flag - per-client or for everybody? (1 byte)
If per-client, 2) and 3) are present.
2) number of recipients to follow (2 bytes)
3) that many entries of [id_i, iv_i, Encrypted cookie]
where the recipient looks for his ID, then decrypts the inner.
The same cookie is encrypted once for each recipient.
Length of each field TBD.
KDF and encryption for cookie TBD.
- Inner Encrypted data (AEAD ChaCha/Poly1305)
Published timestamp is the nonce
Do we need HMAC or ChaCha only? Probably don't need HMAC, everything is signed.
KDF TBD. Used blinded public key. Uses cookie also if per-client.
When decrypted, the data for type 2 or 4, including the header,
but without the timestamp and expires fields?
- Signature (by blinded public key, length as implied by blinded sig type)
Flags: for future use
The signature is of everything above, i.e. the encrypted data.
The signature is of everything above.
Notes
`````
@ -267,43 +349,87 @@ Notes
- Floodfills may limit the max size to a reasonable value to prevent abuse.
Meta LS2
--------
This is used to replace multihoming. Like any leaseset, this is signed by the
creator. This is an authenticated list of destination hashes.
The Meta LS2 is the top of, and possibly intermediate nodes of,
a tree structure.
It contains a number of entries, each pointing to a LS, LS2, or another Meta LS2
to support massive multihoming.
A Meta LS2 may contain a mix of LS, LS2, and Meta LS2 entries.
The leaves of the tree are always a LS or LS2.
The tree is a DAG; loops are prohibited; clients doing lookups must detect and
refuse to follow loops.
A Meta LS2 may have a much longer expiration than a standard LS or LS2.
The top level may have an expiration hours or days after the publication date.
Maximum expiration time will be enforced by floodfills and clients, and is TBD.
The use case for Meta LS2 is massive multihoming, but with no more
protection for correlation of routers to leasesets (at router restart time) than
is provided now with LS or LS2.
This is equivalent to the "facebook" use case, which probably doesn't need
correlation protection. This use case probably needs offline keys,
which are provided in the standard header at each node of the tree.
The back-end protocol for coordination between the leaf routers, intermediate and master Meta LS signers
is not specified here. The requirements are extremely simple - just verify that the peer is up,
and publish a new LS every few hours. The only complexity is for picking new
publishers for the top-level or intermediate-level Meta LSes on failure.
Mix-and-match leasesets where leases from multiple routers are combined, signed, and published
in a single leaseset is documented in proposal 140, "invisible multihoming".
This proposal is untenable as written, because streaming connections would not be
"sticky" to a single router, see http://zzz.ip2/topics/2335 .
The back-end protocol, and interaction with router and client internals, would be
quite complex for invisible multihoming.
To avoid overloading the floodfill for the top-level Meta LS, the expiration should
be several hours at least. Clients must cache the top-level Meta LS, and persist
it across restarts if unexpired.
We need to define some algorithm for clients to traverse the tree, including fallbacks,
so that the usage is dispersed. Some function of hash distance and cost.
If a node has both LS or LS2 and Meta LS, we need to know when it's allowed
to use those leasesets, and when to keep traversing the tree.
Lookup with:
Standard LS flag (1)
Store with:
Meta LS2 type (4)
Store at:
Hash of destination, with daily rotation, as for LS 1
Typical expiration:
Hours to days
Hours to days. Max TBD.
Published by:
"master" Destination or coordinator
"master" Destination or coordinator, or intermediate coordinators
Format
``````
::
Standard LS2 Header:
- Destination (387+ bytes)
- Published timestamp (8 bytes)
- Expires (4 bytes) (offset from published in ms)
- Flags (2 bytes)
Standard LS2 Header as specified above
Meta LS2 Type-Specific Part
- Number of entries (1 byte)
- Number of entries (1 byte) Maximum TBD
- Entries. Each entry contains: (39 bytes)
- Hash (32 bytes)
- Flags (2 bytes)
TBD. Set all to zero for compatibility with future uses.
- Expires (4 bytes) (offset from published in ms)
- Cost (priority) (1 byte)
- Number of revocations (1 byte)
- Number of revocations (1 byte) Maximum TBD
- Revocations: Each revocation contains: (32 bytes)
- Hash (32 bytes)
@ -314,6 +440,7 @@ Format
Flags and properties: for future use
Notes
`````
- A distributed service using this would have one or more "masters" with the
@ -344,6 +471,8 @@ Lookup with:
n/a, see Service List
Store with:
Service Record type (5)
Store at:
Hash of service name, with daily rotation
Typical expiration:
Hours
Published by:
@ -353,11 +482,7 @@ Format
``````
::
Standard LS2 Header:
- Destination (387+ bytes)
- Published timestamp (8 bytes)
- Expires (4 bytes) (offset from published in ms, all zeros for revocation)
- Flags (2 bytes)
Standard LS2 Header as specified above
Service Record Type-Specific Part
- Port (2 bytes) (0 if unspecified)
@ -377,6 +502,10 @@ Notes
limit the number of records stored per hash and their expiration. A whilelist
of hashes may also be used.
- Any other netdb type at the same hash has priority, so a service record can never
overwrite a LS/RI, but a LS/RI will overwrite all service records at that hash.
Service List
------------
@ -391,10 +520,23 @@ A Service List contains Short Service Records, not full Service Records. These
contain signatures but only hashes, not full destinations, so they cannot be
verified without the full destination.
The security, if any, and desirability of service lists is TBD.
Floodfills could limit publication, and lookups, to a whitelist of services,
but that whitelist may vary based on implementation, or operator preference.
It may not be possible to achieve consensus on a common, base whitelist
across implementations.
If the service name is included in the service record above,
then floodfill operators may object; if only the hash is included,
there's no verification, and a service record could "get in" ahead of
any other netdb type and get stored in the floodfill.
Lookup with:
Service List lookup type (2)
Store with:
Service List type (6)
Store at:
Hash of service name, with daily rotation
Typical expiration:
Hours, not specified in the list itself, up to local policy
Published by:
@ -406,7 +548,7 @@ Format
- Hash of the service name (implicit, in the Database Store message)
- Hash of the Creator (floodfill) (32 bytes)
- Timestamp (8 bytes)
- Published timestamp (8 bytes)
- Number of Short Service Records (1 byte)
- List of Short Service Records: