Hello,
There's been talk of moving to a wide block construct for cell crypto (#5460), and for adding PQ Forward Secrecy to traffic (#17272). To facilitate this, there needs to be a method for negotiating which primitives a given relay supports.
To that end, here's the begining of a proposal (tentatively #260) that adds a `CIPHERSUITES` cell to the version negotiation process which allows relays to advertise the link cryptography primitives that they are willing to accept.
TODOs/TBD:
* Should the new cell be variable length? Our development cycle and how often we switch handshakes/link crypto tells me "No", the existing "VERSIONS" cell format tells me "Yes".
* We need to revise prop. 249 to add a cell crypto method specifier to CREATE2V/EXTEND.
* Proposal 249 does not cover changing RELAY_EARLY behavior, which will potentially cause problems (Eg: Ring-LWE + ntor will require between 5 to 9 fragments depending on the exact primitives).
* The actual hybrid construct is deliberately left unspecified.
* With runtime negotiation of primitives on a per-circuit basis, we introduce the possibility of downgrade attacks. We do calculate the SHA256 digest of VERSIONS/CERTS/AUTH_CHALLENGE cells (which will become VERSIONS/CIPHERSUITES/CERTS/AUTH_CHALLENGE), so we could do something like:
auth_input = verify | ID | B | Y | X | SLOG | PROTOID | "Server"
Where SLOG is the digest without too much difficulty...
The alternative to all of this would be something like including handshake methods/supported link crypto in the descriptors, but that seems silly.
Regards,
Hey Yawning,
I'm generally in favour of merging this, but I'll wait a couple days to see if anyone has any feedback. Particularly, I'd like to hear if Nick has any comments.
Some brief comments/questions inline:
Yawning Angel transcribed 5.7K bytes:
Hello,
There's been talk of moving to a wide block construct for cell crypto (#5460), and for adding PQ Forward Secrecy to traffic (#17272). To facilitate this, there needs to be a method for negotiating which primitives a given relay supports.
To that end, here's the begining of a proposal (tentatively #260) that adds a `CIPHERSUITES` cell to the version negotiation process which allows relays to advertise the link cryptography primitives that they are willing to accept.
TODOs/TBD:
- Should the new cell be variable length? Our development cycle and how often we switch handshakes/link crypto tells me "No", the existing "VERSIONS" cell format tells me "Yes".
Given that we switch handshakes once in a blue moon, and generally try to deprecate the old protocol ASAP, it might be better to go with a fixed length?
- We need to revise prop. 249 to add a cell crypto method specifier to CREATE2V/EXTEND.
So that the client can coerce some choice of link cryptographic primitives for the entire circuit? Without advertisements of the supported primitives included somewhere in the relay descriptors (as you mentioned, below), won't this result in (at least for a while, and then again for a while each time a new primitive is introduced) increased circuit build failures?
- Proposal 249 does not cover changing RELAY_EARLY behavior, which will potentially cause problems (Eg: Ring-LWE + ntor will require between 5 to 9 fragments depending on the exact primitives).
What new behaviour do we need from RELAY_EARLY? If I understood prop#249 correctly, RELAY_EARLY should work as before (in particular with 8-9 total RELAY_EARLYs allowed per circuit construction), but that (potentially multipartite) EXTEND2(s) within RELAY_EARLY(s) should contain variable length authentication data. Are you just concerned that we'll go over the 8-9 cell limit and open ourselves back up to infinite circuit attacks? Or am I missing something?
The actual hybrid construct is deliberately left unspecified.
With runtime negotiation of primitives on a per-circuit basis, we introduce the possibility of downgrade attacks. We do calculate the SHA256 digest of VERSIONS/CERTS/AUTH_CHALLENGE cells (which will become VERSIONS/CIPHERSUITES/CERTS/AUTH_CHALLENGE), so we could do something like:
auth_input = verify | ID | B | Y | X | SLOG | PROTOID | "Server"
Where SLOG is the digest without too much difficulty...
This would require backwards-incompatible changes to the AUTHENTICATE cells currently in use by the ntor handshake, right? Are we prepared to wait three releases for the new changes to be available ubiquitously, or do we have some sooner timeline in mind for a PQ handshake?
On Mon, 16 Nov 2015 21:58:41 +0000 isis isis@torproject.org wrote:
Hey Yawning,
I'm generally in favour of merging this, but I'll wait a couple days to see if anyone has any feedback. Particularly, I'd like to hear if Nick has any comments.
I talked to Nick about this, and now think that adding a line or two to each microdescriptor probably is less painful. So no need to merge this.
What new behaviour do we need from RELAY_EARLY? If I understood prop#249 correctly, RELAY_EARLY should work as before (in particular with 8-9 total RELAY_EARLYs allowed per circuit construction), but that (potentially multipartite) EXTEND2(s) within RELAY_EARLY(s) should contain variable length authentication data. Are you just concerned that we'll go over the 8-9 cell limit and open ourselves back up to infinite circuit attacks? Or am I missing something?
Since this is an orthogonal issue... Until the changes that Nick added to #249 last night, RELAY_EARLY behavior was unspecified for fragmented EXTEND cells. The pedantic interpretation could have been "all fragments must be contained in RELAY_EARLY", which wouldn't let you build circuits consisting of more than 1 hop.
Since only the first fragment needs to be in RELAY_EARLY now, there's no further issues.
I'm gonna poke at some other things (in particular I'm multithreading the rest of our circuit build crypto) for a bit before I come back to this, but I have a rough idea of what I want our PQ options to look like.
Regards,
-
isis -
Yawning Angel