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 <kond...@gmail.com> wrote: > On Sun, 20 Sep 2020 at 14:05, Eliot Lear <l...@cisco.com> wrote: > >> >> >> > On 11 Sep 2020, at 12:40, Nick Lamb <n...@tlrmx.org> wrote: >> > >> > On Fri, 11 Sep 2020 12:32:03 +0530 >> > tirumal reddy <kond...@gmail.com> 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
