Re: [TLS] Alternative ESNI?

[Viktor Dukhovni <[e-mail]>]

> On Dec 15, 2018, at 8:08 AM, Stephen Farrell <[e-mail]> wrote:
> 
> I don't see any point in considering the variant with the easy
> active attack though;

For the record the easy MiTM attack requires on-path TCP termination,
only discloses the SNI name, and the full handshake then fails.  It
looks to me like the same happens with the current draft when the
fronting key_share is not DNSSEC-validated.  And the attack on DNS
can be done cheaply at scale as we saw with the MyEtherWallet BGP
re-route back in April.

The present draft puts keys in DNS that for many site operators
will be difficult to rotate frequently, so there is a considerable
loss of forward-secrecy.  Absent DNSSEC, and even with DoH/DoT,
MiTM attacks are not precluded by the current draft.  The attacker
just has to compromise the traffic between the DoH/DoT recursive
resolver and the authoritative server.

Yes, if the same provider operates both of:

   * The user's selected DoH/DoT upstream DNS resolver
   * The authoritative DNS for the ultimate target domain

do we really want this much centralization?

> as ekr said, I think that was considered
> before and I'd say that'll just confuse matters and is better
> omitted, so I'm only really considering your figure 2 below.

It seems to me that in this space we can't realistically have
perfection, there are only trade-offs.  If we want the protected
domains to not stand out by being a tiny fraction of the traffic
to the fronted server, then low adoption barriers are essential
to getting any security here, MiTM or not.

Obviating the need to put server keys in DNS, and synchronize the
key shares across the server farm, ... IMHO does more to ensure
SNI privacy than an MiTM-resistant but more difficult to deploy
model.

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

For opportunistic discovery, yes also DNS, but the DNS record would
just hold a stable indication of support for the protocol.

  * It could be just a boolean, with the SNI name sent to the CDN
    being a well-known placeholder (but only in the case that we
    forgo authenticating the CDN and accept MiTM SNI disclosure).

  * It could be a list of fronting server names (similar to SRV) with
    the appropriate SNI name sent to each server, prior to switching
    to an encrypted SNI.  This supports multi-CDN deployments, but
    the load-balancing across CDNs is then handled client-side.

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

It could be a specially designated sentinel key_share algorithm, or
it could be an extension that solicits HRR.  If this proposal merits
further discussion, then we can get into the details, for now it is
perhaps best to consider the broad outline, and see whether that has
any merit.

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

Either is possible.

> - Given HRR was a kludge for backwards compatibility could changing
>  where that occurs in the protocol trigger more middlebox messes?

It could.  This would need to be explored.

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

Yes, it is not immediately obvious how/whether split mode works.
I've not given it much thought.  Presently just wanted to see
whether using ephemeral keying for ESNI is a viable alternative.

-- 
	Viktor.