On Thu, May 20, 2021 at 04:15:27PM -0700, Nick Harper wrote:
> > But, it makes for a fairly terrible user interface for the human
> > operator. Compare:
> >
> > * managesieve
> > * 6d616e6167657369657665
> >
> > Typos in hex values are easy to make and hard to recognise.
>
> I agree that it's not a great user interface for the human. A good
> solution to that is to let the user define a constant with the hex value
> (or build the ALPN constant into the config language), like how with
> OpenSSL one can specify "ECDHE-ECDSA-AES128-GCM-SHA256" instead of 0xC02B.
> Using your example, one could define a constant ManageSieve = {0x6d 0x61
> 0x6e 0x61 0x67 0x65 0x73 0x69 0x65 0x76 0x65} and reference that constant,
> and if a typo were made (e.g. one put ManageSeive in the config), the
> config would fail fast, vs if one configured "manageseive" as the ALPN
> directly, the typo would propagate further through a deployment before
> being detected/fixed.
The constants would work fine in programming APIs, but they're of no use
in filling in DNS records in web forms, master copies of zone files, ...
or any other configuration file syntax where the context supports only
literals.
> There are good solutions to solve the human factors of managing/configuring
> ALPN that don't require imposing restrictions on what ALPN can go on the
> wire in TLS.
Note, I am NOT promising restricting what can go on the wire TLS, only
what can go in the IANA ALPN registry as a standard interoperable ALPN
value.
> Those solutions should be favored over restricting the wire
> protocol/code point allocation.
None come to mind for the alpn field of the proposed HTTPS/SVCB records.
What would you suggest? (I hope not hex).
The current proposal, even with the rather compex quoting/escaping rules
is better than hex, but is rather fragile. Developers will get it
badly wrong.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
