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

[tirumal reddy <[e-mail]>]

On Sun, 20 Sep 2020 at 14:05, Eliot Lear <[e-mail]> wrote:

>
>
> > On 11 Sep 2020, at 12:40, Nick Lamb <[e-mail]> wrote:
> >
> > On Fri, 11 Sep 2020 12:32:03 +0530
> > tirumal reddy <[e-mail]> 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