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. (This can be stated without mentioning GREASE specifically.)
There is also an issue where this draft does not describe how an observer identifies whether a TLS ClientHello is compliant with a MUD profile. On Tue, Sep 15, 2020 at 4:58 PM Watson Ladd <[email protected]> wrote: > On Tue, Sep 15, 2020, 9:10 AM Eliot Lear > <[email protected]> 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. > > There is no reason that a firewall should expect to parse TLS 1.4. TLS > 1.3 had to go through significant hoops due to middleboxes that > assumed they could see into everything like it was 1.2. This easily > added a year to the development time. The final hunt for incompatible > devices involved attempting to purchase samples, with no real > guarantee that they would find an intolerant device. Encouraging this > sort of behavior is a bad idea IMHO, as it will substantially burden > the TLS WG when designing TLS 1.4 in all sorts of unexpected ways. > > > > > > > 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). > > The whole point of grease is keeping extensions open. Coding special > handling defeats the purpose. > > Sincerely, > Watson Ladd > > > > > Eliot > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
