Hi Ben, Please see inline
On Tue, 22 Sep 2020 at 20:45, Ben Schwartz <bem...@google.com> 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 <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 >> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
