EIP-8: devp2p Forward Compatibility Requirements for Homestead #49

Merged
merged 2 commits into from Feb 19, 2016

Conversation

Projects
None yet
5 participants
@fjl
Contributor

fjl commented Dec 24, 2015

This is the first Networking EIP, in which I am trying to sneak some changes
into all implementations before the Homestead release. These changes should
make network protocol upgrades a lot easier in the future.

Merry 馃巹 everyone.

@fjl fjl referenced this pull request in ethereum/go-ethereum Dec 24, 2015

Merged

rlp, p2p, p2p/discover: EIP-8 changes #2091

EIPS/EIP-8.md
+packets. If the remote hello packet contains a version greater than the current local
+version, the implementation should reply with a hello packet containing the local (lower)
+version. Implementations should also ignore any additional list elements at the end of the
+hello packet.

This comment has been minimized.

@karalabe

karalabe Dec 29, 2015

Member

Aren't the hello packets being sent out immediately as the connection is established? Also not sure about it, but AFAIK there are no ordering guarantees between who sends such a packet first or second, so I don't really see a way to send the lower of the two, if both sides have to wait for the remote one to figure out the correct version.

Edit: Perhaps you meant not that they should reply with the lowest, but rather that they should use the lowest version throughout the communication?

@karalabe

karalabe Dec 29, 2015

Member

Aren't the hello packets being sent out immediately as the connection is established? Also not sure about it, but AFAIK there are no ordering guarantees between who sends such a packet first or second, so I don't really see a way to send the lower of the two, if both sides have to wait for the remote one to figure out the correct version.

Edit: Perhaps you meant not that they should reply with the lowest, but rather that they should use the lowest version throughout the communication?

This comment has been minimized.

@subtly

subtly Dec 31, 2015

Member

Agree this requires clarification and that neither side should wait on the other side to send their version and either side can choose to disconnect or continue communication if the version is different. The proposed specifications are ambiguous because they state that either side can do what they want. This can be simplified to:

  • Once a secure connection is established a Hello packet or Disconnect packet MUST be sent
  • The hello packet MUST contain the highest version supported by the client
@subtly

subtly Dec 31, 2015

Member

Agree this requires clarification and that neither side should wait on the other side to send their version and either side can choose to disconnect or continue communication if the version is different. The proposed specifications are ambiguous because they state that either side can do what they want. This can be simplified to:

  • Once a secure connection is established a Hello packet or Disconnect packet MUST be sent
  • The hello packet MUST contain the highest version supported by the client

This comment has been minimized.

@fjl

fjl Dec 31, 2015

Contributor

I will clarify this in the text, it was definitely not meant to imply that implementations should wait for the remote hello packet.

@fjl

fjl Dec 31, 2015

Contributor

I will clarify this in the text, it was definitely not meant to imply that implementations should wait for the remote hello packet.

EIPS/EIP-8.md
+I propose the following changes to the handshake packets:
+
+* Adding the length of the ciphertext as a plaintext header.
+* Encoding the body of the handshake as RLP.

This comment has been minimized.

@karalabe

karalabe Dec 29, 2015

Member

I'm not familiar with the cryptographic consequences here, but using RLP for encoding the body of the handshake would lead to an attacker knowing a few bytes of the clear-text data, namely the schema of the RLP encoding itself.

Given that the encoded fields are fixed sized ones, an attacker could know for sure the position and value of the length encodings in the cleartext, which could weaken the encryption a bit. I'm not familiar enough with te primitives though to say whether this is acceptable or not.

@karalabe

karalabe Dec 29, 2015

Member

I'm not familiar with the cryptographic consequences here, but using RLP for encoding the body of the handshake would lead to an attacker knowing a few bytes of the clear-text data, namely the schema of the RLP encoding itself.

Given that the encoded fields are fixed sized ones, an attacker could know for sure the position and value of the length encodings in the cleartext, which could weaken the encryption a bit. I'm not familiar enough with te primitives though to say whether this is acceptable or not.

This comment has been minimized.

@wanderer

wanderer Dec 31, 2015

Member

that and we don't really need RLP here. RLP is good for when there is an variable length array but the handshake is always the same. It would be more efficient just to do section size + section.

@wanderer

