Hiya, On 15/12/2018 20:00, Viktor Dukhovni wrote: > > >> On Dec 15, 2018, at 8:08 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> >> 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.
>
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
