Subject: [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Wed, 2 Sep 2020 15:05:50 +0000

Hello, opsawg.  This draft as underwent a number of revisions based on reviews and presentations at the last few IETF meetings.  The authors feel they have addressed the issues and concerns from the WG in their latest posted -05 revision.  As a reminder, this document describes how to use (D)TLS profile parameters with MUD to expose potential unauthorized software or malware on an endpoint.

To that end, this serves as a two-week call for adoption for this work.  Please reply with your support and/or comments by September 16, 2020.

Thanks.

Joe and Tianran

---

From: Eliot Lear <[email-masked]>
Date: Fri, 4 Sep 2020 11:22:10 +0200

I have read the draft and commented, and support this work being adopted by OPSAWG.

Eliot

> On 2 Sep 2020, at 17:05, Joe Clarke (jclarke) <jclarke=[email-masked]> wrote:
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: <[email-masked]>
Date: Fri, 4 Sep 2020 14:18:23 +0000

Hi all, 

I support adoption. 

FWIW, some quick comments are available at: 

* pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-reddy-opsawg-mud-tls-05-rev%20Med.pdf 
* doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-reddy-opsawg-mud-tls-05-rev%20Med.docx 

It would be fair to include some of the limitations of the proposed approach (e.g., IoT devices that are not maintained).

Cheers,
Med

> -----Message d'origine-----
> De : OPSAWG [mailto:[email-masked]] De la part de Joe Clarke
> (jclarke)
> Envoyé : mercredi 2 septembre 2020 17:06
> À : opsawg <[email-masked]>
> Objet : [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
> 
> Hello, opsawg.  This draft as underwent a number of revisions based on
> reviews and presentations at the last few IETF meetings.  The authors
> feel they have addressed the issues and concerns from the WG in their
> latest posted -05 revision.  As a reminder, this document describes
> how to use (D)TLS profile parameters with MUD to expose potential
> unauthorized software or malware on an endpoint.
> 
> To that end, this serves as a two-week call for adoption for this
> work.  Please reply with your support and/or comments by September 16,
> 2020.
> 
> Thanks.
> 
> Joe and Tianran

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: tirumal reddy <[email-masked]>
Date: Sat, 5 Sep 2020 11:32:39 +0530

Hello WG,

I support the adoption of this draft (as a co-author).

Regards,
-Tiru

On Wed, 2 Sep 2020 at 20:36, Joe Clarke (jclarke) <jclarke=
[email-masked]> wrote:

> reviews and presentations at the last few IETF meetings.  The authors feel
> they have addressed the issues and concerns from the WG in their latest
> posted -05 revision.  As a reminder, this document describes how to use
> (D)TLS profile parameters with MUD to expose potential unauthorized
> software or malware on an endpoint.
>
> To that end, this serves as a two-week call for adoption for this work.
> Please reply with your support and/or comments by September 16, 2020.
>
> Thanks.
>
> Joe and Tianran

---

From: Flemming Andreasen <[email-masked]>
Date: Sat, 5 Sep 2020 12:39:31 -0400

I support adoption of the draft too.

Thanks

-- Flemming

On 9/5/20 2:02 AM, tirumal reddy wrote:
> On Wed, 2 Sep 2020 at 20:36, Joe Clarke (jclarke) 
> <jclarke=[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hello, opsawg.  This draft as underwent a number of revisions
>     based on reviews and presentations at the last few IETF meetings.
>     The authors feel they have addressed the issues and concerns from
>     the WG in their latest posted -05 revision.  As a reminder, this
>     document describes how to use (D)TLS profile parameters with MUD
>     to expose potential unauthorized software or malware on an endpoint.
>
>     work.  Please reply with your support and/or comments by September
>     16, 2020.
>
>     Thanks.
>
>     Joe and Tianran
>     [email-masked] <mailto:[email-masked]>

---

From: tirumal reddy <[email-masked]>
Date: Thu, 10 Sep 2020 10:48:15 +0530

Thanks Med for the support and comments, will address them in the next
revision.

Cheers,
-Tiru

On Fri, 4 Sep 2020 at 19:48, <[email-masked]> wrote:

> * pdf:
> https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-reddy-opsawg-mud-tls-05-rev%20Med.pdf
> * doc:
> https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-reddy-opsawg-mud-tls-05-rev%20Med.docx
>
> It would be fair to include some of the limitations of the proposed
> approach (e.g., IoT devices that are not maintained).
>
> Cheers,
> Med
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 Sep 2020 11:46:07 -0400

> To that end, this serves as a two-week call for adoption for this work.  Please reply with your support and/or comments by September 16, 2020.

I have read the document in a number of different revisions, and I 
support adoption.

I have been concerned that this document codifies a kind of TLS snooping 
by middle boxes which has in the past caused significant harm to 
development of TLS. (In particular, TLS version negotiation has had to 
evade existing middle box policies!)

However,  this document seems to walk the fine line between causing 
protocol ossification and providing real security.  To the extent that 
it reduces the pressure by enterprises to invade the TLS encryption 
envelope through use of Enterprise certificates [is there a term for the 
activity describe in section 4.1? I wish there was] this document is a 
very useful thing.

I would like to suggest that upon adoption, that this document go 
through a TLS WG review of some sort before OPSAWG does a WGLC.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 10 Sep 2020 11:51:15 -0400

> Hi all,
...
> It would be fair to include some of the limitations of the proposed approach (e.g., IoT devices that are not maintained).

IoT devices which never get software updates would benefit greatly from 
additional protection that MUD provides.  A MUD profile for such a 
device would have to be created by a third party, and one way to do this 
is by observation of current traffic.    That could certainly include 
TLS parameters observed.
There are multiple efforts in this direction, and additional 
coordination is probably desirable.

Since the device is not getting updates, it won't be changing it's TLS 
library, and so the mechanisms that are described in this document will 
be even MORE effective.   So I'm not sure what limitations you are 
thinking about here.

The real risk is that the device suddenly receives an update, and since 
the MUD file is not from the manufacturer, that the device now sets of 
alarms as the MUD file has not been updated.

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 10 Sep 2020 21:35:33 -0400

Thanks for highlighting this, Michael.  I don't support adoption of this
draft, because I don't think it is fit-for-purpose.  Specifically, I think
it is likely to provide a significant advantage to malware authors (the
opposite of the intended effect).

Currently, if a malware author wants to match the TLS characteristics of
the host device, they have to do some work to characterize its TLS
behavior.  This may be difficult, especially in the case of partial
compromise, or for malware that targets a wide variety of hosts.  However,
with this MUD module in place, the malware can read the TLS behavior right
out of the MUD profile, and configure its behavior to match.

Note that, except in the case of TLS termination, the proxy cannot verify
anything about the TLS session by observing it.  Just because a connection
appears to use a particular SNI or certificate does not prove anything
about the actual destination.

On Thu, Sep 10, 2020 at 11:47 AM Michael Richardson <[email-masked]>
wrote:

> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Panwei (William)" <[email-masked]>
Date: Fri, 11 Sep 2020 04:12:13 +0000

Hi authors, all,

I've read the draft and I support adoption. This draft is useful for the network element, e.g., firewalls, to identity and prevent the unintended usage of (D)TLS encryption, which will help increase the security especially in the Enterprise networks. The unexpected usage of (D)TLS can include two aspects, one is using the old version or weak algorithms, the other is communicating with unauthorized servers. I'm glad to see this draft has covered these two aspects.

Two comments:
1. The 'application-protocols' defined in the YANG module is string-type, can it be defined in a more accurate way, like port numbers or enumerations? Because I think different entities may have different interpretations of the strings.
2. It does be a problem if the updates of the MUD file can't follow the pace of the updates of IoT devices. This draft has considered this problem in some places, but I think it's better to outline this problem separately and systematically.

Regards & Thanks!
Wei Pan

-----Original Message-----
From: OPSAWG [mailto:[email-masked]] On Behalf Of Joe Clarke (jclarke)
Sent: Wednesday, September 2, 2020 11:06 PM
To: opsawg <[email-masked]>
Subject: [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

Thanks.

Joe and Tianran

---

From: tirumal reddy <[email-masked]>
Date: Fri, 11 Sep 2020 12:32:03 +0530

Hi Ben,

Please see inline

> out of the MUD profile, and configure its behavior to match.

The MUD URL is encrypted and shared only with the authorized components in
the network. An  attacker cannot read the MUD URL and identify the IoT
device. Otherwise, it provides the attacker with guidance on what
vulnerabilities may be present on the IoT device.

> about the actual destination.

Yes, it is discussed in
https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-05#section-4

Cheers,
-Tiru

>> work.  Please reply with your support and/or comments by September 16, 2020.
>>

---

From: tirumal reddy <[email-masked]>
Date: Fri, 11 Sep 2020 13:30:16 +0530

Hi Wei,

Thanks for the feedback. Please see inline

On Fri, 11 Sep 2020 at 09:43, Panwei (William) <[email-masked]>
wrote:

> Hi authors, all,
>
> I've read the draft and I support adoption. This draft is useful for the
> network element, e.g., firewalls, to identity and prevent the unintended
> usage of (D)TLS encryption, which will help increase the security
> especially in the Enterprise networks. The unexpected usage of (D)TLS can
> include two aspects, one is using the old version or weak algorithms, the
> other is communicating with unauthorized servers. I'm glad to see this
> draft has covered these two aspects.
>
> Two comments:
> 1. The 'application-protocols' defined in the YANG module is string-type,
> can it be defined in a more accurate way, like port numbers or enumerations?

MUD ACL rules can already include port numbers (see
https://tools.ietf.org/html/rfc8520#section-9).

> Because I think different entities may have different interpretations of
> the strings.
> 2. It does be a problem if the updates of the MUD file can't follow the
> pace of the updates of IoT devices. This draft has considered this problem
> in some places, but I think it's better to outline this problem separately
> and systematically.
>

Sure, we will update the draft. You may also want to look into
https://datatracker.ietf.org/doc/html/draft-richardson-opsawg-mud-acceptable-urls-01,
it can help with rapidly updating the (D)TLS profile as new firmware is
installed.

Cheers,
-Tiru

---

From: tirumal reddy <[email-masked]>
Date: Fri, 11 Sep 2020 17:21:53 +0530

On Fri, 11 Sep 2020 at 16:11, Nick Lamb <[email-masked]> wrote:

> On Fri, 11 Sep 2020 12:32:03 +0530
> tirumal reddy <[email-masked]> wrote:
>
> > The MUD URL is encrypted and shared only with the authorized
> > components in the network. An  attacker cannot read the MUD URL and
> > identify the IoT device. Otherwise, it provides the attacker with
> > guidance on what vulnerabilities may be present on the IoT device.
>
> RFC 8520 envisions that the MUD URL is broadcast as a DHCP option and
> over LLDP without - so far as I was able to see - any mechanism by which
> it should be meaningfully "encrypted" as to prevent an attacker on your
> network from reading it.
>

RFC 8520 allows other means (see sections 1.5 and 1.8) like 802.1X (for
example, TEAP (it does not allow TLS cipher suites without encryption).
The client identity (certificate carrying the MUD URL) is encrypted and not
visible to eavesdroppers. Further, RFC8520 discusses IoT devices may not
even omit the URL. It recommends to use a proxy to retrieve the MUD file
for privacy reasons.

-Tiru

> Nick.

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 14 Sep 2020 10:30:13 -0400

> even omit the URL. It recommends to use a proxy to retrieve the MUD file

These protections are difficult to deploy (representing a minority of
devices), and do not appear to change the dynamic significantly, given the
draft's assumption that the IoT device has already been compromised.  If
the malware can read the MUD URL out of the IoT device's local storage, or
any unit of this model ever contacts an attacker-controlled MUD Manager,
the attacker can access the MUD file, monitor it for updates, etc.

This design treats the MUD file as a "widely shared secret", which is a
fragile arrangement.  It does not appear to match the main conceptual model
of MUD, which describes MUD files as being "published", i.e. generally
public.

I also think this proposal is likely to seriously impede the ability of IoT
vendors to adopt new versions of TLS, or new protocols such as QUIC.  Such
updates would be delayed by (1) the need to add entries to this YANG model,
and then (2) the time for MUD gateways to develop and deploy the new
entries.  Delaying protocol upgrades reduces security, contrary to the
goals of this draft.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 14 Sep 2020 17:08:45 +0200

Hi Ben,

Much of this relitigates RFC 8520, but IMHO it is worth reviewing assumptions from time to time.  Remember, the purpose of MUD is to identify an authorization profile for a device to a network so that either access can be granted based on that profile or an anomaly can be detected.  The primary, but not exclusive, focus is on IOT.

Please see below.

> 
> This design treats the MUD file as a "widely shared secret", which is a fragile arrangement.  It does not appear to match the main conceptual model of MUD, which describes MUD files as being "published", i.e. generally public.

We should separate the MUD URL from the MUD file.  The MUD file is absolutely 100% public, and consists of information that is observable – or should be observable – from the device.  So if you are a Meddler In The Middle (;-) (MITM) you get this information anyway.

The MUD URL gives up device type information.  This is different in character, but often but not always easily gotten.  I would say that if a manufacturer is taking steps to prevent fingerprinting, then they should take steps to protect the MUD URL.  That’s an active area of interest for some.

> I also think this proposal is likely to seriously impede the ability of IoT vendors to adopt new versions of TLS, or new protocols such as QUIC.  Such updates would be delayed by (1) the need to add entries to this YANG model, and then (2) the time for MUD gateways to develop and deploy the new entries.  Delaying protocol upgrades reduces security, contrary to the goals of this draft.

One can deploy a MUD file update in advance of a code update.  The latter takes a whole lot longer than the former.  No IoT manufacturer is going to put out something in less than the default time of 48 hours, lest they brick millions of devices.  Is this more work for an IoT manufacturer?  Sure.  One thing the draft might do is discuss how to incorporate something into unit testing to write out the change.

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Sep 2020 10:22:55 -0700

I tend to agree with Ben Schwartz on this. I have two
concerns about this draft:

1. It seems likely that it will lead to ossification. While
it is true that devices can in theory update their MUD
descriptions, as a practical matter expecting middleboxes
to enforce certain properties of the TLS handshake seems
likely to mean that they will not do a good job with
unknown data. For instance, this document specifies ways
to describe:

(1) a list of supported extensions types

(2) the expected contents of certain extensions (e.g.,
    named groups)

But what happens when a new extension type is created?
It seems fairly optimistic to think that middleboxes
will just accept whatever stuff the client generates
as long as it's one of the listed code points.

2. This document seems to encourage the use
of terminating (MITM) forward proxies (in Section 4.1).
In the past, the IETF has explicitly avoided endorsing
this practice.

-Ekr

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 14 Sep 2020 13:43:36 -0400

On Mon, Sep 14, 2020 at 11:09 AM Eliot Lear <lear=[email-masked]>
wrote:

> Hi Ben,
>
> Much of this relitigates RFC 8520, but IMHO it is worth reviewing
> assumptions from time to time.  Remember, the purpose of MUD is to identify
> an authorization profile for a device to a network so that either access
> can be granted based on that profile or an anomaly can be detected.  The
> primary, but not exclusive, focus is on IOT.
>
> Please see below.
>
>
> We should separate the MUD URL from the MUD file.  The MUD file is
> absolutely 100% public, and consists of information that is observable –
> or should be observable – from the device.  So if you are a Meddler In The
> Middle (;-) (MITM) you get this information *anyway*.
>

Agreed ... but this proposal appears to be predicated on a contrary
assumption.  It assumes that it is difficult for malware to learn the TLS
profile of the device, and then proceeds to place this profile information
in the (public) MUD file, where malware can easily retrieve it.

The MUD URL gives up device type information.  This is different in
> character, but *often* but not *always* easily gotten.  I would say that
> if a manufacturer is taking steps to prevent fingerprinting, then they
> should take steps to protect the MUD URL.  That’s an active area of
> interest for some.
>
>
> I also think this proposal is likely to seriously impede the ability of
> IoT vendors to adopt new versions of TLS, or new protocols such as QUIC.
> Such updates would be delayed by (1) the need to add entries to this YANG
> model, and then (2) the time for MUD gateways to develop and deploy the new
> One can deploy a MUD file update in advance of a code update.  The latter
> takes a whole lot longer than the former.  No IoT manufacturer is going to
> put out something in less than the default time of 48 hours, lest they
> brick millions of devices.
>

I'm not thinking of the hours-days timescale of MUD file updates; I'm
thinking of the months-years timescale of updating standards to support new
features.  How long does a device have to wait after a new protocol
revision comes out before it can start using the new protocol?  First,
we'll need a new draft to update this YANG model with parameters for the
new protocol.  Then, we'll need all the world's MUD vendors to write new
firmware that can parse the new protocol and compare it to the model.  Then
we'll need all the MUD gateways to update to the new firmware.

Of course, the device can unilaterally "back out" of this arrangement by
issuing a reduced MUD file, but if this feature is advertised to customers,
transitioning to a new protocol may not be an option for many years.
(Consider, for example, the impact on QUIC deployment.)

 Is this more work for an IoT manufacturer?  Sure.  One thing the draft
> might do is discuss how to incorporate something into unit testing to write
> out the change.
>
> Eliot
>
>
>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 15 Sep 2020 11:21:50 +0200

Hi Ben

Thanks for the response.  Please see below.

> 
> Agreed ... but this proposal appears to be predicated on a contrary assumption.  It assumes that it is difficult for malware to learn the TLS profile of the device, and then proceeds to place this profile information in the (public) MUD file, where malware can easily retrieve it.

Ok, I didn’t take that from this discussion.

> 
> I'm not thinking of the hours-days timescale of MUD file updates; I'm thinking of the months-years timescale of updating standards to support new features.  How long does a device have to wait after a new protocol revision comes out before it can start using the new protocol?

Ok, I see what you are saying.  Thanks for getting me there.

The question is what to do when you start seeing something you don’t understand.  Let’s take a TLS extension, for instance.  If the TLS extension is unknown to the f/w but is declared somehow, that tells the firewall that they have some coding to do, and should be conservative about complaining over something that is out of profile.  I don’t see that as a show stopper.  What I do see as a showstopper would be if, as is written and you rightly observe, a new rev of a YANG model is required to introduce the TLS extension, so that part would need to be described in a more flexible manner (e.g, an IANA registration or similar).  I’d suggest the authors consider that.

Eliot

---

From: tirumal reddy <[email-masked]>
Date: Tue, 15 Sep 2020 16:15:01 +0530

Thanks Ben and Eliot for the feedback. Please see inline

> Ok, I didn’t take that from this discussion.

I see the confusion, will try to clarify the issues raised:

a) The MUD URL includes privacy sensitive device details like (device type
and firmware version), and it should be stored in a secure location (like
TEE to avoid exposure to an unauthorized software) and to avoid sending
the MUD URL in clear text otherwise it will help an attacker to exploit a
vulnerability on the IoT device. It is already discussed in RFC8520.

b) One of the comments is that an attacker can observe the traffic from the
IoT device, learn the TLS profile and try to mimic some of the TLS profile
parameters of legitimate clients. This attack is discussed in detail in
Sections 3 and 5.  Please have a look.

c) The proposed mechanism not only helps detecting malware but also helps
identifying TLS and cryptographic vulnerabilities on the IoT device (to
prevent the device from getting compromised in the first place).

> revision comes out before it can start using the new protocol?
>
> The question is what to do when you start seeing something you don’t
> understand.  Let’s take a TLS extension, for instance.  If the TLS
> extension is unknown to the f/w but is declared somehow, that tells the
> firewall that they have some coding to do, and should be conservative about
> complaining over something that is out of profile.

Yes.

> I don’t see that as a show stopper.  What I do see as a showstopper would
> be if, as is written and you rightly observe, a new rev of a YANG model is
> required to introduce the TLS extension, so that part would need to be
> described in a more flexible manner (e.g, an IANA registration or
> similar).  I’d suggest the authors consider that.
>

Agreed, the YANG model relies on IANA for TLS parameters values including
extension type values. Even if a f/w does not support a new extension, it
can still identify whether the new extension is included in the MUD
profile. If the extension is not included in the MUD profile, presence of
unauthorized software is detected.

We will update the draft to make it more clear.

-Tiru

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 15 Sep 2020 08:58:34 -0400

...

> What I do see as a showstopper would be if, as is written and you rightly
>> observe, a new rev of a YANG model is required to introduce the TLS
>> extension, so that part would need to be described in a more flexible
>> manner (e.g, an IANA registration or similar).  I’d suggest the authors
>> consider that.
>>
>

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.

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.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 15 Sep 2020 15:09:50 +0200

> 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.

> 
> 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).

Eliot

---

From: Sandeep Rao <[email-masked]>
Date: Wed, 16 Sep 2020 02:35:17 +0530

Hi,

I have read this document and its support adoption here.

There’s one comment,  maybe the authors can clarify this in the draft.

I believe though not widely used, was recently involved in a talk about
usefulness of TLS session resumption in IoT implementations to improve
session establishment efficiency and speed.   As the resumption handshake
would not carry the typical ClientHello parameters , how would the MUD IoT
firewall profile such legitimate ingress with no specific profile
parameters or indications in the handshake ? Probably this is expressed in
‘mud-tls-profile’ with an attribute such as “sessionTicket” : "T/F" or  in
“extension-types” indicating the possibility of such behaviour of the IoT
device and let Firewall handle it in its implementation.  Will help to get
some clarity around this in the document.

Thanks

-Sandeep

>
> ---------- Forwarded message ---------
> From: Joe Clarke (jclarke) <jclarke=[email-masked]>
> Date: Wed, 2 Sep 2020 at 20:36

---

From: Watson Ladd <[email-masked]>
Date: Tue, 15 Sep 2020 19:57:42 -0400

> 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.

> 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

---

From: Nick Harper <[email-masked]>
Date: Tue, 15 Sep 2020 17:30:03 -0700

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-masked]> 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.
> >
> >
> > Probably greasing is something that needs a certain special handling.
> Indeed that’s a form of fingerprinting (greases field XYZ).
>

---

From: tirumal reddy <[email-masked]>
Date: Wed, 16 Sep 2020 12:19:21 +0530

> Indeed that’s a form of fingerprinting (greases field XYZ).

Yes, GREASE requires special handling. The YANG model uses a flag to define
whether the client supports GREASE or not. The MUD TLS profile does not
advertise the GREASE values (see
https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-05#section-5).

-Tiru

---

From: tirumal reddy <[email-masked]>
Date: Wed, 16 Sep 2020 12:54:17 +0530

Hi Nick,

Please see inline

On Wed, 16 Sep 2020 at 06:00, Nick Harper <[email-masked]> wrote:

> 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.)
>

For example, an alert could be triggered to quarantine and remediate the
compromised device, and will update the draft to clarify.

-Tiru

---

From: Nick Harper <[email-masked]>
Date: Wed, 16 Sep 2020 13:08:44 -0700

> 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.

---

From: Dan Wing <[email-masked]>
Date: Wed, 16 Sep 2020 13:48:38 -0700

On Sep 16, 2020, at 1:08 PM, Nick Harper <nharper=[email-masked]> wrote:
> 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.
>  
> 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.

Yes, that is the better way to handle GREASE:  expect Grease from any client, on any TLS value (as Ben pointed out supported_versions may well be Grease'd next).

-d

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 16 Sep 2020 14:02:29 -0700

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=
[email-masked]> wrote:

> 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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Sep 2020 18:12:51 -0400

ekr> Taking a step back from details, ISTM that the whole design of this
ekr> document is antithetical to extensibility:

I agree.  It was my first reaction as well.
I then had another thought: there are dozens of entities out there that want
to do this regardless, enough that it broke the TLS version system requiring
the hack. (Does that hack have a name?)

We can call them stupid, or we can try to understand their point of view, and
try to help them be less stupid.  

ekr> TLS is a protocol with a number of extension points. What this document
ekr> does is allow an endpoint to restrict its use of a certain set of
ekr> extension points. However, the language provided here is insufficiently
ekr> rich to allow the client to properly describe the use of those
ekr> points.

assuming that some language could be provided that was sufficiently rich,
would your objection continue to stand?

ekr> As a concrete example: for extensions the model knows about
ekr> (e.g., supported_versions) you can indicate the contents of the
ekr> extension, but for extensions the model does not know about (e.g., ECH)
ekr> you cannot. That means that you're either stuck with allowing anything
ekr> in those extensions (which means that your filtering effectiveness is
ekr> reduced) or you don't allow those extensions, in which case you create ossification.

ekr> As a thought example, consider a hypothetical TLS 1.4 which decided to
ekr> adopt QUIC-style obfuscation of the CH and SH, putting the obfuscated
ekr> CH/SH in extensions in a stereotyped outer CH/SH. The system described
ekr> here would be unable to do anything useful with that, which creates
ekr> pressure to block TLS 1.4 entirely, which obviously is not awesome.

I believe that without a mechanism described in this document, many
enterprises may conclude that they need to block TLS 1.3.

ekr> If we want to pursue this kind of idea -- and I'm not at all sure we
ekr> should -- ISTM that rather than trying to invent some new DSL for
ekr> filtering TLS we allow the client (who by hypothesis is trusted as to
ekr> what it will generate) to provide a general program that the middlebox
ekr> can interpret that will describe what it will do. For instance, you
ekr> could provide a WASM file which gets fed the CH and just says "this is
ekr> me" or "this doesn't look like me". That way we don't need to continue
ekr> extending the language here whenever TLS evolves. Note that that doesn't
ekr> prohibit having a language like this as a programming convenience, but
ekr> it wouldn't restrict the semantics of what you could say about the
ekr> connection.

We don't have to have the client provide it, it can be encoded by the
manufacturer in the MUD file, assuming that it depends upon the model, not
some local decision in the client.   The idea of having a WASM file is an
interesting one, but being an executable of a sort, it has other security
problems. 

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 18 Sep 2020 15:54:06 -0700

> the hack. (Does that hack have a name?)

There are actually two things here:

1. Changing the version system -- this was done mostly to accommodate
broken servers.
2. Compatibility mode (hiding the HRR, fake CCS, etc.) -- this was designed
to work around
broken middleboxes.

We can call them stupid, or we can try to understand their point of view,
> and

I don't believe that my note calls them stupid.

In any case, ISTM that the design principle that both 1.3 and QUIC have
converged on is
to opaque-ify as much of the handshake as possible, thus discouraging
passive protocol
enforcement of this kind.

> would your objection continue to stand?

I think it's quite likely that that language would have to be
Turing-complete. I note that
the current language is already very complicated and yet insufficiently
rich.

> enterprises may conclude that they need to block TLS 1.3.

Perhaps you mean some hypothetical TLS 1.4?

There is already very widespread deployment of TLS 1.3 for HTTPS and
blocking it would cause breakage of a large number of sites. Perhaps you
could safely do it for non-443 ports...

> some local decision in the client.

Sorry, yes. I meant "client" in the sense that the client tells the
middlebox what rules to use. Whether it does so directly or by reference to
the manufacturer doesn't seem to matter too much for these purposes.

> The idea of having a WASM file is an

Well, one always has to worry about the security of processing data one
receives from the network, but I'm not sure that the distinction between
the kind of DSL we're talking about here and an executable is really that
sharp. The argument for WASM or something like it is that there has already
been enormous investment in building sandboxed interpreters for it, so one
gets to inherit all of that effort. This is not, of course, to say that the
WASM sandbox will never have vulnerabilities,but one can generally not say
that about any software.

-Ekr

---

From: Nick Lamb <[email-masked]>
Date: Fri, 11 Sep 2020 11:40:54 +0100

Nick.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 19 Sep 2020 18:07:50 -0400

Eric Rescorla <[email-masked]> wrote:

    > Perhaps you mean some hypothetical TLS 1.4?

No, I do mean 1.3.   Many enterprises still think that they can stop it.
Are they winning? probably not.

    > the manufacturer doesn't seem to matter too much for these purposes.

okay.

    > sharp. The argument for WASM or something like it is that there has

Such as DSL would have to limit the number of cycles it is allowed to
consume, otherwise the middle box might have to solve the halting problem :-)
BPF could be another model.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 19 Sep 2020 15:35:51 -0700

> Are they winning? probably not.

Can you say more about this? While during previous transitions clients
would "fall back" to lower versions of TLS, both Chrome and Firefox (and I
imagine Edge and Safari but I have less information) do not do so. As a
result any middlebox which blocks 1.3 will effectively cause failures on
any site which offers 1.3, which seems like it would cause a lot of
problems.

> BPF could be another model.

Agreed. I know BPF less well but my understanding is that it has gotten
quite powerful.

-Ekr

---

From: tirumal reddy <[email-masked]>
Date: Sun, 20 Sep 2020 12:58:06 +0530

> coordination is probably desirable.

That is exactly what we are working on till we get support from IoT
manufacturers.

> alarms as the MUD file has not been updated.

To handle this scenario, the default action is not to block the TLS session
but to export the network telemetry including TLS metadata for anomaly
detection using machine learning techniques (similar to
https://arxiv.org/pdf/1607.01639.pdf).

Cheers,
-Tiru

---

From: tirumal reddy <[email-masked]>
Date: Sun, 20 Sep 2020 13:30:09 +0530

Hi Sandeep,

Please see inline

On Wed, 16 Sep 2020 at 02:35, Sandeep Rao <[email-masked]> wrote:

> parameters or indications in the handshake ?
>

The client does not know whether the server will honor the ticket or not,
it will include all the ClientHello parameters (see
https://tools.ietf.org/html/rfc5077 and
https://tools.ietf.org/html/rfc8446#section-2.2) to allow the server to
decline the resumption and fall back to a full handshake.

> Probably this is expressed in ‘mud-tls-profile’ with an attribute such as
> “sessionTicket” : "T/F" or  in “extension-types” indicating the
> possibility of such behaviour of the IoT device and let Firewall handle it
> in its implementation.  Will help to get some clarity around this in the
> document.
>

In TLS 1.2, SessionTicket is an extension (see value 35 in
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml).
If the client supports this extension, it will be included in the
"extension-types" list defined in the YANG module.

TLS 1.3 obsoletes the session resumption mechanism in TLS 1.2 and defines a
new session resumption mechanism in the base TLS 1.3 spec (RFC8446) itself.
In other words, TLS 1.3 clients will always support session resumption
(unlike TLS 1.2 clients).

Cheers,
-Tiru

---

From: Eliot Lear <[email-masked]>
Date: Sun, 20 Sep 2020 10:35:46 +0200

> On 11 Sep 2020, at 12:40, Nick Lamb <[email-masked]> wrote:
> 

That’s a bit of an overstatement.  RFC 8520 specifies a component architecture.  It names three ways of emitting a URL (DHCP, LLDP, 802.1X w/ certificate).  Two other mechanisms have already been developed (QR code, Device Provisioning Protocol), and a 3rd new method is on the way for cellular devices.

I would not universally claim that a MUD URL is secret but neither would I claim it is not.  The management tooling will know which is which, as will the manufacturer, and can make decisions accordingly.

This having been said, it seems to me we are off on the wrong foot here.  The serious argument that needs to be addressed is Ben’s and EKR's.  We have to be careful about ossification.

Eliot

---

From: tirumal reddy <[email-masked]>
Date: Tue, 22 Sep 2020 16:04:13 +0530

> 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

---

From: tirumal reddy <[email-masked]>
Date: Tue, 22 Sep 2020 17:03:12 +0530

On Sun, 20 Sep 2020 at 14:05, Eliot Lear <[email-masked]> wrote:

> That’s a bit of an overstatement.  RFC 8520 specifies a component
> architecture.  It names three ways of emitting a URL (DHCP, LLDP, 802.1X w/
> certificate).  Two other mechanisms have already been developed (QR code,
> Device Provisioning Protocol), and a 3rd new method is on the way for
> cellular devices.
>
> I would not universally claim that a MUD URL is secret but neither would I
> claim it is not.  The management tooling will know which is which, as will
> the manufacturer, and can make decisions accordingly.
>
> This having been said, it seems to me we are off on the wrong foot here.
> The serious argument that needs to be addressed is Ben’s and EKR's.  We
> have to be careful about ossification.
>

In order to address the comments on ossification, we added a new section 6
to explain the rules to processing the MUD (D)TLS rules to handle unknown
TLS parameters and updated Section 10 to enable faster update to the YANG
module. Please see
https://github.com/tireddy2/MUD-TLS-profile/blob/master/draft-reddy-opsawg-mud-tls-06.txt

-Tiru

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Tue, 22 Sep 2020 13:15:22 +0000

The call for adoption has closed.  It has not been without discussion to be sure.  There have been concerns expressed from the TLS working group that it might benefit malware authors and that it could lead to “ossification” in use of the TLS protocol.

That said, there has been considerable support expressed for (and active willingness to work in) moving this work forward.  Therefore, this document has been adopted by the opsawg working group.  The authors have already been active in addressing some concerns brought up during the CFA, and the chairs encourage the authors and those interested in the progression of this work to continue to work with the TLS WG to fully shore up the text and YANG module.

Additionally, it might be good to get a more formal early review of this work from SecDir so that the WG can focus on additional items required to move the work forward.

Authors, please rename this draft, draft-ietf-opsawg-mud-tls and resubmit it to DataTracker as a -00.  DO NOT change any other text.  Within DT, mark this draft as replacing draft-reddy-opsawg-mud-tls.

Thanks.

Joe

> On Sep 2, 2020, at 11:05, Joe Clarke (jclarke) <jclarke=[email-masked]> wrote:
>

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 22 Sep 2020 11:15:39 -0400

I'm not able to understand the new text in Section 6.  Are you saying that
clients MUST include all the listed extensions/features, but MAY also
include extensions/features not listed in the MUD profile?  So the MUD
profile only acts as a "minimum" set of features?

On Tue, Sep 22, 2020 at 7:34 AM tirumal reddy <[email-masked]> wrote:

>> I would not universally claim that a MUD URL is secret but neither would
>> I claim it is not.  The management tooling will know which is which, as
>> will the manufacturer, and can make decisions accordingly.
>>

---

From: tirumal reddy <[email-masked]>
Date: Wed, 23 Sep 2020 11:34:49 +0530

Agreed to get early SecDir review. Published draft-ietf-opsawg-mud-tls
without any changes, we will address the comments from both the WGs in the
next revision.

Cheers,
-Tiru

On Tue, 22 Sep 2020 at 18:45, Joe Clarke (jclarke) <jclarke=
[email-masked]> wrote:

> The call for adoption has closed.  It has not been without discussion to
> be sure.  There have been concerns expressed from the TLS working group
> that it might benefit malware authors and that it could lead to
> “ossification” in use of the TLS protocol.
>
> That said, there has been considerable support expressed for (and active
> willingness to work in) moving this work forward.  Therefore, this document
> has been adopted by the opsawg working group.  The authors have already
> been active in addressing some concerns brought up during the CFA, and the
> chairs encourage the authors and those interested in the progression of
> this work to continue to work with the TLS WG to fully shore up the text
> and YANG module.
>
> Additionally, it might be good to get a more formal early review of this
> work from SecDir so that the WG can focus on additional items required to
> move the work forward.
>
> Authors, please rename this draft, draft-ietf-opsawg-mud-tls and resubmit
> it to DataTracker as a -00.  DO NOT change any other text.  Within DT, mark
> this draft as replacing draft-reddy-opsawg-mud-tls.
>
> Thanks.
>
> Joe
>

---

From: tirumal reddy <[email-masked]>
Date: Wed, 23 Sep 2020 15:20:32 +0530

Hi Ben,

Please see inline

> profile only acts as a "minimum" set of features?

Section 6 discusses the firewall behaviour when it sees a) known
extensions/features in a TLS session but not specified in the MUD profile
b) unknown extensions/features in a TLS session either specified or not
specified in the MUD profile c) updated MUD profile specifying
extensions/features  not supported by the firewall.

