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

[Nick Lamb]

On Wed, 23 Sep 2020 05:51:24 -0700
Eric Rescorla  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

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

[Eric Rescorla]

On Wed, Sep 23, 2020 at 2:51 AM tirumal reddy  wrote:

> Hi Ben,
>
> Please see inline
>
> On Tue, 22 Sep 2020 at 20:45, Ben Schwartz  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.
>
> 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.
>

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


> Cheers,
> -Tiru
>
>
>>
>> On Tue, Sep 22, 2020 at 7:34 AM tirumal reddy  wrote:
>>
>>> On Sun, 20 Sep 2020 at 14:05, Eliot Lear  wrote:
>>>


 > On 11 Sep 2020, at 12:40, Nick Lamb  wrote:
 >
 > On Fri, 11 Sep 2020 12:32:03 +0530
 > tirumal reddy  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.

 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
>>> ___
>>> 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eliot Lear]

Tiru

> On 23 Sep 2020, at 11:50, tirumal reddy  wrote:
> 
> Hi Ben,
> 
> Please see inline 
> 
> On Tue, 22 Sep 2020 at 20:45, Ben Schwartz  > 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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[tirumal reddy]

Hi Ben,

Please see inline

On Tue, 22 Sep 2020 at 20:45, Ben Schwartz  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.

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


>
> On Tue, Sep 22, 2020 at 7:34 AM tirumal reddy  wrote:
>
>> On Sun, 20 Sep 2020 at 14:05, Eliot Lear  wrote:
>>
>>>
>>>
>>> > On 11 Sep 2020, at 12:40, Nick Lamb  wrote:
>>> >
>>> > On Fri, 11 Sep 2020 12:32:03 +0530
>>> > tirumal reddy  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.
>>>
>>> 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
>> ___
>> 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

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

[Ben Schwartz]

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  wrote:

> On Sun, 20 Sep 2020 at 14:05, Eliot Lear  wrote:
>
>>
>>
>> > On 11 Sep 2020, at 12:40, Nick Lamb  wrote:
>> >
>> > On Fri, 11 Sep 2020 12:32:03 +0530
>> > tirumal reddy  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.
>>
>> 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
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[tirumal reddy]

On Sun, 20 Sep 2020 at 14:05, Eliot Lear  wrote:

>
>
> > On 11 Sep 2020, at 12:40, Nick Lamb  wrote:
> >
> > On Fri, 11 Sep 2020 12:32:03 +0530
> > tirumal reddy  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.
>
> 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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[tirumal reddy]

On Thu, 17 Sep 2020 at 01:38, Nick Harper  wrote:

>
>
> On Wed, Sep 16, 2020 at 12:24 AM tirumal reddy  wrote:
>
>> Hi Nick,
>>
>> Please see inline
>>
>> On Wed, 16 Sep 2020 at 06:00, Nick Harper  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.
>

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eliot Lear]

> On 11 Sep 2020, at 12:40, Nick Lamb  wrote:
> 
> On Fri, 11 Sep 2020 12:32:03 +0530
> tirumal reddy  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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

On Sat, Sep 19, 2020 at 3:07 PM Michael Richardson 
wrote:

>
> Eric Rescorla  wrote:
> 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.
> >>
>
> > 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.
>

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.


> >> The idea of having a WASM file is an
> >> interesting one, but being an executable of a sort, it has other
> security
> >> problems.
>
> > 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
>
> 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.
>

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

-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Michael Richardson]

Eric Rescorla  wrote:
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.
>>

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

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

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

okay.

>> The idea of having a WASM file is an
>> interesting one, but being an executable of a sort, it has other security
>> problems.

> 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

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. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

On Fri, Sep 18, 2020 at 3:12 PM Michael Richardson 
wrote:

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

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
> try to help them be less stupid.
>

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.



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

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.


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

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



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


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
> interesting one, but being an executable of a sort, it has other security
> problems.
>

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Michael Richardson]

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  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 



signature.asc
Description: PGP signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

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  wrote:

>
>
> On Wed, Sep 16, 2020 at 12:24 AM tirumal reddy  wrote:
>
>> Hi Nick,
>>
>> Please see inline
>>
>> On Wed, 16 Sep 2020 at 06:00, Nick Harper  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

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

[Dan Wing]

On Sep 16, 2020, at 1:08 PM, Nick Harper  
wrote:
> On Wed, Sep 16, 2020 at 12:24 AM tirumal reddy  wrote:
> Hi Nick,
> 
> Please see inline
> 
> On Wed, 16 Sep 2020 at 06:00, Nick Harper  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.

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[tirumal reddy]

Hi Nick,

Please see inline

On Wed, 16 Sep 2020 at 06:00, Nick Harper  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  wrote:
>
>> On Tue, Sep 15, 2020, 9:10 AM Eliot Lear
>>  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

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

[tirumal reddy]

On Tue, 15 Sep 2020 at 18:39, Eliot Lear  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.
>
>
> 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).
>

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


>
> Eliot
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Harper]

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  wrote:

> On Tue, Sep 15, 2020, 9:10 AM Eliot Lear
>  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

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

[Watson Ladd]

On Tue, Sep 15, 2020, 9:10 AM Eliot Lear
 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

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

[Eliot Lear]

> 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



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[tirumal reddy]

Thanks Ben and Eliot for the feedback. Please see inline

On Tue, 15 Sep 2020 at 14:51, Eliot Lear  wrote:

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


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


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


> Eliot
>
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eliot Lear]

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





signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

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








On Thu, Sep 10, 2020 at 6:36 PM Ben Schwartz  wrote:

> 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 
> wrote:
>
>> On 2020-09-02 11:05 a.m., Joe Clarke (jclarke) 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.
>> >
>> > 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.
>>
>>
>> ___
>> 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eliot Lear]

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




signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[tirumal reddy]

On Fri, 11 Sep 2020 at 16:11, Nick Lamb  wrote:

> On Fri, 11 Sep 2020 12:32:03 +0530
> tirumal reddy  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.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nick Lamb]

On Fri, 11 Sep 2020 12:32:03 +0530
tirumal reddy  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.

Nick.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[tirumal reddy]

Hi Ben,

Please see inline

On Fri, 11 Sep 2020 at 07:05, Ben Schwartz  wrote:

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

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.


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

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

Cheers,
-Tiru


>
> On Thu, Sep 10, 2020 at 11:47 AM Michael Richardson 
> wrote:
>
>> On 2020-09-02 11:05 a.m., Joe Clarke (jclarke) 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.
>> >
>> > 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.
>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> ___
> OPSAWG mailing list
> ops...@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Michael Richardson]

On 2020-09-02 11:05 a.m., Joe Clarke (jclarke) 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.

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.



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls