On Wed, 23 Sep 2020 05:51:24 -0700 Eric Rescorla <e...@rtfm.com> wrote:
> I think this misunderstands the point. > > Suppose I want to add feature X. There are (at least) two scenarios: > > 1. Add a new feature and it just works. > 2. I have to get it added to the YANG module, then get middlebox > vendors to change their software which may involve introducing some > new parser for that feature, then I can publish a policy, and it > works. > > Option (2) is going to take much longer to happen than option (1). > Depending on how slow the vendors are, it could be indefinitely long. > Given that it's often not viable to roll out new networking features > if they introduce any significantly increased risk of failure, this > seems like a recipe for ossification. Perhaps the draft could instead be written in terms of allowing any TLS behaviour *except* behaviours the Thing promises (via a MUD file) never to use. For example a Thing might promise it doesn't do outbound TLS 1.1 or earlier, and then a compliant MUD manager can block or alert on TLS 1.1 or TLS 1.0 connections purportedly coming from the affected Thing. Or perhaps this Thing is designed to receive connections from another Thing and the MUD policy promises these will never use RSA kex, so the MUD manager can block or alert an attempt to use RSA kex. This seems like it avoids the MUD TLS YANG module needing to chase the bleeding edge of TLS development. A TLS feature only becomes relevant for this "ratchet" approach once there are better alternatives that Things should reasonably be doing instead of that feature, likely years after the feature is in wide use and well understood. That could apply appropriate back pressure to Thing vendors. If your Thing lacks the "I don't do outbound TLS 1.0" node in its MUD file then the question is, does it actually still do TLS 1.0? If it doesn't, a newer MUD file can be provided which says it promises not to. If it does still do TLS 1.0 that's a security policy risk for the owner to understand and perhaps decide to mitigate by whatever means they prefer. Nick. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
