On Tue, 15 Sep 2020 at 18:39, Eliot Lear <l...@cisco.com> wrote: > > > 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). >
Yes, GREASE requires special handling. The YANG model uses a flag to define whether the client supports GREASE or not. The MUD TLS profile does not advertise the GREASE values (see https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-05#section-5). -Tiru > > Eliot > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
