search

sftcd / wkesni

A well-known URI for publishing ESNIKeys
7 stars 2 forks source link

Adjust JSON encodings for precision #13

Closed bemasc closed 4 months ago

bemasc commented 1 year ago

There are some nontrivial encoding issues here, because DNS names and ALPNs can contain arbitrary octets. Supporting weird DNS names seems unnecessary since the operator can always choose conformant names, and weird names introduce a risk of escaping mismatch which is probably bad for security. However, supporting weird ALPN values is arguably necessary to avoid ossifying the ALPN registry space.

richsalz commented 1 year ago

I don't know. The ALPN registry space is effectively ascii except for some reserved values https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids although the defining RFC 7301 says bytes.

As for DNS names, I would say say limit to being a-labels. Which is where the IETF is moving, compare a-label, not u-label.

bemasc commented 1 year ago

We've had this conversation before. It looks like your view was the same then! However, from that thread I concluded that the TLS working group didn't have consensus to narrow the allowed character set, and I think that's probably still true. Limiting this draft to a subset of legal ALPN values also strikes me as problematic, as it effectively ossifies the ALPN registry.

I believe "A-label" refers specifically to the output of a Punycode encoder, so I don't think it's relevant here. Also, A-labels never include "_", which I believe we need to allow. However, I agree that IDNs are not allowed in this field. I think that follows automatically from the rule in this PR, but I'm happy to adjust the text if you think it's unclear.