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

Watson Ladd <> Tue, 15 September 2020 23:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 32B763A07BD; Tue, 15 Sep 2020 16:57:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 xLPCyfvbaunZ; Tue, 15 Sep 2020 16:57:56 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9FDB23A0658; Tue, 15 Sep 2020 16:57:55 -0700 (PDT)
Received: by with SMTP id y17so4965703lfa.8; Tue, 15 Sep 2020 16:57:55 -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:content-transfer-encoding; bh=gBi12j83GPQr7DBo2gJmD9UCr1lXSb6Swgcdus8zTQ0=; b=EcPAO6qDsafTRyd+Z5I62GkqvMKnaA4cQ9OMSxMnkUTmsBBnsJPqJok7yGqk+991jj JxqkZaGeWBgQu7RljImbZPnO6wLMfxsftW/Sr2VTFa3nv0aXM0q7JQZ18TdbFw8CY7hK 904asiH3tiwxL/4H+0Y5cIVfFjZUw4vmp8U+qBtsk8o+uVhceQnHRymqjp4UWrlLAmVn 3rUyOwF9LqTUh/B4iQiZOk/WK6Dwf4C5reeHsCr09gqP65ZLtNngqEDz1FtOSQL7ewnS ghLCgZfx+vBMyLJpx+oZWDjFpycg2hJakqH5Bp/hBaBPbiV7kkOVpJwGQoNuLJYGtm0O zXTA==
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:content-transfer-encoding; bh=gBi12j83GPQr7DBo2gJmD9UCr1lXSb6Swgcdus8zTQ0=; b=E2P2fWPfHrRUFuOJAbXDJouRjvbd/1yidDMtQkJUF/IBs988j76ZWfjEPcUxpU6e/t OmoJr+Iqv980dG18MagCyO++8VOTDmdjFw/TMbv0NJNcBPX/fZV5D+jRSw/fAkCfg9Kq D0V+SlIle7eNSeR2ejkR9Ip9asv1Ny6irNlzSzER+F2ILqG9DQY9+J5mZULVawibUzVH qAhTUeksB/jYZ3Fh31UkWQ0AKQwyXUtnrKHbHRRRE3ZnKGx1HMTJy8t9hBLDnGGlF5/g D3sX5Q2K0W57KAsOq5/VSiefu7AOAq7jt+8/rQxEPEwVLF18oV2EjL2SPekiF0dLytws hDig==
X-Gm-Message-State: AOAM533KELJvOSrBbrv9n2t4V6kwTfQr2IdoP7uBOLQuHIMbwc0dcNbr hAuKewysdmsafGB9sHQQtW9ttkasnDp0GeJGbMU=
X-Google-Smtp-Source: ABdhPJwJ3ITqlWy5ZiNCqEx1ukqB+bzoeUgGDhzQ2ArJV8Y1Fb1HukXFrcOfKRNkrZo/jF50EhCVfuMUDNa3yNxlcUQ=
X-Received: by 2002:a19:7e02:: with SMTP id z2mr7414153lfc.130.1600214273793; Tue, 15 Sep 2020 16:57:53 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Watson Ladd <>
Date: Tue, 15 Sep 2020 19:57:42 -0400
Message-ID: <>
To: Eliot Lear <>
Cc: Ben Schwartz <>, opsawg <>, "<>" <>, tirumal reddy <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 23:57:57 -0000

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.

Watson Ladd

> Eliot