Hiya, On 17/12/2018 23:17, David Benjamin wrote: > Hi folks, > > We[*] wrote up some proposed changes for draft-ietf-tls-esni that we'd like > the group's thoughts on. The goal is to make ESNI more robust and eliminate > a bunch of deployment risks. The PRs are linked below: > > https://github.com/tlswg/draft-ietf-tls-esni/pull/124
I like chunks of that. I'm unsure about others 'till I grok 'em better. I like the bits that add detail of required behaviour, e.g. handling resumption, which has been puzzling me:-) The idea of a "public name" is possibly good, but I'll need to ponder it more. (Being slow, as I am:-) Would it be fair to say that that concept isolates ESNI from a likely DNS ops failure mode at the expense of adding another way in which ESNI could be defeated via abuses of the Web PKI? If so, is there any way to make using a "public name" require that the entity who can authenticate as the "public name" also has the private part of the public value published in DNS? (Apologies if your scheme does that already and I missed it, or if that's exactly the sync breakage you're trying to mitigate;-) At first sight though, it does look like there's an interesting overlap between this and what Nico/Viktor were proposing about using HRRs. (In the sense that maybe you're all heading towards a not-bad idea, modulo what I think is ekr's winning argument that always requiring an extra RTT would be disqualifying.) [On a different point, changes like these (or other breaking changes) may be easier if we do that "pick an implementation draft" thing that's been done in other more complex cases. I'm not sure if ESNI justifies that, but given my coding resources, (and abilities:-) it'd help me if people wanted to do something like that. E.g. to decide we noodle about with a -03 and try code up to a -04 or similar (or -05 or whatever version is appropriate). For example, there's another kind of change that I think we want before doing interop on a later version: I'd argue the value published in DNS needs to be DNS/zonefile friendly and not primarily TLS-presentation-layer friendly - we're not there now and getting there (or deciding that's not needed) may require discussion of published drafts and not just issues/PRs.] > https://github.com/tlswg/draft-ietf-tls-esni/pull/125 Greasing like this seems like a fine plan. I'm not sure if greasing is still quite the appropriate term, as this is doing more than that, but I like it lots - without something like this ESNI will stick out a lot. I do wonder if people will be willing to emit so many useless bytes though? A possible alternative way to get a similar "don't stand out" effect might be to re-do the CH changes for ESNI so that they're encoded to look like a real key-share (maybe with some other bits of the CH serving dual purposes) - I think that might be just about doable, but a) likely ends up as a total hack, b) is pretty limited (e.g. for looooong names), and c) requires servers to guess if a CH does or doesn't contain ESNI stuff. Could be fun if it worked though, but has anyone looked at that alternative way to not stand out? Cheers, S. > > The first tries to make ESNI more robust. It introduces the notion of a > "public name" which gives the client an authenticated signal to retry with > new keys or without ESNI at all. This mitigates DNS/server mismatches (a > concern on each key rotation), and partial rollouts or rollbacks (a concern > when first enabling it, plus some scenarios with TLS-terminating > middleboxes). > > The second recommends clients to send GREASE ESNI extensions when they do > not have cached ESNIKeys available. This better meets the "Do not stick > out" goal. The server behavior in the first PR gives us this for free. > > Details are in the PRs. > > (The two PRs were originally written up together. I split them in two based > on some feedback, but since they touch the same text, the GREASE PR > includes the robustness PR. If the WG wishes to go with one but not the > other, the text and details can be adjusted accordingly.) > > Thoughts? > > David > > [*] Steven and I wrote the text itself, with input from Adam, Ben, and > Brad, all CC'd. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
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
