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

[Dan Wing <[e-mail]>]

On Sep 16, 2020, at 1:08 PM, Nick Harper <nharper=[e-mail]> wrote:
> On Wed, Sep 16, 2020 at 12:24 AM tirumal reddy <[e-mail]> wrote:
> Hi Nick,
> 
> Please see inline
> 
> On Wed, 16 Sep 2020 at 06:00, Nick Harper <[e-mail]> wrote:
> I agree with EKR, Ben Schwartz, and Watson Ladd's concerns on this draft.
> 
> The grease_extension parameter shouldn't exist, and there should be no special handling for GREASE values. GREASE doesn't need to be mentioned in this draft, except to say that a client may send values (cipher suites, extensions, named groups, signature algorithms, versions, key exchange modes, ALPN identifiers, etc.) that are unknown to the middlebox and that the middlebox MUST NOT reject connections with values unknown to the middlebox.
> 
> The grease_extension parameter in the YANG model is a "boolean" type to indicate whether the GREASE values are offered by the client or not.  The MUD YANG model does not convey the GREASE values.
>  
> This is still problematic.
> 
> Unknown values MUST be ignored; GREASE is a mechanism used by endpoints to check that their peers correctly ignore unknown values (instead of closing the connection). If a device special-cases GREASE values when processing TLS messages, that device has completely missed the purpose of GREASE and is likely to cause interoperability failures when in the future it sees a TLS message that contains a new extension/cipher suite/etc. that isn't a GREASE value.
> 
> The IETF should not be encouraging devices to special-case GREASE values. I can see no use of the grease_extension parameter in the YANG model that does not involve special-casing GREASE values. Hence it needs to be removed.

Yes, that is the better way to handle GREASE:  expect Grease from any client, on any TLS value (as Ben pointed out supported_versions may well be Grease'd next).

-d