Hiya, (As per the meeting discussion, I'll plan to revise the individual draft in the next while and then the WG can consider what to do about it. If ESNI/ECHO draft-06 is out first, I'll change to align with that. If not, we can worry about that later. In the meantime...)
On 21/11/2019 19:28, Daniel Kahn Gillmor wrote: > On Wed 2019-07-03 16:01:21 +0100, Stephen Farrell wrote: >> It doesn't take much to encourage me so I just >> pushed out that idea in I-D form:-) [1] > […] >> [1] https://tools.ietf.org/html/draft-farrell-tls-wkesni-00 > > Thanks for this (and for the -01 update for the draft). I like this > work, and i think we should pursue it in the WG. Cool. Thanks. > > A couple notes/questions: > > - Clients might use this, not just "zone factories". For instance, > consider a client with limited access to the DNS that makes an > initial direct connection to the hidden host, leaking SNI. If, in > that connection, it also fetches this record, it could use that to > bootstrap future connections to the host, right? Yep. > The draft currently contemplates this briefly for followup queries > for some clients, but it doesn't go into it in more detail. Right. I wasn't sure if people would like, or be freaked out by, that:-) > > - Why is it hosted on the cover server, instead of on the hidden > server? is that just so that the zone factory doesn't leak $HIDDEN > to the network? Yes. Also - if adding a new $HIDDEN then first time around the zone factory can't use ESNI/ECHO to $HIDDEN. > Surely on a zone factory update, the zone factory already knows the > eSNI for $HIDDEN so it could make the request with eSNI to > https://$HIDDEN/.well-known/esni/$HIDDEN.json rather than to > https://$COVER/.well-known/esni/$HIDDEN.json Other than first time, as noted above. I've also had cases where things got out of whack (because I'd broken stuff) that meant ESNI stopped working to $HIDDEN for a bit. (The specific failures I've seen don't make a real difference to answering your question, as the zone factory does try out the new keys with $HIDDEN as part of it's work, but maybe some other failure cases might matter more.) > At the same time, for $COVER to publish this information potentially > puts $COVER at more risk, right? Yes. If $COVER is the public_name from the ESNIConfig though it doesn't seem much more of a risk. > And, a $COVER could *claim* to be a > cover for $HIDDEN without approval of the $HIDDEN site by publishing > these records; if anyone believes that claim, it could cause traffic > to be re-routed through the ersatz $COVER. If it's going to be > hosted at $COVER and not $HIDDEN, we should be explicit about what > defends against such an attack. Sure. In my case, the zone factory knows all the names but yes, discussion of the more general case is needed. > > There could be an "obvious" reason for the choice of hosting it at > $COVER instead of at $HIDDEN, but it should be spelled out in the > draft. Ack. Will do. > > - If this is treated as a separate/independent source of authority > about ESNI data for a host from the DNS (e.g. in the client examples > contemplated in my first point above, not just the "zone factory"), > then the draft probably needs some text discussing what to do when > discovering a discrepancy between what's in the DNS and what's found > at .well-known. True. In the zone factory case, such discrepancies are of course nominal. Otherwise, I can envisage a number of different client scenarios (client DoH/DoT availability can be yes, no or dunno; the client might have old ESNIConfig values or not, and HTTPSSVC might or might not be available etc.) And I guess there's even the case (that probably will freak someone out) where $HIDDEN might not even exist in the DNS at all if it is covered by a wild-card cert and if $HIDDEN is in the client's /etc/hosts or equivalent. (I think I could support that now in my servers but haven't actually deployed such a vhost - maybe I should:-) I'm not sure if this draft ought specify behaviour for such clients, but I can try add text describing the various cases I guess. (If that text were to stay in, then I'd guess that it'll make this document too long to include in the base ESNI/ECHO draft thus taking that option off the table maybe.) Cheers, S. > > Regards, > > --dkg >
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
