search

cloudflare / tls-tris

crypto/tls, now with 100% more 1.3. THE API IS NOT STABLE AND DOCUMENTATION IS NOT GUARANTEED.
Other
291 stars 51 forks source link

Remove dependency on tls.Conn in key agreement abstraction #171

Closed Lekensteyn closed 5 years ago

Lekensteyn commented 5 years ago

The key agreement protocols only need a source of randomness for key generation and agreement (for KEM), and the role (client or server), so pass these explicitly.

Make keyAgreementClient and keyAgreementServer independent of the tls.Conn instance to allow reuse for ESNI.

In the TLS handshake, we have:

  1. Client generates an ephemeral private key and sends a derived public key share.
  2. Server takes this public key share, generates a new ephemeral private key, derives a shared secret and sends a derived public key share.
  3. Client uses its earlier private key to compute the same shared secret.

For ESNI, we have:

  1. Server generates a semi-static private key and publishes a derived public key share (say, in DNS).
  2. Client generates a new ephemeral private key, derives a shared secret and sends a derived public key share.
  3. Server uses its earlier private key to compute the shared secret.

As you can see the roles are reversed. It didn't seem correct to call keyAgreementClient as a server and vice versa. Neither am I sure if the "Alice" and "Bob" role should be reversed for SIDH. For ESNI I plan to support ECDHE only. The ecdheKex interface is adapted for the TLS handshake (with PQ support), but for ESNI, this interface will directly be used. The kex interface is maintained, instead keyAgreementXxx have been made independent of Conn. For ESNI I simply do not use the PQ algorithms, so the difference between keyAgreementClient/Server does not matter.

It is possible to specialize the "generate" method, for TLS it could receive "isClient" but in ECDHE there is no distinction so I could drop it. Thoughts?

Lekensteyn commented 5 years ago

Regarding your suggestion to split generate into generateClient/generateServer, I have decided to do that for now since it would either result in some more code duplication or a special if/else case in kexHybridSIDHp503X25519.generate. This can be done later if desired.

As for renaming "Client" -> "Initiator" (the party that generates a key share first) and "Server" -> "Responder" (the party that receives the key share first before generating a new key share and shared secret), I think it might be more confusing for the TLS handshake so I have decided against it. I'll just add a comment to the ESNI code.

kriskwiatkowski commented 5 years ago

LGTM