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] The future of external PSK in TLS 1.3

[Carrick Bartle]

I didn't mention SCADA at all. Did you mean to address this question to Filippo 
or Peter?


> On Sep 23, 2020, at 4:49 AM, Hannes Tschofenig  
> wrote:
> 
> Hi Carrick, 
>  
> you note that SCADA is a pretty specific use case. SCADA sounds specific but 
> TLS is used widely in the IoT market. It is even used in devices that use 
> smart cards, which use TLS with PSK to protect their provisioning protocol.
>  
> I am worried that marking a ciphersuite as N with the meaning that it "has 
> not been through the IETF consensus process, has limited applicability, or is 
> intended only for specific use cases" is hard for readers to understand which 
> of these three cases were actually the reason for marking it as “N”. The "has 
> not been through the IETF consensus process" will scare off many people.
>  
> For most people the web is the generic case and everything else is a 
> “specific use case”. Sure, the web is very important but TLS is a generic 
> protocol used in many environments.  
>  
> I don’t understand John’s motivation. The LAKE group makes a decision to 
> remove PSK support. That’s good for them. Does this imply that the TLS group 
> also needs to make the same decision?
>  
> Ciao
> Hannes
>  
> From: Carrick Bartle  
> Sent: Monday, September 21, 2020 6:19 PM
> To: Hannes Tschofenig 
> Cc: Carrick Bartle ; Filippo Valsorda 
> ; tls@ietf.org
> Subject: Re: [TLS] The future of external PSK in TLS 1.3
>  
> Can you justify your reasoning? 
>  
> Which part?
>  
> 
> 
> On Sep 21, 2020, at 2:22 AM, Hannes Tschofenig  > wrote:
>  
> Hi Carrick, 
>  
> Can you justify your reasoning? 
>  
> The challenge I have with the work on IoT in the IETF that the preferences 
> for pretty much everything changes on a regular basis.
>  
> I don’t see a problem that requires a change. In fact, I have just posted a 
> mail to the UTA list that gives an overview of the implementation status of 
> embedded TLS stacks and PSK-based ciphersuites are widely implemented.  
>  
> Ciao
> Hannes
>  
> From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of 
> Carrick Bartle
> Sent: Monday, September 21, 2020 5:31 AM
> To: Filippo Valsorda mailto:fili...@ml.filippo.io>>
> Cc: tls@ietf.org 
> Subject: Re: [TLS] The future of external PSK in TLS 1.3
>  
> I'm also fine with marking psk_ke as not recommended to be consistent with 
> the non-PFS ciphers, but there are plenty of valid use cases that justify 
> keeping dhe_psk_ke as recommended for external PSKs. Several of these use 
> cases are detailed in draft-ietf-tls-external-psk-guidance-00.
>  
>  
>  
> On Sep 19, 2020, at 9:00 AM, Filippo Valsorda  > wrote:
>  
> 2020-09-19 13:48 GMT+02:00 Peter Gutmann  >:
> John Mattsson  > writes:
>  
> >Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and
> >especially psk_ke are both marked as RECOMMENDED. If used in the initial
> >handshake, both modes have severe privacy problems,
>  
> PSK is used a fair bit in SCADA.  There are no privacy problems there.  So
> just because there's a concern for one specific environment doesn't mean it
> should be banned for any use.  In particular, I think if a specific industry
> has a particular concern, they should profile it for use in that industry but
> not require that everyone else change their behaviour.
>  
> Indeed, if the SCADA industry has a particular need, they should profile TLS 
> for use in that industry, and not require we change the recommendation for 
> the open Internet.
>  
> Setting Recommended to N is not "banning" anything, it's saying it "has not 
> been through the IETF consensus process, has limited applicability, or is 
> intended only for specific use cases". SCADA sounds like a pretty specific 
> use case.
>  
> I don't have a strong opinion on psk_dhe_ke, but I see no reason psk_ke 
> wouldn't be marked N like all suites lacking PFS.
> ___
> TLS mailing list
> TLS@ietf.org 
> https://www.ietf.org/mailman/listinfo/tls 
> 
>  
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you. 
> ___
> TLS mailing list
> TLS@ietf.org 
> https://www.ietf.org/mailman/listinfo/tls 
> 
>  
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents 

Re: [TLS] The future of external PSK in TLS 1.3

[David Benjamin]

It sounds like the registry may be confusing, so perhaps we, independent of
the existing criteria for Y vs N, need to do a better job of presenting the
information. That sounds like an orthogonal issue to whether psk_ke should
be marked as recommended. There are plenty of recommended = N cipher suites
in the registry that went through the IETF process. Security expectations
evolve or we may make mistakes, and this is one tool we have for realigning
things when that happens.

