On Thu, May 20, 2021 at 3:56 PM Viktor Dukhovni <[email protected]>
wrote:
> I agree it is a straight-forwarding encoding for machines, and it is
> well suited for the GREASE code points.
>
> 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.
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. Those solutions should be favored over restricting the wire
protocol/code point allocation.
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
