On Tue, Nov 20, 2018 at 1:46 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > 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:-) > Thanks for your comments. Responses below. >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 > This is likely to happen. - 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 > I don't agree with this. It is going to lead to a lot of redundancy because many servers will support >1 cipher suite with the same key share. Moreover, from an implementation perspective, supporting >1 RR would be quite a bit more work. - no extensions (make an even newer RR or version-bump:-) > Again, not a fan of this. It leads to redundancy. - get rid of not_before/not_after - I don't believe those > are useful given TTLs and they'll just lead to failures > I'm mostly ambivalent on this, but on balance, I think these are useful, as they are not tied to potentially fragile DNS TTLs. - get rid of padded_length - just say everyone must > always use the max (260?) - I'm not in favor of this. The CH is big enough as it is, and this has a pretty big impact on that, especially for QUIC. There are plenty of scenarios where the upper limit is known and << 160. 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 > It only has to be the same for all the ones in the anonymity set, and they already need to coordinate on the key. - 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) > We are likely to drop the base64 encoding. -Ekr > [1] https://github.com/sftcd/openssl/tree/master/esnistuff > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