Regarding how psk_ke should be marked, we have already marked the analogous
cipher suite in TLS 1.2, TLS_PSK_WITH_AES_128_GCM_SHA256, as N. There is
indeed a problem with the use of that mode. TLS 1.3 was intended to provide
forward secrecy, and psk_ke does not do so. This is especially problematic
with external PSKs, such as the smartcards folks mentioned, because it
means all traffic hinges on a long-lived shared secret. The one footnote is
that TLS 1.3 uses the same code points for external PSKs and resumption,
and the precedent is less clear for resumption. But TLS 1.2 resumption's
lack of fresh key exchange is a well-documented problem that we happily
fixed with psk_dhe_ke, so I'm perfectly fine extending the status to psk_ke
with resumption.

This is separate from psk_dhe_ke, which is analogous to TLS 1.2's
TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256. That one is still recommended Y. For
that matter, psk_dhe_ke is used in ECDH-ful resumption, so if the WG wants
to say something stronger about external PSKs, we'd need a new values in
that column anyway...

(An aside, psk_dhe_ke and psk_ke are PSK key exchange modes, not cipher
suites.)

On Wed, Sep 23, 2020 at 12:03 PM Hannes Tschofenig <
hannes.tschofe...@arm.com> wrote:

> Hi David,
>
>
>
> my problem is that the IANA registry only says “not recommended” but it
> does not say for what environments these ciphersuites are not recommended.
> Worse, it also wants to indicate whether the specification has gone through
> the IETF process.
>
>
>
> Ciao
>
> Hannes
>
>
>
> *From:* David Benjamin 
> *Sent:* Wednesday, September 23, 2020 5:47 PM
> *To:* Salz, Rich 
> *Cc:* Hannes Tschofenig ; Filippo Valsorda <
> fili...@ml.filippo.io>; Carrick Bartle ;
> tls@ietf.org
> *Subject:* Re: [TLS] The future of external PSK in TLS 1.3
>
>
>
> There are two different code points involved in TLS 1.3 PSK, and I think
> there may be some mixup here:
>
> 1. Whether TLS 1.3 psk_ke should be marked N
>
> 2. Whether TLS 1.3. psk_dhe_ke should be marked N
>
>
>
> Avoiding psk_ke does not remove compatibility with any authentication
> method. psk_ke and psk_dhe_ke use the same PSKs. The difference is whether
> the handshake mixes an additional (EC)DH exchange into the key schedule.
> We've *already* marked TLS_PSK_WITH_AES_128_GCM_SHA256 with an N, so it
> seems to me psk_ke with an external PSK should be similar. Handshakes using
> psk_ke with an external PSK incorporate no secrets in the key exchange
> apart from a (often long-lived) external symmetric secret. Compromise that
> secret, and all traffic ever authenticated with that PSK is compromised.
> Resumption PSKs use short-lived keys, so psk_ke is less immediately
> disastrous but given the equivalent construction in TLS 1.2 has forward
> secrecy issues
> , marking it
> as N across the board seems a good idea to me. (BoringSSL does not
> implement psk_ke for this reason. Looks like Go and NSS do not implement it
> either.)
>
>
>
> psk_dhe_ke I suppose depends on how one interprets "specific use case", so
> I don't feel very strongly here.
>
>
>
> David
>
>
>
> On Wed, Sep 23, 2020 at 11:37 AM Salz, Rich  40akamai@dmarc.ietf.org> wrote:
>
> I agree with Hannes’s reasoning.
>
>
>
> I am also concerned about devolving TLS to be just Web browser/server.
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The future of external PSK in TLS 1.3

[Hannes Tschofenig]

Hi David,

my problem is that the IANA registry only says “not recommended” but it does 
not say for what environments these ciphersuites are not recommended. Worse, it 
also wants to indicate whether the specification has gone through the IETF 
process.

Ciao
Hannes

From: David Benjamin 
Sent: Wednesday, September 23, 2020 5:47 PM
To: Salz, Rich 
Cc: Hannes Tschofenig ; Filippo Valsorda 
; Carrick Bartle ; tls@ietf.org
Subject: Re: [TLS] The future of external PSK in TLS 1.3

There are two different code points involved in TLS 1.3 PSK, and I think there 
may be some mixup here:
1. Whether TLS 1.3 psk_ke should be marked N
2. Whether TLS 1.3. psk_dhe_ke should be marked N

Avoiding psk_ke does not remove compatibility with any authentication method. 
psk_ke and psk_dhe_ke use the same PSKs. The difference is whether the 
handshake mixes an additional (EC)DH exchange into the key schedule. We've 
already marked TLS_PSK_WITH_AES_128_GCM_SHA256 with an N, so it seems to me 
psk_ke with an external PSK should be similar. Handshakes using psk_ke with an 
external PSK incorporate no secrets in the key exchange apart from a (often 
long-lived) external symmetric secret. Compromise that secret, and all traffic 
ever authenticated with that PSK is compromised. Resumption PSKs use 
short-lived keys, so psk_ke is less immediately disastrous but given the 
equivalent construction in TLS 1.2 has forward secrecy 
issues, marking it 
as N across the board seems a good idea to me. (BoringSSL does not implement 
psk_ke for this reason. Looks like Go and NSS do not implement it either.)

psk_dhe_ke I suppose depends on how one interprets "specific use case", so I 
don't feel very strongly here.

David

On Wed, Sep 23, 2020 at 11:37 AM Salz, Rich 
mailto:40akamai@dmarc.ietf.org>> wrote:
I agree with Hannes’s reasoning.

I am also concerned about devolving TLS to be just Web browser/server.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The future of external PSK in TLS 1.3

[David Benjamin]

There are two different code points involved in TLS 1.3 PSK, and I think
there may be some mixup here:
1. Whether TLS 1.3 psk_ke should be marked N
2. Whether TLS 1.3. psk_dhe_ke should be marked N

Avoiding psk_ke does not remove compatibility with any authentication
method. psk_ke and psk_dhe_ke use the same PSKs. The difference is whether
the handshake mixes an additional (EC)DH exchange into the key schedule.
We've *already* marked TLS_PSK_WITH_AES_128_GCM_SHA256 with an N, so it
seems to me psk_ke with an external PSK should be similar. Handshakes using
psk_ke with an external PSK incorporate no secrets in the key exchange
apart from a (often long-lived) external symmetric secret. Compromise that
secret, and all traffic ever authenticated with that PSK is compromised.
Resumption PSKs use short-lived keys, so psk_ke is less immediately
disastrous but given the equivalent construction in TLS 1.2 has forward
secrecy issues ,
marking it as N across the board seems a good idea to me. (BoringSSL does
not implement psk_ke for this reason. Looks like Go and NSS do not
implement it either.)

psk_dhe_ke I suppose depends on how one interprets "specific use case", so
I don't feel very strongly here.

David

On Wed, Sep 23, 2020 at 11:37 AM Salz, Rich  wrote:

> I agree with Hannes’s reasoning.
>
>
>
> I am also concerned about devolving TLS to be just Web browser/server.
>
>
> ___
> 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] The future of external PSK in TLS 1.3

[Salz, Rich]

I agree with Hannes’s reasoning.

I am also concerned about devolving TLS to be just Web browser/server.

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

Re: [TLS] The future of external PSK in TLS 1.3

[Hannes Tschofenig]

Hi Filippo,

I worry that labelling ciphersuites that is deployed in parts of the industry 
as “not recommended” will confuse those who look at the IANA website.

Only those readers who look at the note will then learn that not recommended 
means three things, whereby the option "has not been through the IETF consensus 
process" should not give readers great confidence either.

I hope this explains my concern.

There is no problem with the use of these PSK ciphersuites, so why mark them as 
“not recommended”?

Ciao
Hannes

From: Filippo Valsorda 
Sent: Wednesday, September 23, 2020 3:39 PM
To: Hannes Tschofenig ; Carrick Bartle 

Cc: tls@ietf.org
Subject: Re: [TLS] The future of external PSK in TLS 1.3

2020-09-23 13:49 GMT+02:00 Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>>:

Hi Carrick,



you note that SCADA is a pretty specific use case. SCADA sounds specific but 
TLS is used widely in the IoT market. It is even used in devices that use smart 
cards, which use TLS with PSK to protect their provisioning protocol.



I am worried that marking a ciphersuite as N with the meaning that it "has not 
been through the IETF consensus process, has limited applicability, or is 
intended only for specific use cases" is hard for readers to understand which 
of these three cases were actually the reason for marking it as “N”. The "has 
not been through the IETF consensus process" will scare off many people.



For most people the web is the generic case and everything else is a “specific 
use case”. Sure, the web is very important but TLS is a generic protocol used 
in many environments.

By this reasoning, what is a specific use case? My interpretation is "anything 
you shouldn't use unless you have specific requirements". Compatibility with 
smart cards is clearly a specific requirement, and you should definitely use an 
ECDH PSK if you can. What's your interpretation?

The average user of OpenSSL or BoringSSL or LibreSSL or Go crypto/tls or NSS or 
Java doesn't do SCADA, doesn't do IoT, doesn't do smart cards, regardless of 
whether they talk to browsers or other services.


I don’t understand John’s motivation. The LAKE group makes a decision to remove 
PSK support. That’s good for them. Does this imply that the TLS group also 
needs to make the same decision?

(Again, no one is suggesting dropping anything, as far as I can tell.)


Ciao

Hannes