If the client supports new features/extensions but not yet added in the
YANG module, it can be updated using expert review or specification
required registration procedure, discussed in
https://tools.ietf.org/html/rfc8126.

Cheers,
-Tiru

>>> This having been said, it seems to me we are off on the wrong foot
>>> here.  The serious argument that needs to be addressed is Ben’s and EKR's.
>>> We have to be careful about ossification.
>>>
>>
>> In order to address the comments on ossification, we added a new section
>> 6 to explain the rules to processing the MUD (D)TLS rules to handle unknown

---

From: Eliot Lear <[email-masked]>
Date: Wed, 23 Sep 2020 12:29:24 +0200

Tiru

> On 23 Sep 2020, at 11:50, tirumal reddy <[email-masked]> wrote:
> 
> Hi Ben,
> 
> Please see inline 
> 
> On Tue, 22 Sep 2020 at 20:45, Ben Schwartz <[email-masked] <mailto:[email-masked]>> wrote:
> I'm not able to understand the new text in Section 6.  Are you saying that clients MUST include all the listed extensions/features, but MAY also include extensions/features not listed in the MUD profile?  So the MUD profile only acts as a "minimum" set of features?
> 
> Section 6 discusses the firewall behaviour when it sees a) known extensions/features in a TLS session but not specified in the MUD profile b) unknown extensions/features in a TLS session either specified or not specified in the MUD profile c) updated MUD profile specifying extensions/features  not supported by the firewall.
> 

I think it would be good to step through a couple of example extensions that could be viewed both separately and together, and what the order of operations would look like in each case.

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 Sep 2020 05:51:24 -0700

On Wed, Sep 23, 2020 at 2:51 AM tirumal reddy <[email-masked]> wrote:

>> I'm not able to understand the new text in Section 6.  Are you saying
>> that clients MUST include all the listed extensions/features, but MAY also

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.

-Ekr

>>>> I would not universally claim that a MUD URL is secret but neither
>>>> would I claim it is not.  The management tooling will know which is which,
>>>> as will the manufacturer, and can make decisions accordingly.
>>>>

---

From: Nick Lamb <[email-masked]>
Date: Wed, 23 Sep 2020 22:14:54 +0100

On Wed, 23 Sep 2020 05:51:24 -0700
Eric Rescorla <[email-masked]> wrote:

> 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.
> 
> 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.