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

[Eric Rescorla <[e-mail]>]

On Thu, Oct 10, 2019 at 11:59 AM Rob Sayre <[e-mail]> wrote:

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

What are you anticipating the server would do with the SNI? Ordinarily we
expect the host header to be used for host identification purposes.

-Ekr


> thanks,
> Rob
>