From: Carrick Bartle mailto:cbartle...@icloud.com>>
Sent: Monday, September 21, 2020 6:19 PM
To: Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>>
Cc: Carrick Bartle 
mailto:cbartle891=40icloud@dmarc.ietf.org>>;
 Filippo Valsorda mailto:fili...@ml.filippo.io>>; 
tls@ietf.org
Subject: Re: [TLS] The future of external PSK in TLS 1.3



Can you justify your reasoning?



Which part?




On Sep 21, 2020, at 2:22 AM, Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:



Hi Carrick,



Can you justify your reasoning?



The challenge I have with the work on IoT in the IETF that the preferences for 
pretty much everything changes on a regular basis.



I don’t see a problem that requires a change. In fact, I have just posted a 
mail to the UTA list that gives an overview of the implementation status of 
embedded TLS stacks and PSK-based ciphersuites are widely implemented.



Ciao

Hannes


From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of 
Carrick Bartle
Sent: Monday, September 21, 2020 5:31 AM
To: Filippo Valsorda mailto:fili...@ml.filippo.io>>
Cc: tls@ietf.org
Subject: Re: [TLS] The future of external PSK in TLS 1.3



I'm also fine with marking psk_ke as not recommended to be consistent with the 
non-PFS ciphers, but there are plenty of valid use cases that justify keeping 
dhe_psk_ke as recommended for external PSKs. Several of these use cases are 
detailed in draft-ietf-tls-external-psk-guidance-00.







On Sep 19, 2020, at 9:00 AM, Filippo Valsorda 
mailto:fili...@ml.filippo.io>> wrote:



2020-09-19 13:48 GMT+02:00 Peter Gutmann 
mailto:pgut...@cs.auckland.ac.nz>>:

John Mattsson 
mailto:40ericsson@dmarc.ietf.org>>
 writes:



>Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and

>especially psk_ke are both marked as RECOMMENDED. If used in the initial

>handshake, both modes have severe privacy problems,



PSK is used a fair bit in SCADA.  There are no privacy problems there.  So

just because there's a concern for one specific environment doesn't mean it

should be banned for any use.  In particular, I think if a specific industry

has a particular concern, they should profile it for use in that industry but

not require that everyone else change their behaviour.



Indeed, if the SCADA industry has a particular need, they should profile TLS 
for use in that industry, and not require we change the recommendation for the 
open Internet.



Setting Recommended to N is not "banning" anything, it's saying it "has not 
been through the IETF consensus process, has 

Re: [TLS] The future of external PSK in TLS 1.3

[David Woodhouse]

On Sat, 2020-09-19 at 11:30 +, John Mattsson wrote:
> Hi,
> 
> Recent discussions in 3GPP, ACE, and LAKE about the use of symmetric
> keys for authentication and key exchange made me think about the
> future role of external PSK in TLS.
> 
> https://mailarchive.ietf.org/arch/msg/ace/A60CFIvUohBwAXi_JuMKkQanZak/
> 
> I authored RFC 8442 because I believe PSK+ECDHE is needed for legacy
> systems. Due to the major privacy, security, and deployment
> limitations with PSK, I see little need to use PSK (besides
> resumption) in new systems, except for the use case in RFC 8773.

Some VPN protocols (e.g. Cisco AnyConnect) attempt to establish a DTLS
session in parallel with an existing TLS session, to avoid TCP-over-TCP 
where possible.

Cisco does it by fabricating a DTLS session (details exchanged over the
existing authenticated TLS channel) and then "resuming" it. Using this
method, the DTLS protocol version and all options are hard-coded when
the session is fabricated. This makes me sad.

In the open source implementation of client/server we have extended the
protocol to exchange a PSK over the existing TLS session, then
negotiate DTLS the "normal" way using that PSK.

That's a lot cleaner (IMO) and seems like a valid use case for PSK.



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

Re: [TLS] The future of external PSK in TLS 1.3

[Filippo Valsorda]

2020-09-23 13:49 GMT+02:00 Hannes Tschofenig :
> Hi Carrick,

>  

> you note that SCADA is a pretty specific use case. SCADA sounds specific but 
> TLS is used widely in the IoT market. It is even used in devices that use 
> smart cards, which use TLS with PSK to protect their provisioning protocol.

>  

> I am worried that marking a ciphersuite as N with the meaning that it "has 
> not been through the IETF consensus process, has limited applicability, or is 
> intended only for specific use cases" is hard for readers to understand which 
> of these three cases were actually the reason for marking it as “N”. The "has 
> not been through the IETF consensus process" will scare off many people.

>  

> For most people the web is the generic case and everything else is a 
> “specific use case”. Sure, the web is very important but TLS is a generic 
> protocol used in many environments.  


By this reasoning, what is a specific use case? My interpretation is "anything 
you shouldn't use unless you have specific requirements". Compatibility with 
smart cards is clearly a specific requirement, and you should definitely use an 
ECDH PSK if you can. What's your interpretation?

