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.) 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.) 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." 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;-) > [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: - 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? - Maybe add that even TLS1.3 clients that don't really do ESNI MAY grease ESNI? (A bit weird but hey why not?:-) - 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;-) Cheers, S.
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
