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

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

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

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)

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

> 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

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

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

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] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

Hi there IESG I support the intent of this document, and I think the approach to update the various documents listed is the right one. Because of the breadth of documents updated, I wonder if at least some implementation guidance is warranted, in order to assist developers and even perhaps adm

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

It is incredibly difficult to draw a line so precisely as to where the threat to a device begins and ends, given the wide range of deployment scenarios. If a device can be at all critical (and even if it isn’t), then it should be upgraded or replaced. Better that this be out there in its curre

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

> On 2 Dec 2020, at 11:37, Peter Gutmann wrote: > > Eliot Lear writes: > >> If a device can be at all critical (and even if it isn’t), then it should be >> upgraded or replaced. > > The fact that many of these devices are extremely critical is precisely w

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

> On 2 Dec 2020, at 11:44, Peter Gutmann wrote: > > > It's actually the complete opposite, they will have every difficulty in doing > so. You've got systems engineers whose job it is to keep things running at > all costs, or where the effort to replace/upgrade is almost insurmountable, > who

Re: [TLS] [Last-Call] Last Call: (Deprecating TLSv1.0 and TLSv1.1) to Best Current Practice

HI Bill, > On 2 Dec 2020, at 17:22, Bill Frantz wrote: > > On 12/2/20 at 5:37 AM, pgut...@cs.auckland.ac.nz (Peter Gutmann) wrote: > >> The fact that many of these devices are extremely critical is precisely why >> they're never replaced or upgraded, because they can't be taken out of >> produ

Re: [TLS] [T2TRG] ITDA - IoT Device Authentication

Just to add- this is what the plethora of BRSKI drafts are attempting to address in 6tisch, ANIMA, and EMU. If there is to be a new mechanism, I encourage that it be listed on the GitHub page at https://github.com/iot-onboarding/catalog . Both the RE

[TLS] Fwd: Last Call: (TLS 1.2 is in Feature Freeze) to Informational RFC

Rich, Keep in mind, draft-gutmann-tls-lts is under consideration as an independent submission right now.  If it's not the intent of the IETF to create a conflict with regard to that draft, then my suggestion is a statement in Section 1 along the following lines: “The policy specified in this

[TLS] Re: The TLS-LTS Saga

RFC 4846 states that you may ask the IAB to review the ISE's decision.  If they choose to do so (they don't have to), they may advise the ISE to reconsider.  You are welcome to use this route.  If the IAB does advise me to reconsider, I certainly will do so.  I have made mistakes before. Eliot