[tor-dev] Proposal: Link Cryptographic Agility

[isis]

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?

-- 
 ♥Ⓐ isis agora lovecruft
_________________________________________________________
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
Current Keys: https://blog.patternsinthevoid.net/isis.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1240 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151116/ec0afd12/attachment.sig>