Taking a step back from details, ISTM that the whole design of this document is antithetical to extensibility: TLS is a protocol with a number of extension points. What this document does is allow an endpoint to restrict its use of a certain set of extension points. However, the language provided here is insufficiently rich to allow the client to properly describe the use of those points. As a concrete example: for extensions the model knows about (e.g., supported_versions) you can indicate the contents of the extension, but for extensions the model does not know about (e.g., ECH) you cannot. That means that you're either stuck with allowing anything in those extensions (which means that your filtering effectiveness is reduced) or you don't allow those extensions, in which case you create ossification.
As a thought example, consider a hypothetical TLS 1.4 which decided to adopt QUIC-style obfuscation of the CH and SH, putting the obfuscated CH/SH in extensions in a stereotyped outer CH/SH. The system described here would be unable to do anything useful with that, which creates pressure to block TLS 1.4 entirely, which obviously is not awesome. If we want to pursue this kind of idea -- and I'm not at all sure we should -- ISTM that rather than trying to invent some new DSL for filtering TLS we allow the client (who by hypothesis is trusted as to what it will generate) to provide a general program that the middlebox can interpret that will describe what it will do. For instance, you could provide a WASM file which gets fed the CH and just says "this is me" or "this doesn't look like me". That way we don't need to continue extending the language here whenever TLS evolves. Note that that doesn't prohibit having a language like this as a programming convenience, but it wouldn't restrict the semantics of what you could say about the connection. -Ekr On Wed, Sep 16, 2020 at 1:09 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. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