wanderer Dec 31, 2015

Member

that and we don't really need RLP here. RLP is good for when there is an variable length array but the handshake is always the same. It would be more efficient just to do section size + section.

This comment has been minimized.

@subtly

subtly Dec 31, 2015

Member

@karalabe @wanderer I think RLP is better than DER and it gives us more flexibility than fixed-length without adding too much complexity. Specifically, RLP is helpful for future upgrades and future features.

@subtly

subtly Dec 31, 2015

Member

@karalabe @wanderer I think RLP is better than DER and it gives us more flexibility than fixed-length without adding too much complexity. Specifically, RLP is helpful for future upgrades and future features.

This comment has been minimized.

@fjl

fjl Dec 31, 2015

Contributor

The initial packet is encrypted using AES, which is not known to be vulnerable to known plaintext attacks.

RLP is suggested here because it can carry more structure than a simple length-value scheme.
For example, a future version of the handshake could carry the devp2p hello packet and/or arbitrary protocol-specific metadata to reduce the number of round trips.

@fjl

fjl Dec 31, 2015

Contributor

The initial packet is encrypted using AES, which is not known to be vulnerable to known plaintext attacks.

RLP is suggested here because it can carry more structure than a simple length-value scheme.
For example, a future version of the handshake could carry the devp2p hello packet and/or arbitrary protocol-specific metadata to reduce the number of round trips.

