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

Eric Rescorla <ekr@rtfm.com> Wed, 23 September 2020 12:52 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42ADE3A10C1 for <opsawg@ietfa.amsl.com>; Wed, 23 Sep 2020 05:52:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-8dh0EdhhgD for <opsawg@ietfa.amsl.com>; Wed, 23 Sep 2020 05:52:03 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E34B43A0FC7 for <opsawg@ietf.org>; Wed, 23 Sep 2020 05:52:02 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id u4so17119520ljd.10 for <opsawg@ietf.org>; Wed, 23 Sep 2020 05:52:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=exnzvqsd6Mn2wejjgLgv0ujCB6/tmbEf2WNfRZPWdk8=; b=XT/giWGRTTD8TbvEm/vnZDOrFUQ3EOIlg8lOxa3FmPXP5R7eMxj8u7AoU96yYx3C3F cuWFTKWjLRVpw7aFseJ29VnIbzWQ/xyUra2x3TeYPNZrPIFMwU7FKFAMnpdTxkO1/lEe dcqKcs6dVah69tExdSTjPK4xnSqNRRldMtZRy96F28zYo6dFh0ste5AT5ARW9Xv9JFbk QSZ1y1r6vV0Q70HwF+uCELwbZcLoUVfkNFwN2l2zkUx+ckOOtqau+6bBYAFmm0f+cU7b 6TQXz145RVX96Ve65hy8ZDFP3f4ocWYw9rJqfgmP/QMtw4wP980Co+3RZ31aVzJMST4y 7lMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=exnzvqsd6Mn2wejjgLgv0ujCB6/tmbEf2WNfRZPWdk8=; b=TJuJ32N06+NgPmHU7/Ip4FlT+4JLfPpUVTzyvxnXTI+1vLIIHzS2ykLU1TTh07E16j aAxCLvHe9YFmqgY0vFWhsbLjvcA0XR3uRS7gVhmKpG8fKSgUep1Q9G6ke3dJcULOGLWD khR+RXU63PafkRMeE/I798eoOEm43hf6GcGs3x8p//xTfI1OLC4piXOoaS497Iw+Qzvc R9XwXmA+yGxo4EKll5r1aC4FQQuYWm+TsaOPmOetzGKWm3yHqx2Ipb6GVju04JHCE7Uh /eWfl1qgvDFsSNFonGhObURLvfDD1f5d4gf7RsnyDfM1oFI3e9SC/HFUqHmO3sZPSaE4 dvag==
X-Gm-Message-State: AOAM5312udgRZGBdhq+WhdUmwdPVGPTq7w680bHoh+kw6x7KBNA6OziT qQk7dydn+0lDYRmKK46MaPHfZudsGmy9cIFnPxEMLw==
X-Google-Smtp-Source: ABdhPJwXFivEl4b8Jz4tb5mzMIwjtwrShZRs1NiNSv54xPAQAsydA/WYhywAcZoDIsM4dp6DvulF5ojM3VcXh1zVYY8=
X-Received: by 2002:a2e:8114:: with SMTP id d20mr3060879ljg.409.1600865521069; Wed, 23 Sep 2020 05:52:01 -0700 (PDT)
MIME-Version: 1.0
References: <21BA8D05-DD83-44DE-81B9-457692484CAD@cisco.com> <053b286e-4780-1818-a79d-71b9c967bbd2@sandelman.ca> <CAHbrMsANEA4omTm5dPYLN9zGde2YdT_71ujpBcCEer_xSkPhbw@mail.gmail.com> <CAFpG3gepojPJoK8W+o9Qr66gPSUqHY+sDX-v+-fuwcM9Y56C_g@mail.gmail.com> <20200911114054.184988dc@totoro.tlrmx.org> <FF4995F8-53F1-450B-A305-A095A7BAE057@cisco.com> <CAFpG3gcS951QfTZb+qFstjnBxfxP54B=VDSSPP3xyP3dtuabQg@mail.gmail.com> <CAHbrMsD5qj2ovcUVMRYStXN01RiX2RiJ+N8cakeGPH3wU2nqBQ@mail.gmail.com> <CAFpG3gd9OTZexW9_XCmeO-2uBc8OcVx5HJzs1Qq-zR8zAbnmGg@mail.gmail.com>
In-Reply-To: <CAFpG3gd9OTZexW9_XCmeO-2uBc8OcVx5HJzs1Qq-zR8zAbnmGg@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 23 Sep 2020 05:51:24 -0700
Message-ID: <CABcZeBMdra=1Rhum7ky1sj_AnNbK7GOJzKJNMZJvQJtfgGe_cg@mail.gmail.com>
To: tirumal reddy <kondtir@gmail.com>
Cc: Ben Schwartz <bemasc@google.com>, opsawg <opsawg@ietf.org>, "<tls@ietf.org>" <tls@ietf.org>, Eliot Lear <lear@cisco.com>
Content-Type: multipart/alternative; boundary="000000000000b7837005affa8c3f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/cnajXduLkYyZypEK_rQv5Ea-BA0>
Subject: Re: [OPSAWG] [TLS] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Sep 2020 12:52:05 -0000

On Wed, Sep 23, 2020 at 2:51 AM tirumal reddy <kondtir@gmail.com> wrote:

> 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.
>

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 <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
>>>
>> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>