Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.txt)

[Rob Sayre <[e-mail]>]

On Fri, Oct 11, 2019 at 1:45 AM Eric Rescorla <[e-mail]> wrote:

>
> OK, I think we've now reached where we are talking past each other.
>
> At a very high level, here's the TLS 1.3 handshake:
>
> C->S: CH (w/ SNI)
> S->C: SH, CERT, CV, FIN
> C->S: [CERT, CV], FIN
>
> In order for the server to send the certificate, which, as you can see, is
> in its first flight, it has to have the SNI available.
>

I think this is the disconnect. The situation you describe is common
(sharing an IPv4 address), and I definitely understand why the SNI needs to
be in the ClientHello in that situation.


> This means that it has to go in the client's first flight. But the
> client's certificate is in the client's second flight. And the client has
> to have the server's certificate before it sends its certificate, because
> otherwise it can't authenticate the server and so an active attacker can
> get the client's cert.
>
> If you still disagree, maybe you could show me the ladder diagram you have
> in mind?
>

The ladder diagram I have in mind is exactly as described in the TLS 1.3
RFC. Assume that the server can't send application data on its first
flight, and that the client must send a certificate on its second flight.

Then, assume that useful data can be transmitted in subdomain labels to a
server that has issued a wildcard certificate.

thanks,
Rob