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

[Eric Rescorla <[e-mail]>]

On Wed, Sep 23, 2020 at 2:51 AM tirumal reddy <[e-mail]> wrote:

> Hi Ben,
>
> Please see inline
>
> On Tue, 22 Sep 2020 at 20:45, Ben Schwartz <[e-mail]> 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.
>

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
change their software which may involve introducing some new parser for
that feature, then I can publish a policy, and it works.

Option (2) is going to take much longer to happen than option (1).
Depending on how slow the vendors are, it could be indefinitely long. Given
that it's often not viable to roll out new networking features if they
introduce any significantly increased risk of failure, this seems like a
recipe for ossification.

-Ekr


> Cheers,
> -Tiru
>
>
>>
>> On Tue, Sep 22, 2020 at 7:34 AM tirumal reddy <[e-mail]> wrote:
>>
>>> 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
>>> _______________________________________________
>>> TLS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>