On Wed, Feb 13, 2019 at 6:24 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> On 13/02/2019 23:55, David Benjamin wrote: > > On Wed, Feb 13, 2019 at 5:00 PM Stephen Farrell < > stephen.farr...@cs.tcd.ie> > > wrote: > > That text isn't prescribing any particular behavior. > > Then delete it:-) > It's just describing > > the effect the rest of the text has on "trusted MITM proxies" and the > like. > > Disagree. "Just describing" does not match the use of a meaningless > marketing term like "trusted blah proxy" sorry. Better to avoid all > that fuss really, no? > > > Note this is specifically about "MITM proxies" which control a root > > certificate that the client is configured to trust. I will refrain from > > commenting on whether this deployment model is at all wise, but it does > > exist (antivirus, etc). The text itself is just an updated version of > > existing bits here: > > https://tools.ietf.org/html/draft-ietf-tls-esni-02#section-6.2 > > I don't recall that having a concept of it being possible to > "correctly" implement breaking the TLS protocol? (As is inherent > in being an MITM.) > > > > > As for where this effect comes from, it's a consequence of the rollback > and > > partial deployment robustness mechanism in the PR: > > > >> If the server negotiates an earlier version of TLS, or if it does not > >> provide an "encrypted_server_name" extension in EncryptedExtensions, the > >> client proceeds with the handshake, verifying the certificate against > >> ESNIKeys.public_name as described in {{verify-public-name}}. The client > > MUST > >> NOT enable the False Start optimization {{RFC7918}}. If the handshake > > completes > >> successfully, the client MUST abort the connection with an > > "esni_required" alert. > >> It then SHOULD retry the handshake with a new transport connection and > > ESNI > >> disabled." > > > > Or, in other words, IF the server is able to speak authoritatively for > the > > public name (relatively to the client's trust anchors) but appears to not > > understand ESNI at all, that is a signal to the client that ESNI got > turned > > off or hasn't fully been turned on yet. ESNI involves client state and, > > without this, it's risky for a server operator to deploy ESNI. > Deployments > > are complex systems, and complex systems react to change unpredictably. > For > > most changes, if some show-stopping problem is found, it is safe to > > rollback the change. For instance, clients naturally tolerate servers > > turning TLS 1.3 on and off, a fact I'm sure every early adopter of TLS > 1.3 > > has used many times. ESNI, a priori, breaks this property. The intent of > > this text is to restore it, without totally breaking it (the stop signal > is > > authenticated under the public name, the same standard this PR sets for > > replacing the key). > > It may be ok to live with such fallback whilst ESNI is being > introduced but I think ongoing support for it would be unwise. > And such a fallback requires no discussion of MITM attacks. > (Other than as an attack.) > > > > > It turns out that a user moving in and out of one of these "trusted > MITMs" > > I object to that term again, sorry:-) It's marketing meaninglessness. > I have been using air quotes for a reason... :-P My personal view on these things is very far from positive. The intent was simply to update the existing text talking about this same scenario ("A more serious problem is MITM proxies [...] The client can detect this case and disable ESNI while in that network configuration"). In so far as it made sense for the original document to talk about this, among the many complex compatibility considerations in ESNI, I think it continues to makes sense for the PR to do so. That said, you have a good point about the word "correct". I was using that just to invert the existing sentence which begins "A non-conformant MITM proxy [...]", but you are right that the phrasing in the PR has different implications. I need to go through the comments on GitHub and update the PR. In doing so, I will also take another stab at wordsmithing this. Hopefully I can come up with something less objectionable. > > I'm guessing you're referring to this? > > > >> Note that verifying a connection for the public name does not verify it > > for the > >> origin. The TLS implementation MUST NOT surface such connections as > > successful to > >> the application. > > > > That just says you can't report it as successful. > > "MUST NOT surface" seems like bad phrasing then. > I'm blanking on better wording. I wanted to keep the wording independent of whether your TLS stack knows how to open transport connections or not, which changes things a bunch, which constrained things a bit. Any thoughts? > > Is there any reason not to just do it in every ClientHello? > > I'd guess that some implementers may be put off by the > wasted bandwidth. Others won't care but if it's the case > that sending a bogus ESNI x% of the time gets as good a > result as sending all the time (which is how I interpret > what the SHOULD calls for) then it seems better to encourage > x% and not 100%. > When Chrome sends GREASE extensions today, we do it unconditionally on all ClientHellos. I think x% doesn't give a great result. Then implementation bugs get papered over with some probability on retry. The world is full of transparent retries, so this is a poor enforcement of protocol invariants. But, in terms of interop, nothing goes wrong if you choose not to send it sometimes (maybe you're doing a field trial, I dunno). Hence SHOULD, not MUST. >> - Padding to 260 is IIRC the max that works. A CH with such > >> padding is ~600 bytes. Seems like a waste of bytes to me and > >> it could stick out depending on real ESNI padding_lengths. > >> Maybe consider something like "pad to a length that matches > >> recent traffic" and leave it to clients to figure out what > >> might stick out less. (I'm not sure every server will ask > >> for padding to 260 as CF do;-) > >> > > > 260 comes from elsewhere which says: > > > >> The length to pad the ServerNameList value to prior to encryption. > >> This value SHOULD be set to the largest ServerNameList the server > >> expects to support rounded up the nearest multiple of 16. If the > >> server supports wildcard names, it SHOULD set this value to 260. > > Yeah, and I disagree with that too:-) > > > I figured that assuming, by default, that the server supports wildcard > > names seemed reasonable so the text mirrored the other SHOULD. Though > maybe > > that's a bit much? I don't have strong feelings here. What do you think > the > > text should say? Perhaps it should pick a random multiple-of-16 length > > between 64 and 260? Or maybe we should decrease the wildcard value... a > > 260-byte SNI name is kind of excessive, honestly. > > Regardless of the above disagreement about 260, if a client has > been sending a bunch of CH's including real ESNI that are about > 400 bytes because some server's ESNIKeys says to pad to 160, and > that client then sends 600 bytes CH's to everyone else, I think > it'd be crystal clear which is grease and which not. > This is precisely why client and server recommendations should align. It sounds like you believe that the server recommendation of 260 is too much. I would support a change to that (together with a matching client change). What do you think it should say instead? I don't think "pad to a length that matches recent traffic" works well because that adds a bit of correlation between multiple services. It's a minor correlation, but such things still aren't great for privacy and doesn't seem worth adding here. I certainly would not want to implement such a thing. I'm fine with recommending a fixed value, or picking randomly within a range. Beyond that, I think the problem should be solved at both recommendations together. David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
