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

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 M

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

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 extens

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

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 me

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

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

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

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

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

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

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

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-

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

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

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 protoco

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

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/A60CFIvUohB

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

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 throu

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

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

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

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

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

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

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 sui

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

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 i

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

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 c