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

Nick Harper <> Wed, 16 September 2020 00:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3DAE83A08ED for <>; Tue, 15 Sep 2020 17:30:17 -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 5zWrvD89cN1L for <>; Tue, 15 Sep 2020 17:30:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 792153A08E2 for <>; Tue, 15 Sep 2020 17:30:15 -0700 (PDT)
Received: by with SMTP id h17so5085564otr.1 for <>; Tue, 15 Sep 2020 17:30:15 -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=TZ/w7j18z91kOSlSsUK9irqnAMEibNnutZKj9tdFMqo=; b=pMmii9sLlvVxfS/3mJOoaqrXI4prlH9ek8+2O33FAkKoi0EDvsn7uHrRzuvcNbhiL5 oF+NlppsGvUdf1fbchlXT1fShD+MYAhTvS5SPRfQVZYUNgVGvHxROjD6iuJKDMePeh20 mmt9E1+JYCk5PuHUzVcESl1vDkiaOgBfBewMnmh/KRWIYS4sM/k9y4+3g2JmZgI1tmiM pvX7kiogMe9hIE/mHvwEG+5EHbEmtn+bc1wcNl+Q4/xSp9tc8K0DbbCyqD9NMLaHrsnt r87mxZDjo0Tr40EABMYJtyXCXOX8S7Ymi+akxOjWu0seSZoPMx65rDKHo6QGb7LgOcia k8/w==
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=TZ/w7j18z91kOSlSsUK9irqnAMEibNnutZKj9tdFMqo=; b=qfvzRwFGSdrplhLqMQwAV0phSqXuJwB28kWbKC7KJ6jb6yF6vAVhYBUpTSa4/FdoxG emJCyNgh/LL+rhvM4kZaBYd8W5cTUu1P0OVzGaLPcXjt0mCiO8kyp76gsQqVOYykgoYg ZmwwcEcnPw0taanFb7at19/ZX2rzRfc33vfdArQYBPftktaXkb1D0SJ8eDMkCkACYxrg C08dWPX3TNk9X0VqkkpZi7ksBei1FTys0+CAQLtim0VT1dmYGLUJcoPUuqz8+FBOAHlf lK6dFUa/V2jT6TbahGpDXGinjMwCSIoMZAAPCDxU+XEJb5pry/ryjIgk4fFnBzKgaV7+ G/UA==
X-Gm-Message-State: AOAM530jW68LuzSWFGrBVED9tTorXOlb6mXGnLQMG89PvNfpPjzbcpRT jgjEsjVzxVcZQVWhR4aiXjXFwuM8cP2YSpnEWPXn5Q==
X-Google-Smtp-Source: ABdhPJwKntmRCr0Bxja504jA4NSMOmQOBwy/+1uBs1uue975C/NjeAcXx9sKGF8UApVmZBZHEXcxmmIwCoyQENGehog=
X-Received: by 2002:a9d:67d0:: with SMTP id c16mr14610338otn.347.1600216214380; Tue, 15 Sep 2020 17:30:14 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Nick Harper <>
Date: Tue, 15 Sep 2020 17:30:03 -0700
Message-ID: <>
To: Watson Ladd <>
Cc: Eliot Lear <>, opsawg <>, "<>" <>, tirumal reddy <>
Content-Type: multipart/alternative; boundary="0000000000000608ed05af635f7d"
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: Wed, 16 Sep 2020 00:30:17 -0000

I agree with EKR, Ben Schwartz, and Watson Ladd's concerns on this draft.

The grease_extension parameter shouldn't exist, and there should be no
special handling for GREASE values. GREASE doesn't need to be mentioned in
this draft, except to say that a client may send values (cipher suites,
extensions, named groups, signature algorithms, versions, key exchange
modes, ALPN identifiers, etc.) that are unknown to the middlebox and that
the middlebox MUST NOT reject connections with values unknown to the
middlebox. (This can be stated without mentioning GREASE specifically.)

There is also an issue where this draft does not describe how an observer
identifies whether a TLS ClientHello is compliant with a MUD profile.

On Tue, Sep 15, 2020 at 4:58 PM Watson Ladd <> wrote:

> On Tue, Sep 15, 2020, 9:10 AM Eliot Lear
> <> wrote:
> >
> >
> >
> > 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.
> >
> >
> > I understand.  I used TLS extensions merely as an example.
> There is no reason that a firewall should expect to parse TLS 1.4. TLS
> 1.3 had to go through significant hoops due to middleboxes that
> assumed they could see into everything like it was 1.2. This easily
> added a year to the development time. The final hunt for incompatible
> devices involved attempting to purchase samples, with no real
> guarantee that they would find an intolerant device. Encouraging this
> sort of behavior is a bad idea IMHO, as it will substantially burden
> the TLS WG when designing TLS 1.4 in all sorts of unexpected ways.
> >
> >
> > 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.
> >
> >
> > Probably greasing is something that needs a certain special handling.
> Indeed that’s a form of fingerprinting (greases field XYZ).
> The whole point of grease is keeping extensions open. Coding special
> handling defeats the purpose.
> Sincerely,
> Watson Ladd
> >
> > Eliot
> _______________________________________________
> TLS mailing list