> My concern is not with "new extensions" per se. The hidden assumption here > is that "extensions" are the only way TLS can evolve. In fact, future TLS > versions are not constrained to evolve in any particular way. For example, > future versions can introduce entirely new messages in the handshake, or > remove messages that are currently visible in the handshake. QUIC is > arguably just an extreme version of this observation.
I understand. I used TLS extensions merely as an example. > > Even within the realm of ClientHello extensions, there is significant > inflexibility here. For example, consider the handling of GREASE extensions. > GREASE uses a variety of reserved extension codepoints, specifically to make > sure that no entity is attempting to restrict use of unrecognized extensions. > This proposal therefore has to add a flag declaring whether the client uses > GREASE, because otherwise the set of extensions is dynamic, and the number of > potential codepoints is impractically large. Any change to the way GREASE > selects and rotates extension codepoints would therefore require a revision > of this YANG model first. There has also been discussion of adding > GREASE-type behavior to the "supported_versions" extension; that would > similarly require a revised YANG model here. > Probably greasing is something that needs a certain special handling. Indeed that’s a form of fingerprinting (greases field XYZ). Eliot
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
