Re: [TLS] OPTLS: Signature-less TLS 1.3

[Nikos Mavrogiannopoulos <[e-mail]>]

----- Original Message -----
> During the TLS interim meeting of last week (Oct 22 2014) I suggested that
> TLS
> 1.3 should abandon signature-based authentication (other than for
> certificates)
> and be based solely on a combination of ephemeral Diffie-Hellman for PFS and
> static Diffie-Hellman for authentication. This has multiple benefits
> including
> major performance gain (by replacing the per-handshake RSA signature by the
> server with a much cheaper elliptic curve exponentiation), compatibility
> with
> the mechanisms required for forward secrecy, natural accommodation of a
> 0-RTT
> option, and a simple extension without signatures for client authentication.

That effectively deprecates all existing infrastructure used for TLS that pretty
much only works with RSA and ECDSA certificates (from smart cards, to HSMs and
acceleration hardware). That's not necessarily bad, and we may already be past the
point where TLS 1.3 can be considered a minor revision of TLS 1.2.

> PROTOCOL OPTLS:
> 
> ClientHello
> ClientKeyShare
> ClientData* [K0]       -------->
>                                            ServerHello
>                                            ServerKeyShare
>                                            ServerCertificate* [K1]
>                                            ServerFinished [K2]
>                        <--------           ServerData* [K2]
> ClientFinished* [K2]   -------->
> 
> 
>             Protected Application Data [K3]
>                        <------->
> 1-RTT CASE:
> 
> The basic 1-RTT case omits the ClientData* field. It includes a
> ClientKeyShare
> g^x and a ServerKeyShare g^y and an optional (encrypted) server
> certificate.
> If the certificate is sent (it can be omitted if the client has indicated
> that
> it knows the server key as in the case in the 0-RTT scenario) and is
> encrypted,
> the encryption key K1 is derived from g^{xy}.
> 
> Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It is used
> to
> authenticate-encrypt the ServerFinished and ClientFinished messages (which
> include a hash of the previous traffic) and to encrypt data from the server
> if
> such data is piggybacked to the second message.

How does the client get the DH (or ECDH) group parameters used by the server?

> CLIENT AUTHENTICATION:
> 
> Client authentication can be supported via an option or extension. It would
> include a client certificate for a static DH key g^c sent in the third
> message
> (the certificate can be encrypted under key K2 to provide client's identity
> protection). In this case, the key for computing the ClientFinished message
> and
> the application key K3 would be derived from a combination of the values
> g^xy,
> g^xs, g^yc (and possibly also g^{cs}).

As I understand client authentication as above would only work if both the client
and the server share the same DH/ECDH group for their certificates, and that cannot
be assumed to be true on an infrastructure that is designed to upgrade (e.g., change
client certs from secp192r1 to secp256r1).

regards,
Nikos