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

Hi Ben,

Please see inline

On Tue, 22 Sep 2020 at 20:45, Ben Schwartz <bemasc@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 <kondtir@gmail.com> wrote:
>
>> On Sun, 20 Sep 2020 at 14:05, Eliot Lear <lear@cisco.com> wrote:
>>
>>>
>>>
>>> > On 11 Sep 2020, at 12:40, Nick Lamb <njl@tlrmx.org> wrote:
>>> >
>>> > On Fri, 11 Sep 2020 12:32:03 +0530
>>> > tirumal reddy <kondtir@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
>>
>