On Thu, Oct 10, 2019 at 11:19 AM Rob Sayre <say...@gmail.com> wrote: > > > On Fri, Oct 11, 2019 at 1:08 AM Eric Rescorla <e...@rtfm.com> wrote: > >> >> >> On Wed, Oct 9, 2019 at 10:16 PM Rob Sayre <say...@gmail.com> wrote: >> >>> On Wed, Oct 9, 2019 at 8:06 PM Eric Rescorla <e...@rtfm.com> wrote: >>> >>>> >>>>> I don't think that's quite what I'm proposing. I'm proposing >>>>> (optionally) sending the SNI with a client certificate. >>>>> >>>> >>>> What are you trying to accomplish by doing that? >>>> >>> >>> I want to keep the SNI encrypted in TLS hops that use client >>> certificates, but where ESNI won't work. >>> >>> For example, how is the SNI transmitted in the parens here: >>> >>> [ Client ] -----> (ESNI) -----> [ CDN ] -----> (???) -----> [ Origin ] >>> >>> I don't think a DNS-based solution like ESNI will work for that second >>> hop, because the origin tends to be identified by an IP address rather than >>> a domain name. >>> >> >> I feel like we're perhaps talking past each other, so I'm going to start >> back at the beginning. >> >> In the ordinary case of Client -> Origin or Client -> CDN, the SNI >> principally serves to tell the server which origin the client wants and >> thus which certificate to serve. For this reason, it has to go in the CH. >> > > In general, I agree with you. But only because client certificates are > relatively rare for end users. >
> If a client certificate is required, the server probably can't send > application data in its first response. > 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. 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? -Ekr > >> >> In the case of CDN -> Origin, it seems like SNI could serve the same >> purpose (say that the origin server is hosting multiple servers), in which >> case it seems like the same requirements apply. OTOH, if the origin server >> just hosts one origin, then you could potentially have the SNI delivered >> later (as you suggest), but then why have SNI delivered at all? >> > > Two reasons: > > 1) the SNI could contain subdomain data, like "username.example.com" > 2) if there is a client certificate, the SNI might be relevant in deciding > whether to accept it > > I understand that the intermediary (CDN, etc) will be able to observe the > SNI, but it's not clear why it's ok that any passive observer to the origin > should be able to. > > thanks, > Rob > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