The average user of OpenSSL or BoringSSL or LibreSSL or Go crypto/tls or NSS or 
Java doesn't do SCADA, doesn't do IoT, doesn't do smart cards, regardless of 
whether they talk to browsers or other services.

> I don’t understand John’s motivation. The LAKE group makes a decision to 
> remove PSK support. That’s good for them. Does this imply that the TLS group 
> also needs to make the same decision?


(Again, no one is suggesting dropping anything, as far as I can tell.)

> Ciao

> Hannes

>  


> *From:* Carrick Bartle  
> *Sent:* Monday, September 21, 2020 6:19 PM
> *To:* Hannes Tschofenig 
> *Cc:* Carrick Bartle ; Filippo 
> Valsorda ; tls@ietf.org
> *Subject:* Re: [TLS] The future of external PSK in TLS 1.3

>  

>> Can you justify your reasoning? 

>  

> Which part?

>  


> 

>> On Sep 21, 2020, at 2:22 AM, Hannes Tschofenig  
>> wrote:

>>  

>> Hi Carrick, 

>>  

>> Can you justify your reasoning? 

>>  

>> The challenge I have with the work on IoT in the IETF that the preferences 
>> for pretty much everything changes on a regular basis.

>>  

>> I don’t see a problem that requires a change. In fact, I have just posted a 
>> mail to the UTA list that gives an overview of the implementation status of 
>> embedded TLS stacks and PSK-based ciphersuites are widely implemented.  

>>  

>> Ciao

>> Hannes

>>  


>> *From:* TLS  *On Behalf Of *Carrick Bartle
>> *Sent:* Monday, September 21, 2020 5:31 AM
>> *To:* Filippo Valsorda 
>> *Cc:* tls@ietf.org
>> *Subject:* Re: [TLS] The future of external PSK in TLS 1.3

>>  

>> I'm also fine with marking psk_ke as not recommended to be consistent with 
>> the non-PFS ciphers, but there are plenty of valid use cases that justify 
>> keeping dhe_psk_ke as recommended for external PSKs. Several of these use 
>> cases are detailed in draft-ietf-tls-external-psk-guidance-00.

>>  

>>  

>>  

>>> On Sep 19, 2020, at 9:00 AM, Filippo Valsorda  wrote:

>>>  

>>> 2020-09-19 13:48 GMT+02:00 Peter Gutmann :

 John Mattsson  writes:

  

 >Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke 
 >and

 >especially psk_ke are both marked as RECOMMENDED. If used in the initial

 >handshake, both modes have severe privacy problems,

  

 PSK is used a fair bit in SCADA.  There are no privacy problems there.  So

 just because there's a concern for one specific environment doesn't mean it

 should be banned for any use.  In particular, I think if a specific 
 industry

 has a particular concern, they should profile it for use in that industry 
 but

 not require that everyone else change their behaviour.

>>>  

>>> Indeed, if the SCADA industry has a particular need, they should profile 
>>> TLS for use in that industry, and not require we change the recommendation 
>>> for the open Internet.

>>>  

>>> Setting Recommended to N is not "banning" anything, it's saying it "has not 
>>> been through the IETF consensus process, has limited applicability, or is 
>>> intended only for specific use cases". SCADA sounds like a pretty specific 
>>> use case.

>>>  

>>> I don't have a strong opinion on psk_dhe_ke, but I see no reason psk_ke 
>>> wouldn't be marked N like all suites lacking PFS.

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

>>  

>> IMPORTANT NOTICE: The contents of this email and any attachments are 
>> confidential and may also be privileged. If you are not the intended 
>> recipient, please notify the sender immediately and do not disclose the 
>> contents to any other person, use it for any purpose, or store or copy the 
>> information in any medium. Thank you. 
>> ___
>> TLS 

Re: [TLS] Obsolete SCSV!? (was Re: AD review of draft-ietf-tls-oldversions-deprecate-06)

[Salz, Rich]

Not to bury the lead or anything, but posting detailed analysis at 5:43am?  We 
can guess that you’re not in a different timezone…

Sure, looks fine to me.

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

Re: [TLS] Obsolete SCSV!? (was Re: AD review of draft-ietf-tls-oldversions-deprecate-06)

[Eric Rescorla]

I am completely indifferent on Updates versus Obsoletes (Indeed, this
discussion seems like more support for my argument that we should get rid
of the
distinction). With that said, I believe that this analysis is broadly
correct.

To recap the situation as I understand it:
TLS always provided anti-version downgrade defenses because the Finished
message covers the version negotiation [0]. However, the version fallback
mechanism involved generating a new handshake without the (potentially)
incompatible version, thus was not subject to the Finished check. The SCSV
was an anti-downgrade mechanism (essentially a version signal) which could
be sent in the new handshake, thus being subject to the Finished check.

