Re: [OPSAWG] [TLS] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[tirumal reddy <[e-mail]>]

On Tue, 15 Sep 2020 at 18:39, Eliot Lear <[e-mail]> 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
>
>