Re: [TLS] Alternative ESNI?

[Stephen Farrell <[e-mail]>]

Hiya,

On 15/12/2018 20:00, Viktor Dukhovni wrote:
> 
> 
>> On Dec 15, 2018, at 8:08 AM, Stephen Farrell <[e-mail]> wrote:
>>e
>> 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.  

Yes. The significant difference though, for me, is that I can
see how to mitigate the attack in the case of the current draft
(deploy DNSSEC and/or DoH/DoT covering the bits of network about
which you're worried). Whereas the HRR scheme without the step
of authenticating the cover site inherently cannot have such a
mitigation as far as I can see.

Personally, I think that's a winning argument against the HRR
scheme with no cover-server authentication prior to exposing the
ESNI.

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

I agree that the current content specified for putting in the
DNS and the potential centralisation that may cause are both
undesirable.

I'm not convinced the HRR scheme is a better replacement. (But
I do think it is worth considering, as I said before.)

If browsers found one of the schemes attractive and the other
not, that'd I think be a winning argument - unfortunately, but
realistically, that'd win all arguments about trade-offs in
terms of potential for privacy improvement.

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

Isn't the easiest attack on ESNI then to just block visibility
of that boolean at which point a client will use SNI and not ESNI
and it's game-over? That seems to imply the HRR scheme isn't
any less dependent on DNS really, as I think ekr implied. (The
HRR scheme could be much nicer in terms of operating DNS, but not
more secure.)

Cheers,
S.

PS: Thanks for the other answers below, I think they're clear
enough.

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