EIPS/EIP-8.md
+```
+
+Implementations may choose to add a random amount of bytes to vary the size of the packet.
+Doing so helps prevent statistical traffic classification.

This comment has been minimized.

@karalabe

karalabe Dec 29, 2015

Member

If the handshake is prefixed with the length of the cipher-text, isn't that already leaking enough information to allow statistical classification? I.e. a single TCP frame containing exactly the same amount of random data that was specified by the first N bytes?

@karalabe

karalabe Dec 29, 2015

Member

If the handshake is prefixed with the length of the cipher-text, isn't that already leaking enough information to allow statistical classification? I.e. a single TCP frame containing exactly the same amount of random data that was specified by the first N bytes?

This comment has been minimized.

@subtly

subtly Dec 31, 2015

Member

@karalabe Yes 鈥 although I'm not a trained cryptanalyst like others whom I've worked with on rlpx. The ciphertext will always be at least N bytes, so over time, the fact that the value is greater than N and rest is random leaks information. If the value is cleartext it can also be reliably manipulated which can create other problems; flipping a few bits to increase the value would cause a longer read which results in timing out the connection.

<3 that I was able to sync up and send eth transactions from several locations where I couldn't use github.

@subtly

subtly Dec 31, 2015

Member

@karalabe Yes 鈥 although I'm not a trained cryptanalyst like others whom I've worked with on rlpx. The ciphertext will always be at least N bytes, so over time, the fact that the value is greater than N and rest is random leaks information. If the value is cleartext it can also be reliably manipulated which can create other problems; flipping a few bits to increase the value would cause a longer read which results in timing out the connection.

<3 that I was able to sync up and send eth transactions from several locations where I couldn't use github.

This comment has been minimized.

@fjl

fjl Jan 1, 2016

Contributor

I would like to note that an earlier draft of EIP-8 encoded the length prefix as:

size-mask = sha3(recipient-pubk[:4] || enc-auth-msg[:16])[:2]
auth-size-masked = xor(size-mask, auth-size)

I played around with a few variations of this idea (omitting the public key, etc.) and concluded that the complexity isn't worth it. Such masking schemes can become a strong indicator themselves or leak peer identities. Statistical classification these days can differentiate based on inter-packet timing, to the point where Tor traffic can be detected even though it masquerades as HTTPS. We won't win against such attempts, whether we mask the size or not.

The issue that @karalabe mentioned is a valid concern, but one could argue that the (admittedly weak) protection against traffic classification is merely a side effect. Padding the handshake is required for another reason (see a few lines further up in the EIP document), if anything this is defense-in-depth. I will change the sentence to say "helps prevent signature-based traffic classification".

Given that the size of the handshake plaintext is randomly padded, the length prefix does not leak information about the plaintext. This is what matters.

Side note: TLS, ZRTP and other encrypted protocols include version number and length as plaintext fields.

flipping a few bits to increase the value would cause a longer read which results in timing out the connection.

A (privileged) attacker wishing to fail connection attempts has other means to do so: flipping any bit of the handshake packet is sufficient to invalidate its MAC.

The 16bit length prefix allows for up to ~64kB of handshake data. With todays connection speeds, it is unlikely that anyone will run into a timeout even if the maximum amount of data is actually used for a valid purpose.

@fjl

fjl Jan 1, 2016

Contributor

I would like to note that an earlier draft of EIP-8 encoded the length prefix as:

size-mask = sha3(recipient-pubk[:4] || enc-auth-msg[:16])[:2]
auth-size-masked = xor(size-mask, auth-size)

I played around with a few variations of this idea (omitting the public key, etc.) and concluded that the complexity isn't worth it. Such masking schemes can become a strong indicator themselves or leak peer identities. Statistical classification these days can differentiate based on inter-packet timing, to the point where Tor traffic can be detected even though it masquerades as HTTPS. We won't win against such attempts, whether we mask the size or not.

The issue that @karalabe mentioned is a valid concern, but one could argue that the (admittedly weak) protection against traffic classification is merely a side effect. Padding the handshake is required for another reason (see a few lines further up in the EIP document), if anything this is defense-in-depth. I will change the sentence to say "helps prevent signature-based traffic classification".

Given that the size of the handshake plaintext is randomly padded, the length prefix does not leak information about the plaintext. This is what matters.

Side note: TLS, ZRTP and other encrypted protocols include version number and length as plaintext fields.

flipping a few bits to increase the value would cause a longer read which results in timing out the connection.

A (privileged) attacker wishing to fail connection attempts has other means to do so: flipping any bit of the handshake packet is sufficient to invalidate its MAC.

The 16bit length prefix allows for up to ~64kB of handshake data. With todays connection speeds, it is unlikely that anyone will run into a timeout even if the maximum amount of data is actually used for a valid purpose.

This comment has been minimized.

@subtly

subtly Jan 1, 2016

Member

I played around with a few variations of this idea (omitting the public key, etc.) and concluded that the complexity isn't worth it.

I believe zero knowledge proofs would be useful here however its too soon and I don't think there are libraries which implement ZK proofs in a generally usable way.

to the point where Tor traffic can be detected even though it masquerades as HTTPS. We won't win against such attempts, whether we mask the size or not.

Tor can be detected by statistical classification because there isn't a source for entropy or robust multiplexing and tor doesn't wish to address the problem (I've spoken to 3 of their devs about this). TL;DR it's out of scope for Tor.

I've known about statistical classification systems since 2006, have worked with netflow systems, and a patent for a signal classification system, thus...

"We won't win".

...is nonsense. It's Science :) Research, writing code and not compromising on design principles.

Side note: TLS, ZRTP and other encrypted protocols include version number and length as plaintext fields.

They also send public key and certs in plaintext. I spoke with an author of SSL and they simply didn't get to build what they wanted, and they didn't have the strong guarantees of cryptography which we have today. There's complete agreement that plaintext is bad.

@subtly

subtly Jan 1, 2016

Member

I played around with a few variations of this idea (omitting the public key, etc.) and concluded that the complexity isn't worth it.

I believe zero knowledge proofs would be useful here however its too soon and I don't think there are libraries which implement ZK proofs in a generally usable way.

to the point where Tor traffic can be detected even though it masquerades as HTTPS. We won't win against such attempts, whether we mask the size or not.

Tor can be detected by statistical classification because there isn't a source for entropy or robust multiplexing and tor doesn't wish to address the problem (I've spoken to 3 of their devs about this). TL;DR it's out of scope for Tor.

I've known about statistical classification systems since 2006, have worked with netflow systems, and a patent for a signal classification system, thus...

"We won't win".

...is nonsense. It's Science :) Research, writing code and not compromising on design principles.

Side note: TLS, ZRTP and other encrypted protocols include version number and length as plaintext fields.

They also send public key and certs in plaintext. I spoke with an author of SSL and they simply didn't get to build what they wanted, and they didn't have the strong guarantees of cryptography which we have today. There's complete agreement that plaintext is bad.

@karalabe

This comment has been minimized.

Show comment
Hide comment
@karalabe

karalabe Dec 29, 2015

Member

In my opinion the proposal is solid apart from the RLP encoding question I've raised above. That should be looked at by someone more capable in cryptography.

I would however like to emphasize that this would be a very high priority feature to get into the Homestead fork, as the protocol in it's current state is not upgradable without a hard fork. There are issues with the current protocol already, and as time progresses I'm certain we'll find plenty more, or simply much needed extensions that cannot be implemented due to the forking requirements.

The most important aspect IMHO about the solution proposed by Felix is that it's extremely simple. It could be added to any implementation in a matter of minutes, which is imho worth doing now and paving the way forward to easier upgrades afterwards.

The upgrade mechanism itself is quite crude as any version bump requires adding fields to the end, no fields can be deleted or semantically changed (to keep backwards compatibility), but as we're not aiming to do many updates, just to facilitate occasional essential ones, I think this is fine. And as we're transitioning through metropolis and serenity, we can take the lessons learned from previous updates and refine/clean in each of these hard forks.

Best case scenario we can seamlessly upgrade the devp2p protocol as need arises, worst case scenario we don't use the upgrade mechanism, but it won't hinder anything either.

Member

karalabe commented Dec 29, 2015

In my opinion the proposal is solid apart from the RLP encoding question I've raised above. That should be looked at by someone more capable in cryptography.

I would however like to emphasize that this would be a very high priority feature to get into the Homestead fork, as the protocol in it's current state is not upgradable without a hard fork. There are issues with the current protocol already, and as time progresses I'm certain we'll find plenty more, or simply much needed extensions that cannot be implemented due to the forking requirements.

The most important aspect IMHO about the solution proposed by Felix is that it's extremely simple. It could be added to any implementation in a matter of minutes, which is imho worth doing now and paving the way forward to easier upgrades afterwards.

The upgrade mechanism itself is quite crude as any version bump requires adding fields to the end, no fields can be deleted or semantically changed (to keep backwards compatibility), but as we're not aiming to do many updates, just to facilitate occasional essential ones, I think this is fine. And as we're transitioning through metropolis and serenity, we can take the lessons learned from previous updates and refine/clean in each of these hard forks.

Best case scenario we can seamlessly upgrade the devp2p protocol as need arises, worst case scenario we don't use the upgrade mechanism, but it won't hinder anything either.

EIPS/EIP-8.md
+version. Implementations should also ignore any additional list elements at the end of the
+hello packet.
+
+Similarly, implementations of the RLPx Discovery Protocol should ignore the version number

This comment has been minimized.

@subtly

subtly Dec 31, 2015

Member

Can be simplified to:

  • RLPx UDP packets with unknown type should be ignored

Why the specification to ignore additional list elements?

The version number in Ping/Pong packets shouldn't be ignored. It is to be cached and/or checked against existing metadata and maybe further verified as a compatible version following encrypted handshake.

@subtly

subtly Dec 31, 2015

Member

Can be simplified to:

  • RLPx UDP packets with unknown type should be ignored

Why the specification to ignore additional list elements?

The version number in Ping/Pong packets shouldn't be ignored. It is to be cached and/or checked against existing metadata and maybe further verified as a compatible version following encrypted handshake.

This comment has been minimized.

@fjl

fjl Dec 31, 2015

Contributor

I will clarify this too. "Ignore" may suggest that the version number should be discarded, which is not the intended meaning. It is simply meant to say that nodes with mismatching version should still be included in the discovery table.

The bit about additional list elements allows for backwards-compatible upgrades in the same manner as for the devp2p hello packet: If any packet is extended to include more information in a later version of the protocol, older nodes will simply ignore these elements.

@fjl

fjl Dec 31, 2015

Contributor

I will clarify this too. "Ignore" may suggest that the version number should be discarded, which is not the intended meaning. It is simply meant to say that nodes with mismatching version should still be included in the discovery table.

The bit about additional list elements allows for backwards-compatible upgrades in the same manner as for the devp2p hello packet: If any packet is extended to include more information in a later version of the protocol, older nodes will simply ignore these elements.

This comment has been minimized.

@subtly

subtly Jan 1, 2016

Member

Can this be a nested tuple? Something like:

auth-body     = rlp.list(auth-vsn, rlp.list(sig, initiator-pubk, initiator-nonce OR token))

Thus:

  • The first item in auth-body will always be VERSION
  • The second item in auth-body will always be a list for HANDSHAKE (3 items)

Notably, any extensions would need to be very strict to ensure they aren't introducing plaintext elements.

@subtly

subtly Jan 1, 2016

Member

Can this be a nested tuple? Something like:

auth-body     = rlp.list(auth-vsn, rlp.list(sig, initiator-pubk, initiator-nonce OR token))

Thus:

  • The first item in auth-body will always be VERSION
  • The second item in auth-body will always be a list for HANDSHAKE (3 items)

Notably, any extensions would need to be very strict to ensure they aren't introducing plaintext elements.

@wanderer

This comment has been minimized.

Show comment
Hide comment
@wanderer

wanderer Dec 31, 2015

Member

Currently the id's are 64 bytes. Can we change them 32 bytes (a compressed public key)?

Member

wanderer commented Dec 31, 2015

Currently the id's are 64 bytes. Can we change them 32 bytes (a compressed public key)?

EIPS/EIP-8.md
+
+I propose the following changes to the handshake packets:
+
+* Adding the length of the ciphertext as a plaintext header.

This comment has been minimized.

@subtly

subtly Dec 31, 2015

Member

No plaintext. The problem with this is that the length will always be greater than X, and likely equal to X, so it can be inferred that the connection is rlpx. Leaking information (aka plaintext) is not within the design rationale of RLPx or any encrypted protocol.

@subtly

subtly Dec 31, 2015

Member

No plaintext. The problem with this is that the length will always be greater than X, and likely equal to X, so it can be inferred that the connection is rlpx. Leaking information (aka plaintext) is not within the design rationale of RLPx or any encrypted protocol.

This comment has been minimized.

@fjl

fjl Jan 1, 2016

Contributor
EIPS/EIP-8.md
+
+* Adding the length of the ciphertext as a plaintext header.
+* Encoding the body of the handshake as RLP.
+* Adding a version number to both packets in place of the token flag (unused).

This comment has been minimized.

@subtly

subtly Dec 31, 2015

Member

The token flag will be used, don't remove it! Just because it isn't used doesn't mean it isn't a priority. It isn't used now because other issues are a higher priority and need to be resolved first.

@subtly

subtly Dec 31, 2015

Member

The token flag will be used, don't remove it! Just because it isn't used doesn't mean it isn't a priority. It isn't used now because other issues are a higher priority and need to be resolved first.

This comment has been minimized.

@fjl

fjl Dec 31, 2015

Contributor

Adding the token feature (if it ever happens) will incur a version bump. The flag value can be added back into the list at that time.

@fjl

fjl Dec 31, 2015

Contributor

Adding the token feature (if it ever happens) will incur a version bump. The flag value can be added back into the list at that time.

This comment has been minimized.

@subtly

subtly Jan 1, 2016

Member

Its happened! I need to be able to use it now (as soon as I can implement it).

@subtly

subtly Jan 1, 2016

Member

Its happened! I need to be able to use it now (as soon as I can implement it).

EIPS/EIP-8.md
+* Adding the length of the ciphertext as a plaintext header.
+* Encoding the body of the handshake as RLP.
+* Adding a version number to both packets in place of the token flag (unused).
+* Removing the hash of the ephemeral public key (it is redundant).

This comment has been minimized.

@subtly

subtly Dec 31, 2015

Member

+1

@subtly

This comment has been minimized.

Show comment
Hide comment
@subtly

subtly Jan 1, 2016

Member

@karalabe If homestead is a hard-fork I think we should just fix the protocol. A design rationale behind RLPx is that communication MUST NOT rely on the authentication handshake for metadata, and that metadata is to be exchanged via discovery. The solution is so simple: Try to connect to the node via discovery first! This way both sides will authenticate what version they know they can speak before attempting the handshake 鈥 its also easy to write a discovery (UDP) stack which supports multiple versions. Case in point, a peer cannot connect to a node prior to discovery 鈥撀燼s discovery is how the public key is obtained. No discovery == no TCP handshake.

Member

subtly commented Jan 1, 2016

@karalabe If homestead is a hard-fork I think we should just fix the protocol. A design rationale behind RLPx is that communication MUST NOT rely on the authentication handshake for metadata, and that metadata is to be exchanged via discovery. The solution is so simple: Try to connect to the node via discovery first! This way both sides will authenticate what version they know they can speak before attempting the handshake 鈥 its also easy to write a discovery (UDP) stack which supports multiple versions. Case in point, a peer cannot connect to a node prior to discovery 鈥撀燼s discovery is how the public key is obtained. No discovery == no TCP handshake.

@subtly

This comment has been minimized.

Show comment
Hide comment
@subtly

subtly Jan 1, 2016

Member

@karalabe @fjl @wanderer

For the handshake, what do we need to consider other than the scenarios below?

Node AAA, Version 1
Node FFF, Version 2

Scenario 1: Node AAA(v1) attempts connecting to FFF(v2)
Scenario 2: Node FFF(v2) attempts connecting to AAA(v1)

Note: This upgrade is more complex than it seems. The necessity of this upgrade is in order to fix the way the KDF used and to enable framing. Ideally we also remove AES padding. What this means is that if new clients are to support old clients they will need to be able to enable the new framing system on a per-session.

Member

subtly commented Jan 1, 2016

@karalabe @fjl @wanderer

For the handshake, what do we need to consider other than the scenarios below?

Node AAA, Version 1
Node FFF, Version 2

Scenario 1: Node AAA(v1) attempts connecting to FFF(v2)
Scenario 2: Node FFF(v2) attempts connecting to AAA(v1)

Note: This upgrade is more complex than it seems. The necessity of this upgrade is in order to fix the way the KDF used and to enable framing. Ideally we also remove AES padding. What this means is that if new clients are to support old clients they will need to be able to enable the new framing system on a per-session.

@wanderer

This comment has been minimized.

Show comment
Hide comment
@wanderer

wanderer Jan 4, 2016

Member

@subtly I'm not planning on supporting backwards compatibility.

Member

wanderer commented Jan 4, 2016

@subtly I'm not planning on supporting backwards compatibility.

@fjl

This comment has been minimized.

Show comment
Hide comment
@fjl

fjl Jan 4, 2016

Contributor

And that's fine. You can always drop connections with lower version (the EIP doc explicitly permits this).

Contributor

fjl commented Jan 4, 2016

And that's fine. You can always drop connections with lower version (the EIP doc explicitly permits this).

@fjl

This comment has been minimized.

Show comment
Hide comment
@fjl

fjl Jan 9, 2016

Contributor

Test vectors have been added.

Contributor

fjl commented Jan 9, 2016

Test vectors have been added.

@fjl

This comment has been minimized.

Show comment
Hide comment
@fjl

fjl Jan 9, 2016

Contributor

@subtly (aggregating our discussion a bit)

Your concerns about the RLPx handshake changes seem to be:

  • Adding plaintext of any form is bad. I agree that plaintext that leaks secrets is bad, but the size of the handshake is not a secret.
  • The size prefix makes identifying RLPx TCP connections easy. My take on it is that the fixed size handshake is just as recognizable and that randomizing the length offers adequate protection in most cases.
  • The handshake should not carry metadata, it should be communicated through discovery instead. The issue with this is that discovery isn't always available (e.g. when connecting through Tor). We are also planning to offer discovery over RLPx/TCP in the near future, in which case the RLPx handshake is the entry point.
  • It requires a backwards-compatible implementation for the RLPx v5 KDF changes. If you don't care about backwards-compatibility, you can refuse communication with older nodes. The change merely shifts responsibility so the newer node is in control about this decision.
Contributor

fjl commented Jan 9, 2016

@subtly (aggregating our discussion a bit)

Your concerns about the RLPx handshake changes seem to be:

  • Adding plaintext of any form is bad. I agree that plaintext that leaks secrets is bad, but the size of the handshake is not a secret.
  • The size prefix makes identifying RLPx TCP connections easy. My take on it is that the fixed size handshake is just as recognizable and that randomizing the length offers adequate protection in most cases.
  • The handshake should not carry metadata, it should be communicated through discovery instead. The issue with this is that discovery isn't always available (e.g. when connecting through Tor). We are also planning to offer discovery over RLPx/TCP in the near future, in which case the RLPx handshake is the entry point.
  • It requires a backwards-compatible implementation for the RLPx v5 KDF changes. If you don't care about backwards-compatibility, you can refuse communication with older nodes. The change merely shifts responsibility so the newer node is in control about this decision.
@Gustav-Simonsson

This comment has been minimized.

Show comment
Hide comment
@Gustav-Simonsson

Gustav-Simonsson Jan 24, 2016

Member

After discussing with @fjl and @nagydani I think we need to write up a spec of exact requirements of RLPx in terms of threat models - what attacks are we interested in defending against right now, and which can we leave for future protocol upgrades. It's hard to have a discussion of details such as leaking plaintext and/or ciphertext length without having consensus on threat models & general reqs.

Member

Gustav-Simonsson commented Jan 24, 2016

After discussing with @fjl and @nagydani I think we need to write up a spec of exact requirements of RLPx in terms of threat models - what attacks are we interested in defending against right now, and which can we leave for future protocol upgrades. It's hard to have a discussion of details such as leaking plaintext and/or ciphertext length without having consensus on threat models & general reqs.

@fjl

This comment has been minimized.

Show comment
Hide comment
@fjl

fjl Feb 1, 2016

Contributor

For anyone following this discussion: A lot has happened. We've had multiple long calls about EIP-8, a counterproposal and a rebuttal of the counterproposal have been written.

I've updated the text of EIP-8 to clarify some things. Notably, Postel's Law is now mentioned because it
might not be so obvious that it is at play here. A new Rationale section on the discovery change has been added, and there is now a section exploring the implications of the plaintext size prefix for the handshake packets.

Contributor

fjl commented Feb 1, 2016

For anyone following this discussion: A lot has happened. We've had multiple long calls about EIP-8, a counterproposal and a rebuttal of the counterproposal have been written.

I've updated the text of EIP-8 to clarify some things. Notably, Postel's Law is now mentioned because it
might not be so obvious that it is at play here. A new Rationale section on the discovery change has been added, and there is now a section exploring the implications of the plaintext size prefix for the handshake packets.

@wanderer

This comment has been minimized.

Show comment
Hide comment
@wanderer

wanderer Feb 1, 2016

Member

However, such an attacker can also be expected to read and or participate in RLPx Discovery traffic, in which case effective blocking is possible irrespective of the size prefix.

So I think in that case the discovery traffic wouldn't be UDP. It could be by written notes sent by pigeons, ect. But the point is just because the normal method for discovery is blocked the transport can still operate.

Member

wanderer commented Feb 1, 2016

However, such an attacker can also be expected to read and or participate in RLPx Discovery traffic, in which case effective blocking is possible irrespective of the size prefix.

So I think in that case the discovery traffic wouldn't be UDP. It could be by written notes sent by pigeons, ect. But the point is just because the normal method for discovery is blocked the transport can still operate.

@fjl

This comment has been minimized.

Show comment
Hide comment
@fjl

fjl Feb 1, 2016

Contributor

The document assumes nodes talking using the currently specified protocols, not a version where arbitrary transport is negotiated using an arbitrary method of discovery. Not sure whether this needs to be made explicit. We can improve on everything in the future, but for the RLPx protocol that is in use right now, correlating UDP traffic is definitely possible (and there are other indicators, including commonly used ports, the fixed-size handshake traffic pattern, the first byte always being 0x04, etc.).
I guess what I'm trying to say is that the prefix won't make things worse than they are now.

Contributor

fjl commented Feb 1, 2016

The document assumes nodes talking using the currently specified protocols, not a version where arbitrary transport is negotiated using an arbitrary method of discovery. Not sure whether this needs to be made explicit. We can improve on everything in the future, but for the RLPx protocol that is in use right now, correlating UDP traffic is definitely possible (and there are other indicators, including commonly used ports, the fixed-size handshake traffic pattern, the first byte always being 0x04, etc.).
I guess what I'm trying to say is that the prefix won't make things worse than they are now.

@wanderer

This comment has been minimized.

Show comment
Hide comment
@wanderer

wanderer Feb 1, 2016

Member

The document assumes nodes talking using the currently specified protocols, not a version where arbitrary transport is negotiated using an arbitrary method of discovery

I think I have a slightly different view here. I view the three protocols (discovery, handshake, transport) as being mutually independent and composable.

Member

wanderer commented Feb 1, 2016

The document assumes nodes talking using the currently specified protocols, not a version where arbitrary transport is negotiated using an arbitrary method of discovery

I think I have a slightly different view here. I view the three protocols (discovery, handshake, transport) as being mutually independent and composable.

@fjl

This comment has been minimized.

Show comment
Hide comment
@fjl

fjl Feb 2, 2016

Contributor

This is my abstract view, too, but when discussing the possibility of filtering RLPx v4 TCP connections
we need to look at what people actually use. There are two choices for users now: using UDP discovery or supplying the pubkey+endpoint. There won't be a third option just tomorrow, unless we implement it (or use a library for it ;)) and it gets adopted.

Contributor

fjl commented Feb 2, 2016

This is my abstract view, too, but when discussing the possibility of filtering RLPx v4 TCP connections
we need to look at what people actually use. There are two choices for users now: using UDP discovery or supplying the pubkey+endpoint. There won't be a third option just tomorrow, unless we implement it (or use a library for it ;)) and it gets adopted.

@fjl

This comment has been minimized.

Show comment
Hide comment
@fjl

fjl Feb 2, 2016

Contributor

Anyway, I've fixed up the sentence to state explicitly that TCP connections could be blocked by looking at UDP traffic, which was the intended meaning.

Contributor

fjl commented Feb 2, 2016

Anyway, I've fixed up the sentence to state explicitly that TCP connections could be blocked by looking at UDP traffic, which was the intended meaning.

@fjl

This comment has been minimized.

Show comment
Hide comment
@fjl

fjl Feb 2, 2016

Contributor

Another short overview document (as requested by @chriseth): https://gist.github.com/6c6d24dc1c7ab5d77c5c

Contributor

fjl commented Feb 2, 2016

Another short overview document (as requested by @chriseth): https://gist.github.com/6c6d24dc1c7ab5d77c5c

@fjl

This comment has been minimized.

Show comment
Hide comment
@fjl

fjl Feb 3, 2016

Contributor

Note: test vectors need to be regenerated for the size prefix authentication change. I'll do that and then squash all the commits together.

Contributor

fjl commented Feb 3, 2016

Note: test vectors need to be regenerated for the size prefix authentication change. I'll do that and then squash all the commits together.

@arkpar arkpar referenced this pull request in paritytech/parity Feb 4, 2016

Closed

EIP-8 (RLPx changes for homestead) #349

@fjl

This comment has been minimized.

Show comment
Hide comment
@fjl

fjl Feb 9, 2016

Contributor

Test vectors are now up to date.

Contributor

fjl commented Feb 9, 2016

Test vectors are now up to date.

@fjl

This comment has been minimized.

Show comment
Hide comment
@fjl

fjl Feb 17, 2016

Contributor

Squashed.

Contributor

fjl commented Feb 17, 2016

Squashed.

@karalabe

This comment has been minimized.

Show comment
Hide comment
@karalabe

karalabe Feb 18, 2016

Member

Could we get this merged into the EIP repo if it was accepted for homestead? (Also specify it as "Accepted"?)

Member

karalabe commented Feb 18, 2016

Could we get this merged into the EIP repo if it was accepted for homestead? (Also specify it as "Accepted"?)

@wanderer

This comment has been minimized.

Show comment
Hide comment
@wanderer

wanderer Feb 18, 2016

Member

@karalabe yes definitely! @fjl could change the status to "accepted" on this? It would b ready to merge then

Member

wanderer commented Feb 18, 2016

@karalabe yes definitely! @fjl could change the status to "accepted" on this? It would b ready to merge then

@fjl

This comment has been minimized.

Show comment
Hide comment
@fjl

fjl Feb 18, 2016

Contributor

Done.

Contributor

fjl commented Feb 18, 2016

Done.

wanderer added a commit that referenced this pull request Feb 19, 2016

Merge pull request #49 from fjl/EIP-8
EIP-8: devp2p Forward Compatibility Requirements for Homestead

@wanderer wanderer merged commit 2c9a53e into ethereum:master Feb 19, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment