Hiya, I've started to try code up an openssl version of this. [1] (Don't be scared though, it'll likely be taken over by a student in the new year:-)
From doing that I think the ESNIKeys structure is too complicated and could do with a bunch of changes. The ones I'd argue for would be: - use a new RR, not TXT - have values of ESNIKey each only encode a single option (so no lists at all) since >1 value needs to be supported at the DNS level anyway - that'd mean exactly one ciphersuite - exactly one key share - no extensions (make an even newer RR or version-bump:-) - get rid of not_before/not_after - I don't believe those are useful given TTLs and they'll just lead to failures - get rid of padded_length - just say everyone must always use the max (260?) - that needs to be the same for all encrypted sni values anyway so depending on 'em all to co-ordinate the same value in DNS seems fragile - I'm not convinced the checksum is useful, but it's not hard to handle - (Possibly) drop the base64 encoding, make it DNS operator friendly text (or else binary with a zonefile text format defined in addition) I'm fine that such changes don't get done for a while (so I or my student get time to try make stuff work:-) and it might in any case take a while to figure out how to handle the multi-CDN use-case discussed in Bangkok which would I guess also affect this structure some, but I wanted to send this to the list while it's fresh for me. Cheers, S. [1] https://github.com/sftcd/openssl/tree/master/esnistuff
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
