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

[Hugo Krawczyk <[e-mail]>]

The issues regarding group matching (and mis-matching) raised here and
discussed
in other messages are indeed very important. In the case of server-only
authentication this reduces to the client guessing the right g^x and thus
requires dealing with wrong guesses (this only applies to the 1-RTT case as
in
the 0-RTT case the client learns the group together with the server's static
key g^s). In the mutual authentication case, if server and client cannot
agree
on using the same group for authentication, then the client would need to
choose its g^x in the server's group while authentication by the client
would
require the server to send an additional ServerKeyShare in the client's
group.
Note, however, that in the use case where the parties have certificates for
signature keys and they sign their own static DH key, clients and servers
can
possess static DH keys in different groups (without requiring a CA-issued
certificate for each such group), hence more easily support the peer's
group.

Hugo



On Sat, Nov 1, 2014 at 11:41 AM, Nikos Mavrogiannopoulos <[e-mail]>
wrote:

> ----- 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
>