On Sat, Dec 15, 2018 at 01:08:50PM +0000, Stephen Farrell wrote:
> On 15/12/2018 02:53, Nico Williams wrote:
> > OpenSSL extracts and uses SNI from session resumption tickets.
> >
> > This gave Viktor Dukhovni and Matt Caswell an idea that I'll relay here
> > on their behalf.
>
> I agree this is worth exploring, though am not sure if it'd be
> better in the end. (I chatted with Viktor about this and said
> I'd try see if I could make it work once I've gotten further
> along coding up the current draft.)
Perhaps this alternative ESNI protocol can complement the current ESNI
proposal.
The idea would be to allow sites that cannot orchestrate ESNI keyshares
across multiple CDNs to opt for this alternative by publishing in DNS
only the fronting domainname(s). Only then would one pay the extra
round trip price to get ESNI, and only if the client wants it (but the
client should want it).
A client that finds a domain's fronting domain but not ESNI keys would
engage in the active attack resistant variant I posted with the fronting
domainname as the public SNI, and the server would know to respond with
the HRR.
The key is that we need to be able to deploy an ESNI protocol widely and
easily, but if ESNI keyshare orchestration is a big brake on deployment,
then it might take a long time to get traction.
(Note that I never said that DoH/DPRIV would not be needed. The
alternative would allow simple manual, local configuration, whereas
publishing ESNI keyshares does not.)
> I don't see any point in considering the variant with the easy
> active attack though; as ekr said, I think that was considered
Agreed. I included it mostly to show how we got to the one that is
resistant to active attacks. I thought it'd be useful to do that, but
instead it seems to have given everyone something bad to latch onto :(
> before and I'd say that'll just confuse matters and is better
> omitted, so I'm only really considering your figure 2 below.
I agree.
> > ClientHello
> > + key_share -------->
> > ServerHello
> > + key_share
> > {EncryptedExtensions*}
> > {Certificate}
> > {CertificateVerify}
> > <-------- {HelloRetryRequest}
> > ClientHello
> > + key_share
> > {EncryptedExtensions} -------->
> > {EncryptedExtensions}
> > {CertificateRequest*}
> > {Certificate}
> > {CertificateVerify}
> > {Finished}
> > <-------- [Application Data*]
> > {Certificate*}
> > {CertificateVerify*}
> > {Finished} -------->
> > [Application Data] <-------> [Application Data]
> >
> > Figure 2: Alternative ESNI w/ active protection
> >
>
> Some questions:
>
> - How are you proposing the client knows of the existence of the
> hidden service? (Aside from local configuration, which is always
> possible.)
DNS (DPRIV, DoH).
Local config isn't really possible if it means the user has to type in
keyshares.
> - How does the server know to include the HRR in it's answers? (IOW,
> what ESNI signal is present in the client's 1st flight?
The client uses the fronting domainname as the public SNI payload. The
server, knowing via local configuration that it has no ESNI keyshares in
DNS, responds with the HRR as above.
> - Ought that be some more general signal? e,g. "client wants to send
> some EncryptedExtensions, let's do an extra RTT." (I'd like that
> I think, but the counter argument might be that that's overreach
> and we'd be better to just stick with an ESNI model that we're
> confident can get some deployment.)
Yes and no. In order to get ESNI widely adopted it will probably help
to have a way to trigger this denies the censors an unambiguous "pst,
hey, let's do this thing so the censors don't know your name" signal.
But for that I would think that yes, we'd want a general signal about
this.
> - Given HRR was a kludge for backwards compatibility could changing
> where that occurs in the protocol trigger more middlebox messes?
Dunno.
> - This seems like supporting the split mode behaviour [1] could be a
> lot more complex, as this scheme is more embedded in the h/s. Is
> that fair? (Note: I'm not sure the split mode is really easy in
> any circumstances though, so that mightn't be a killer argument.)
See above, and below.
Maybe we do both, the current ESNI proposal and this as an alternative
for when ESNI keyshare orchestration is difficult, and in that case you
don't get to do split mode.
> - In tls1.3 the HRR has an accompanying key_share, if pursuing this
> further I'd say you'd want to consider whether or not that is
> better to include. (That is, your server's first flight above has
> a SH and then HRR but only one key_share - it might be better to
> have a key_share in each, and that might even enable a more
> tractable split mode model if the cover server could handoff the
> rest of the h/s after that maybe.)
Ohhh, nice! That's brilliant! One of the keyshares (the HRR's) could
be the one shared with the middlebox for split mode. The client would
derive two sets of handshake traffic keys then. (If split mode is not
used then the HRR can have the same keyshare as the SH, then only one
set of handshake traffic keys need be derived. In encrypted extensions
we'd need to identify which key was used -- maybe, the recipient can
always try decrypting with both keys.)
Nico
--
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
