On Sep 16, 2020, at 1:08 PM, Nick Harper <nharper=40google....@dmarc.ietf.org> wrote: > On Wed, Sep 16, 2020 at 12:24 AM tirumal reddy <kond...@gmail.com> wrote: > Hi Nick, > > Please see inline > > On Wed, 16 Sep 2020 at 06:00, Nick Harper <nhar...@google.com> 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
