On Wed, Oct 23, 2019 at 12:13:39PM -0400, Ben Schwartz wrote: > On the topic of radical suggestions, here's another one: > https://github.com/tlswg/draft-ietf-tls-esni/pull/186 > > In brief, this replaces the variable-length name with a fixed-length > hash, plus some accommodations to allow *.example.com, > *.*.example.com, etc. > > My hope is that this design would work in the architecture described > by Watson, while saving ~220 bytes in each ClientHello. > > One interesting feature of this design is that it doesn't require each > wildcard domain to publish any unique DNS record. Instead, all > third-level wildcard customers can share a configuration, all > fourth-level wildcard customers can share a configuration, etc. This > distinction is not visible in the TLS handshake, so the anonymity set > is not reduced.
AFAIK, PKIX in practice only allows single full-label wildcard in terminal position (the only place * can appear is as first character, followed by label separator). And the scheme in #186 does not seem to distinguish between "example.org" (the base name) and "*.example.org" (a wildcard). There also seems to be issue that seemingly nothing constrains the case of hashed encoding. And you do not want to deal with arbitrary casings, as the number of those quickly blows up. Perhaps a simpler way would be to have a flag that causes the first label to be overwritten with '*'. That would be set on nodes covered by a wildcard certificate. Alphabet would be hashed lowercased. Then the server could just hash every lowercased name from every known certificate and use the hashes as lookup table keys without worrying about encoding. And in the structure, the label_limit, num_labels and length field for name_digest seem to be superfluous. This would give that the encrypted_sni is 64 octets with AES-128 or Chacha20, and 80 octets with AES-256. On optimizing stuff, the length fields for record_digest and encrypted_sni in client structure are also superfluous, because the length of record_digest is impiled by suite (and unknown suites are unprocessable anyway) and encrypted_sni runs to end of explicit-length record. The length of key share probably can not be removed, as some algorithms may have variable-length ciphertexts. Using the above figures, this would mean that the part after the share would be 96 octets for AES-128 and Chacha20 and 128 octets for AES-256. -Ilari _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
