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. 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? The draft currently contemplates this briefly for followup queries for some clients, but it doesn't go into it in more detail. - 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? 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 At the same time, for $COVER to publish this information potentially puts $COVER at more risk, right? 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. 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. - 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. Regards, --dkg
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
