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

Eliot Lear <> Tue, 15 September 2020 13:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8066D3A0544; Tue, 15 Sep 2020 06:09:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Status: No, score=-9.6 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P6n1u6RWjSP6; Tue, 15 Sep 2020 06:09:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0EEE23A053E; Tue, 15 Sep 2020 06:09:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5802; q=dns/txt; s=iport; t=1600175397; x=1601384997; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=qhExkoXR0OmujxTCEdFN4UFTj9xNGCwGFL1LdgTlGnI=; b=EI3cNRIHPKaSAPHlPCgQE7yRQD+PAiyR4GEQX8ysmZmMbpAsy15cYvOH VFJFd/s3Pyf5Y2EwyiWwrFPcZbuS6tcZ4NR7IMpQRIuhlifxPl+7KuCV9 SOzYRAKSIlRVXHQ3p7WfMSP/3pg06Xrk83sDw5tAqUCaCvYJJ6nRY0NhA 0=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.76,430,1592870400"; d="asc'?scan'208,217";a="29567670"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Sep 2020 13:09:52 +0000
Received: from [] ([]) by (8.15.2/8.15.2) with ESMTPS id 08FD9qWl031302 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Sep 2020 13:09:52 GMT
From: Eliot Lear <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_53FBADC8-12DF-4710-98E5-D10396438CA7"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Tue, 15 Sep 2020 15:09:50 +0200
In-Reply-To: <>
Cc: tirumal reddy <>, opsawg <>, "<>" <>
To: Ben Schwartz <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3608.
X-Outbound-SMTP-Client:, []
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 13:10:00 -0000

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

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