Hiya, Just on this bit...
On 04/07/18 18:20, Eric Rescorla wrote: > The structure started a bit simpler and got new features to > deal with new issues. Specifically: > > - The checksum is intended to deal with corruption I'm not sure I see why that's needed, but I believe you if you say it might help with some home routers. (Though I'd also be interested in information/citation about the details of the problems seen there.) > - The keys and cipher suites seem kind of mandatory Yep. OTOH, given we need to support >1 value for the RR, if mostly people just need one key+CS per-RR, it may be possible to use multiple RRs to provide additional keys/CSes. (If most uses would have a variable number of keys/CSes then I agree the current structure is better.) > - The padded length is needed to tell the client how much to > pad. Though I guess we could always pad to 260. If you don't > pad at all, it doesn't work. Sure. > - I think it's clear what not_before and not_after are for. If you have > more concrete feedback about better ways to do that, we'd welcome > this. With not_before/not_after (and the TTL) there'll need to be some consideration of the various overlaps, which has been a source of bugs and ops screw-ups in other scenarios. I also don't like the forced expiry of not_after - people will just put in 2038 all over, or risk weird breakage. (X.509's mandatory notAfter was IMO an error for most uses of X.509 - an error inherited from the X.500 DAP user authentication use-case that initially motivated X.509.) I wonder would an incrementing counter (like SOA serial) maybe be easier where the client just uses the highest value? (There was some discussion on related topics during the work on MTA-STS, but I forget the details, might be worth checking with the folks involved.) > - Extensions is just there because we're trying to be safe. Sure, but I hope we consider dropping 'em if there's no need. New RRTYPEs could always be used for extensions (if new RRTYPEs are cheap, that is:-) > > FWIW, this actually is pretty friendly because we b64-encode > (thus making the internal structure opaque to DNS). Removing > things won't make it much smaller because a big chunk of > the data is in the keys. For instance, in my implementation, > the object is 70 bytes long and 34 bytes of that is key (X25519) > and 8 bytes is cipher suite (each of these has 2 bytes of length). That's good. But I was more thinking about how friendly this would be for the DNS admin folks. One thing I like about TLSA and CAA is that (for my use-cases:-) I can just cut'n'paste the values into zone files and they'll be good until a CA root key or name changes, which is pretty rare and would be widely advertised ahead of time. With RRSIGs and similar, I can also easily inspect values by just looking at zonefiles and/or using dig, which is helpful for me at least. But I don't have to deal with large zones so that kind of inspection may not be of much use to larger operators. So, I'd defer to real DNS server folks on whether or not being able to directly view the internals of ESNIKeys encoding makes any difference. All that said, I did just suggest adding in the dummy sni value:-) So I mostly think if this goes ahead (as I hope it does), we spend a bit of time considering the above issues before we're done. 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
