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

[Ilari Liusvaara <[e-mail]>]

On Sat, Nov 01, 2014 at 05:41:01AM -0400, Nikos Mavrogiannopoulos 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.

The only reason it is called TLS 1.3 ("SSL 3.4") is because we can't use TLS 2.0
designation ("SSL 4.0") on wire because of compatiblity reasons. :->


Regarding the most basic ways to secure long-term private keys (but most servers
don't do even that[1]), those are based on software that is rather easily
upgraded.


[1] Those would have easily stopped dumping of private keys via Heartbleed.

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

Presumably from ServerHello (with CKS being optimistic).

But the case where client misses all its guesses needs to be handled.
 
> > 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).

>From what I quickly read, the idea was to issue the parameters off EE
certificates, so that getting appropriate group is little problem.


However, this poses some challenges with respect to revocation. From what I
understand, the parameters are intended to have limited lifetime (much
shorter than EE certificates).

The reason this is problematic is that one can't really rely on clocks:
- Even if you happen to have sub-second accurate clock, a lot of computers don't.
- The time protocols often aren't secured, allowing attacker to play tricks
  with endpoint time.


-Ilari