Re: [TLS] Alternative ESNI?

[Nico Williams <[e-mail]>]

On Fri, Dec 14, 2018 at 08:53:47PM -0600, Nico Williams wrote:
>              Figure 1: Alternative ESNI w/o active protection

Figure 1 was expositional.  Please forget it.

>               Figure 2: Alternative ESNI w/ active protection


>              Figure 3: Alternative ESNI w/ active protection,
>                           with worst-case latency

There's a different way to do the third case _without_ an extra round
trip in the worst case.  Now there are no cases with worse latency than
the worst latency in RFC 8446.

This is the case where the client's initial key_share is not acceptable
to the server.

The key observation is that we can send the server's Certificate and
CertificateVerify in the clear when they are for the fronting name,
which means we can authenticate the server in the first flight, which
means that we can have handshake traffic keys in the second flight:


        ClientHello
        + key_share             -------->
                                                        ServerHello
                                                        + key_share
                                                        Certificate
                                                  CertificateVerify
                                <--------         HelloRetryRequest
        ClientHello
        + key_share
        {EncryptedExtensions}   -------->
                                              {EncryptedExtensions}
                                              {CertificateRequest*}
                                                      {Certificate}
                                                {CertificateVerify}
                                                         {Finished}
                                <--------       [Application Data*]
        {Certificate*}
        {CertificateVerify*}
        {Finished}              -------->
        [Application Data]      <------->        [Application Data]

             Figure 4: Like figure #2 but with initial client
               key_share that is unacceptable to the server


Note that the server's Certificate and CertificateVerify goes
unencrypted.  Why?  Well, it is the Certificate for the *fronting*
name, the one that went unencrypted in the ClientHello, so it doesn't
really need protection.

As Stephen Farrell points out, we get to have *two* server key_shares,
one from the SH and one from the HRR, which gives us the opportunity to
have one of them be something of a static key share shared with a
traffic director.  So we get to have *two* sets of handshake traffic
keys, one that gives a traffic director visibility, and one that does
not.

Do we ever need confidentiality protection relative to the traffic
director?  If so we'll need notation for indicating which handshake
traffic key set to use for what encrypted extensions.

Nico
--