Re: [OPSAWG] [TLS] 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: [OPSAWG] [TLS] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

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 han

Re: [OPSAWG] [TLS] 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: [OPSAWG] [TLS] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

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 malwa

Re: [OPSAWG] [TLS] 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: [OPSAWG] [TLS] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

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

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

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 ver

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

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 ment

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

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 p

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

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 h

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

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 ver

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

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 t

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

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 b

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

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 a

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

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 stereotype

Re: [OPSAWG] [TLS] 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: [OPSAWG] [TLS] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

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

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

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 t

Re: [OPSAWG] [TLS] 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: [OPSAWG] [TLS] 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: [OPSAWG] [TLS] 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: [OPSAWG] [TLS] 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

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

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 author

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

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 provide