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 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. > For example, an alert could be triggered to quarantine and remediate the compromised device, and will update the draft to clarify. -Tiru > > On Tue, Sep 15, 2020 at 4:58 PM Watson Ladd <watsonbl...@gmail.com> wrote: > >> On Tue, Sep 15, 2020, 9:10 AM Eliot Lear >> <lear=40cisco....@dmarc.ietf.org> 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 >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
