On Thu, 17 Sep 2020 at 01:38, Nick Harper <nhar...@google.com> 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. > Got it, Thanks. Removed the grease_extension parameter from the YANG module and added the following text: GREASE [RFC8701] sends random values on TLS parameters to ensure future extensibility of TLS extensions. Such GREASE values might be extended to other TLS parameters. Thus, the (D)TLS profile parameters defined in the YANG module by this document MUST NOT include the GREASE values for extension types, named groups, signature algorithms, (D)TLS versions, pre-shared key exchange modes, cipher suites and for any other TLS parameters defined in future RFCs. -Tiru
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