TLS 1.3 provides an alternate mechanism for the case where the server
speaks TLS 1.3 but the client/server pair negotiate < 1.3. Thus, in the
world where the only valid values of TLS are 1.2 and 1.3+, then this
mechanism should render the SCSV unnecessary.

-Ekr






On Wed, Sep 23, 2020 at 5:43 AM Sean Turner  wrote:

> Hi! this issue was buried in the Ben’s review, but I think it is worth
> getting some attention on.
>
> > On Aug 13, 2020, at 13:54, Benjamin Kaduk  wrote:
> >
> > On Wed, Aug 12, 2020 at 04:29:56PM -0400, Kathleen Moriarty wrote:
> >>
> >> On Sun, Jul 26, 2020 at 5:22 PM Benjamin Kaduk  wrote:
> >>>
> >>> - Similarly, the downgrade protection provided by the SCSV of RFC 7507
> >>>  seems to be entirely obsolete.  Any implementation that is compliant
> >>>  with this document will support only 1.2 or higher.  If it only
> >>>  supports one version, no downgrade is possible; if it also supports
> >>>  1.3 or newer, the new downgrade-detection mechanism defined by TLS 1.3
> >>>  applies, so the SCSV mechanism is entirely redundant (i.e., obsolete).
> >>>  We could effectuate that status change in this document as well.
> >>>
> >>
> >> Has this been addressed in RFC8446?  If not, the specific downgrade
> >> examples are just listed as examples.  If a gap is left, then the full
> >> document should not be deprecated and made obsolete.  The text infers
> other
> >> versions in my read.  I have not looked to see if this was addressed in
> >> RFC8446 yet though.
> >
> > I'd really like to get a few more people to weigh in on this one -- IIRC
> > David Benjamin and Martin Thomson had mentioned some thoughts in the chat
> > during the session at 108, and Ekr as author of 8446 would be expected to
> > have a good sense of what it does.
> >
> > The specific RFC 8446 mechanism here is described at
> > https://tools.ietf.org/html/rfc8446#section-4.1.3 : "TLS 1.3 has a
> > downgrade protection mechanism embedded in the server's random value.
> > [...]"
> >
> > While the RFC 8446 mechanism has the client do the actual detection of
> > downgrade, there's a MUST-level requirement on clients to make the check,
> > so from a specification point of view the check can be treated as
> reliable.
> > The RFC 7507 mechanism has the server do the detection, but I think the
> end
> > result is still the same: in an "downgraded" exchange between two honest
> > participants, the handshake fails and the downgrade is detected.
> >
> > Since the functionality is still useful, just superseded, this one seems
> > like a better fit for "obsoletes" (vs. "historic).
> >
>
> Right now, we have a list of RFCs draft-ietf-tls-oldversions-deprecate
> will update. RFC 7507 "TLS Fallback Signaling Cipher Suite Value (SCSV) for
> Preventing Protocol Downgrade Attacks" (
> https://datatracker.ietf.org/doc/rfc7507/) is in this list. If you agree
> with Ben’s logic then we would be move 7507 out of the list of “updates”
> and adding an obsoletes header, i.e., “Obsoletes: 7507 (if approved)”, and
> moving 7507 down in s1.1 to the obsoletes paragraph. While this might seem
> like a minor point, this is the kind of the IESG loves to sink its teeth
> into so have a WG opinion on this matter can make overcoming later hurdles
> easier for the AD and doc shepherd.
>
> Thanks for the your time,
>
> spt (doc shepherd)
> ___
> 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

[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] The future of external PSK in TLS 1.3

[Blumenthal, Uri - 0553 - MITLL]

I sincerely hope that the TLS group will NOT make the same decision [as LAKE - 
to drop PSK].

Regards,
Uri

> On Sep 23, 2020, at 07:50, Hannes Tschofenig  
> wrote:
> 
> 
> Hi Carrick,
>  
> you note that SCADA is a pretty specific use case. SCADA sounds specific but 
> TLS is used widely in the IoT market. It is even used in devices that use 
> smart cards, which use TLS with PSK to protect their provisioning protocol.
>  
> I am worried that marking a ciphersuite as N with the meaning that it "has 
> not been through the IETF consensus process, has limited applicability, or is 
> intended only for specific use cases" is hard for readers to understand which 
> of these three cases were actually the reason for marking it as “N”. The "has 
> not been through the IETF consensus process" will scare off many people.
>  
> For most people the web is the generic case and everything else is a 
> “specific use case”. Sure, the web is very important but TLS is a generic 
> protocol used in many environments.  
>  
> I don’t understand John’s motivation. The LAKE group makes a decision to 
> remove PSK support. That’s good for them. Does this imply that the TLS group 
> also needs to make the same decision?
>  
> Ciao
> Hannes
>  
> From: Carrick Bartle  
> Sent: Monday, September 21, 2020 6:19 PM
> To: Hannes Tschofenig 
> Cc: Carrick Bartle ; Filippo Valsorda 
> ; tls@ietf.org
> Subject: Re: [TLS] The future of external PSK in TLS 1.3
>  
> Can you justify your reasoning? 
>  
> Which part?
>  
> 
> 
> On Sep 21, 2020, at 2:22 AM, Hannes Tschofenig  
> wrote:
>  
> Hi Carrick, 
>  
> Can you justify your reasoning? 
>  
> The challenge I have with the work on IoT in the IETF that the preferences 
> for pretty much everything changes on a regular basis.
>  
> I don’t see a problem that requires a change. In fact, I have just posted a 
> mail to the UTA list that gives an overview of the implementation status of 
> embedded TLS stacks and PSK-based ciphersuites are widely implemented.  
>  
> Ciao
> Hannes
>  
> From: TLS  On Behalf Of Carrick Bartle
> Sent: Monday, September 21, 2020 5:31 AM
> To: Filippo Valsorda 
> Cc: tls@ietf.org
> Subject: Re: [TLS] The future of external PSK in TLS 1.3
>  
> I'm also fine with marking psk_ke as not recommended to be consistent with 
> the non-PFS ciphers, but there are plenty of valid use cases that justify 
> keeping dhe_psk_ke as recommended for external PSKs. Several of these use 
> cases are detailed in draft-ietf-tls-external-psk-guidance-00.
>  
>  
>  
> On Sep 19, 2020, at 9:00 AM, Filippo Valsorda  wrote:
>  
> 2020-09-19 13:48 GMT+02:00 Peter Gutmann :
> John Mattsson  writes:
>  
> >Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and
> >especially psk_ke are both marked as RECOMMENDED. If used in the initial
> >handshake, both modes have severe privacy problems,
>  
> PSK is used a fair bit in SCADA.  There are no privacy problems there.  So
> just because there's a concern for one specific environment doesn't mean it
> should be banned for any use.  In particular, I think if a specific industry
> has a particular concern, they should profile it for use in that industry but
> not require that everyone else change their behaviour.
>  
> Indeed, if the SCADA industry has a particular need, they should profile TLS 
> for use in that industry, and not require we change the recommendation for 
> the open Internet.
>  
> Setting Recommended to N is not "banning" anything, it's saying it "has not 
> been through the IETF consensus process, has limited applicability, or is 
> intended only for specific use cases". SCADA sounds like a pretty specific 
> use case.
>  
> I don't have a strong opinion on psk_dhe_ke, but I see no reason psk_ke 
> wouldn't be marked N like all suites lacking PFS.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>  
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you. 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>  
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you. 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


smime.p7s
Description: S/MIME cryptographic signature
___
TLS 

[TLS] Obsolete SCSV!? (was Re: AD review of draft-ietf-tls-oldversions-deprecate-06)

[Sean Turner]

Hi! this issue was buried in the Ben’s review, but I think it is worth getting 
some attention on.

> On Aug 13, 2020, at 13:54, Benjamin Kaduk  wrote:
> 
> On Wed, Aug 12, 2020 at 04:29:56PM -0400, Kathleen Moriarty wrote:
>> 
>> On Sun, Jul 26, 2020 at 5:22 PM Benjamin Kaduk  wrote:
>>> 
>>> - Similarly, the downgrade protection provided by the SCSV of RFC 7507
>>>  seems to be entirely obsolete.  Any implementation that is compliant
>>>  with this document will support only 1.2 or higher.  If it only
>>>  supports one version, no downgrade is possible; if it also supports
>>>  1.3 or newer, the new downgrade-detection mechanism defined by TLS 1.3
>>>  applies, so the SCSV mechanism is entirely redundant (i.e., obsolete).
>>>  We could effectuate that status change in this document as well.
>>> 
>> 
>> Has this been addressed in RFC8446?  If not, the specific downgrade
>> examples are just listed as examples.  If a gap is left, then the full
>> document should not be deprecated and made obsolete.  The text infers other
>> versions in my read.  I have not looked to see if this was addressed in
>> RFC8446 yet though.
> 
> I'd really like to get a few more people to weigh in on this one -- IIRC
> David Benjamin and Martin Thomson had mentioned some thoughts in the chat
> during the session at 108, and Ekr as author of 8446 would be expected to
> have a good sense of what it does.  
> 
> The specific RFC 8446 mechanism here is described at
> https://tools.ietf.org/html/rfc8446#section-4.1.3 : "TLS 1.3 has a
> downgrade protection mechanism embedded in the server's random value.
> [...]"
> 
> While the RFC 8446 mechanism has the client do the actual detection of
> downgrade, there's a MUST-level requirement on clients to make the check,
> so from a specification point of view the check can be treated as reliable.
> The RFC 7507 mechanism has the server do the detection, but I think the end
> result is still the same: in an "downgraded" exchange between two honest
> participants, the handshake fails and the downgrade is detected.
> 
> Since the functionality is still useful, just superseded, this one seems
> like a better fit for "obsoletes" (vs. "historic).
> 

Right now, we have a list of RFCs draft-ietf-tls-oldversions-deprecate will 
update. RFC 7507 "TLS Fallback Signaling Cipher Suite Value (SCSV) for 
Preventing Protocol Downgrade Attacks" 
(https://datatracker.ietf.org/doc/rfc7507/) is in this list. If you agree with 
Ben’s logic then we would be move 7507 out of the list of “updates” and adding 
an obsoletes header, i.e., “Obsoletes: 7507 (if approved)”, and moving 7507 
down in s1.1 to the obsoletes paragraph. While this might seem like a minor 
point, this is the kind of the IESG loves to sink its teeth into so have a WG 
opinion on this matter can make overcoming later hurdles easier for the AD and 
doc shepherd.

Thanks for the your time,

spt (doc shepherd)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] The future of external PSK in TLS 1.3

[Hannes Tschofenig]

Hi Carrick,

you note that SCADA is a pretty specific use case. SCADA sounds specific but 
TLS is used widely in the IoT market. It is even used in devices that use smart 
cards, which use TLS with PSK to protect their provisioning protocol.

I am worried that marking a ciphersuite as N with the meaning that it "has not 
been through the IETF consensus process, has limited applicability, or is 
intended only for specific use cases" is hard for readers to understand which 
of these three cases were actually the reason for marking it as “N”. The "has 
not been through the IETF consensus process" will scare off many people.

For most people the web is the generic case and everything else is a “specific 
use case”. Sure, the web is very important but TLS is a generic protocol used 
in many environments.

I don’t understand John’s motivation. The LAKE group makes a decision to remove 
PSK support. That’s good for them. Does this imply that the TLS group also 
needs to make the same decision?

Ciao
Hannes

From: Carrick Bartle 
Sent: Monday, September 21, 2020 6:19 PM
To: Hannes Tschofenig 
Cc: Carrick Bartle ; Filippo Valsorda 
; tls@ietf.org
Subject: Re: [TLS] The future of external PSK in TLS 1.3

Can you justify your reasoning?

Which part?



On Sep 21, 2020, at 2:22 AM, Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:

Hi Carrick,

Can you justify your reasoning?

The challenge I have with the work on IoT in the IETF that the preferences for 
pretty much everything changes on a regular basis.

I don’t see a problem that requires a change. In fact, I have just posted a 
mail to the UTA list that gives an overview of the implementation status of 
embedded TLS stacks and PSK-based ciphersuites are widely implemented.

Ciao
Hannes

From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of 
Carrick Bartle
Sent: Monday, September 21, 2020 5:31 AM
To: Filippo Valsorda mailto:fili...@ml.filippo.io>>
Cc: tls@ietf.org
Subject: Re: [TLS] The future of external PSK in TLS 1.3

I'm also fine with marking psk_ke as not recommended to be consistent with the 
non-PFS ciphers, but there are plenty of valid use cases that justify keeping 
dhe_psk_ke as recommended for external PSKs. Several of these use cases are 
detailed in draft-ietf-tls-external-psk-guidance-00.



On Sep 19, 2020, at 9:00 AM, Filippo Valsorda 
mailto:fili...@ml.filippo.io>> wrote:

2020-09-19 13:48 GMT+02:00 Peter Gutmann 
mailto:pgut...@cs.auckland.ac.nz>>:
John Mattsson 
mailto:40ericsson@dmarc.ietf.org>>
 writes:

>Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and
>especially psk_ke are both marked as RECOMMENDED. If used in the initial
>handshake, both modes have severe privacy problems,

PSK is used a fair bit in SCADA.  There are no privacy problems there.  So
just because there's a concern for one specific environment doesn't mean it
should be banned for any use.  In particular, I think if a specific industry
has a particular concern, they should profile it for use in that industry but
not require that everyone else change their behaviour.

Indeed, if the SCADA industry has a particular need, they should profile TLS 
for use in that industry, and not require we change the recommendation for the 
open Internet.

Setting Recommended to N is not "banning" anything, it's saying it "has not 
been through the IETF consensus process, has limited applicability, or is 
intended only for specific use cases". SCADA sounds like a pretty specific use 
case.

I don't have a strong opinion on psk_dhe_ke, but I see no reason psk_ke 
wouldn't be marked N like all suites lacking PFS.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you. ___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
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