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

Ben Schwartz <> Tue, 15 September 2020 12:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C9E193A0F5A for <>; Tue, 15 Sep 2020 05:58:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NNzvrXAosw12 for <>; Tue, 15 Sep 2020 05:58:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A34253A09BB for <>; Tue, 15 Sep 2020 05:58:47 -0700 (PDT)
Received: by with SMTP id x2so2914310ilm.0 for <>; Tue, 15 Sep 2020 05:58:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hcmsYiCQXikwHHxC/EGKHSvwl//q0ew72VpgHK+MxL4=; b=IdnaxO6qftwIPizV66gdoUULSrQmlSVpqPQjWz2W/nLhZhlYXFFJUS7Y+CVEZuy4r2 HnpyOWzVDZwawFAiMjVwMEKzR9KqCnT36bJk9y1MkoY4Vh4ZtGXo2R/Ro0YY3TBMm+QG HJFY/GT3HMXHMib4u9m2REVpOt4EDPZ1xVCJE8tPP7ykOV5aPuGnTfyKgGNSehGVt5Ej ZxAkYsO2gEsablkZQ88L3iKgXuNMV42kZjrQqel5iDWeNWkor1Z0HLNr650NV+4VNg/B TQ4m9KKAmnUyzV3xcYadqx2xPA5aeXK+sQiP0Idjy+AB7bQ2NArFBjaHeK00t78mmZYt cBLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hcmsYiCQXikwHHxC/EGKHSvwl//q0ew72VpgHK+MxL4=; b=b4ItV2AQYy2dOZvgoE7ZsK/3YOld9CjT2dXJ0uj2nfXezJf7mg5z8yRlV+eWzX7/9A HufaSDcPTJV4QuWlABOFOA55Ja31Yv9BAfCqajrkB/5k3lWx3m1JQvt2YlRE++ooR6n0 j6SMzfNDhs9FwTRnS6Zpu1UNIgzGkNWkplmm5R+EA/FpbxXZ9pIFsawgvo7rlRm/0cZd 3dxJxGW+tJJemy7w6BeIH/lV5gWIBZxj2Ev4QS9ng+ZQEb7/sX9bhDlnqy7Yu6hnIJYW HAwxMH3T4JzXytNY5p6mU/njfowZWYuvcYENCiygFeDIV1a4oiRa1239GmeN/Tz2oOkf SvNw==
X-Gm-Message-State: AOAM532j5mXAMIKnkLTAeGRDx7YIaom2YfH19AzOiLGRhoG8qkpCw1Wt 9qAg+FFMwIqXz2MSzf+u9iSRsF6AOsBN0lwKosq6jw==
X-Google-Smtp-Source: ABdhPJypbOMxmdrX9zQ67iclu294pIe8YfQQQrdB+SryEXsW6YkEN32hOvjxv/n39K9UozqjrSH/pUUwk2mNKcRtsOk=
X-Received: by 2002:a92:7c03:: with SMTP id x3mr16952198ilc.241.1600174726545; Tue, 15 Sep 2020 05:58:46 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Tue, 15 Sep 2020 08:58:34 -0400
Message-ID: <>
To: tirumal reddy <>
Cc: Eliot Lear <>, Nick Lamb <>, opsawg <>, "<>" <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000002f311b05af59b607"
Archived-At: <>
Subject: Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Sep 2020 12:58:51 -0000

On Tue, Sep 15, 2020 at 6:45 AM tirumal reddy <> wrote:

> Thanks Ben and Eliot for the feedback. Please see inline
> On Tue, 15 Sep 2020 at 14:51, Eliot Lear <> wrote:

> What I do see as a showstopper would be if, as is written and you rightly
>> observe, a new rev of a YANG model is required to introduce the TLS
>> extension, so that part would need to be described in a more flexible
>> manner (e.g, an IANA registration or similar).  I’d suggest the authors
>> consider that.
> Agreed, the YANG model relies on IANA for TLS parameters values including
> extension type values. Even if a f/w does not support a new extension, it
> can still identify whether the new extension is included in the MUD
> profile. If the extension is not included in the MUD profile, presence of
> unauthorized software is detected.
> We will update the draft to make it more clear.

My concern is not with "new extensions" per se.  The hidden assumption here
is that "extensions" are the only way TLS can evolve.  In fact, future TLS
versions are not constrained to evolve in any particular way.  For example,
future versions can introduce entirely new messages in the handshake, or
remove messages that are currently visible in the handshake.  QUIC is
arguably just an extreme version of this observation.

Even within the realm of ClientHello extensions, there is significant
inflexibility here.  For example, consider the handling of GREASE
extensions.  GREASE uses a variety of reserved extension codepoints,
specifically to make sure that no entity is attempting to restrict use of
unrecognized extensions.  This proposal therefore has to add a flag
declaring whether the client uses GREASE, because otherwise the set of
extensions is dynamic, and the number of potential codepoints is
impractically large.  Any change to the way GREASE selects and rotates
extension codepoints would therefore require a revision of this YANG model
first.  There has also been discussion of adding GREASE-type behavior to
the "supported_versions" extension; that would similarly require a revised
YANG model here.

> -Tiru
>> Eliot