Thanks for the comments! Responses inline. On Wed, Feb 13, 2019 at 5:00 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > Hiya, > > On 13/02/2019 22:15, Christopher Wood wrote: > > > > > > [1] https://github.com/tlswg/draft-ietf-tls-esni/pull/124 > > I just re-read that. I've a question: why tie the version > change to this PR and not the I-D rev? I'd prefer if we > make the change to 0xff02 when -03 is published. (I don't > care which PR does that, but wouldn't like to see every > PR bump that number.) > I bumped it because the PR was making a wire-incompatible change, but batching them up to I-D revs makes sense too. No preferences here. (Spec editors, do you care? I can remove that part of the change.) > Aside from that I think it's ok (though I may find other > issues when implementing later) with two caveats that can > be handled now or later: > > 1. The DNS RR structure still needs fixing but that is likely > better handled separately. (By "fixing" I mean a new RR type > but also that it needs to be designed for DNS admins as well > and not only for TLS implementers which is the current case. > (I'm not saying what might or might not make it more dnsops > friendly, just that that needs to be checked/done sometime.) > I'm guessing this is to do with the various discussions around multi-CDN and whatnot? That seems orthogonal to that PR. (I don't personally have particularly strong opinions or experience there.) > 2. I don't think the text below ought be included, it's not > the job of this WG to design MITM attacks. (Or maybe I've > misinterpreted it?) > > "The public name, however, makes this protocol compatible with > deployments that use correctly-implemented MITM proxies. If the > client has cached an ESNIKey for the origin server, the MITM > proxy will process the cleartext SNI field and terminate a > connection to the public name instead. If the client is > configured to trust the proxy's certificate, it will accept > the connection as valid for the public name and retry with > ESNI disabled." > That text isn't prescribing any particular behavior. It's just describing the effect the rest of the text has on "trusted MITM proxies" and the like. 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 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 turns out that a user moving in and out of one of these "trusted MITMs" looks the same as a rollback, so we get robustness to that scenario too. The current draft attempted to handle this case too, but did so with extra machinery. From the link above: > A Web client client can securely detect case (2) because it will > result in a connection which has an invalid identity (most likely) > but which is signed by a certificate which does not chain to a > publicly known trust anchor. The client can detect this case and > disable ESNI while in that network configuration Here, there is no name check, so any publicly known root that the client trusts can be used to trigger that fallback, even if it's just, say, an intranet server and not a MITM proxy. The PR fixes this by checking the public name. It only counts as a signal if the server can speak for the service's public name, not any arbitrary name. I also don't think I'd implement that fallback in my openssl > fork. Earlier text says to complete the h/s but to not make > that visible to the application layer and the above seems to > conflict with that. I could hold my nose were that in -03 as it > has no effect really, but I'll whine about it later for sure;-) > 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. Whether you report it to the application at all depends on your API shape. For a low-level TLS library that doesn't create transport connections, I'm envisioning it report failure with a special error code, which higher-level logic can interpret as a retry. (This is how we handle 0-RTT rejects in BoringSSL. 0-RTT rejects affect connection usage, such as if you thought you were speaking HTTP/2, but the server rejected and then negotiated HTTP/1.1. It's ultimately a very funny retry.) For higher-level code that knows how to make transport connections, one option then is for the retry to be handled more transparently. > > [2] https://github.com/tlswg/draft-ietf-tls-esni/pull/125 > > I like this one. But the "SHOULD send" and "MUST pad to 260" > seem a bit OTT to me, though I could live with 'em for now. > So consider these nits, not objections: > (260 is just a SHOULD rather than a MUST. More below.) > - Rather than "SHOULD send", it may be better to say something > like "SHOULD frequently send" and leave it to clients to decide > how often to grease. Wouldn't that have the same effect? > Is there any reason not to just do it in every ClientHello? > - Maybe add that even TLS1.3 clients that don't really do ESNI > MAY grease ESNI? (A bit weird but hey why not?:-) > Indeed! The PR currently says: > If the client attempts to connect to a server and does not have an ESNIKeys > structure available for the server, Knowing what ESNI is but not really doing it I think counts as "does not have an ESNIKeys structure available". Do you think it should be called out more explicitly? > - 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. 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. David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
