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

tirumal reddy <> Wed, 16 September 2020 06:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DEEB13A0D6D; Tue, 15 Sep 2020 23:49:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=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 Y8V0dJM51o07; Tue, 15 Sep 2020 23:49:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 575533A0D6B; Tue, 15 Sep 2020 23:49:34 -0700 (PDT)
Received: by with SMTP id f82so5428831ilh.8; Tue, 15 Sep 2020 23:49:34 -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=aKEw4l2oQ3dooYjfAwxgupLMAk7oaPiiz7VZ2yGVR6o=; b=QWMYgfyqJK3RxJxoZrXyQjtaLe1t4Obfpmp9GL/XtziFSh/zLl9a1dlnYGzK1I42zb 280gF2oHekEAjp6hHXIhsayrv+t0PVpIQ/f9H/tK6mk/juzrvcxngyNsjtz5Q97p43Dq 5mHvKRxqxcHLiwwuf45hwpAdMuDDzj/YehHx67gtAqrQIw5BdeZAgUWNM11JOClYTOjC RtuGgARoxbHFRx066hC6fjOior8TSnrcYxTdNa6xiwU+KkobabebotI7+xZMOyFiLZWu Q9m3/YqQbrt+YZL0G7zedFVDOoWt5gFrgQRfsmtPFHJrW9tFTNkZ9tkbGINa8aSGrS+D hfMg==
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=aKEw4l2oQ3dooYjfAwxgupLMAk7oaPiiz7VZ2yGVR6o=; b=M6QQvaiOe8Gt6YNsPO1tQ+1kroVtePDovZCAzp56yBGu/iZamvI+wr4nCsygkm7XRO 2yms73Gg6u9ZIiGnGx6PChIVRQsrj8/VlkeL0HhliYbLoHtz6Pmdx15kbAVNqwmUQJe2 2xWqFwNHVBXMhljW0ssJGl6cw7Yq100aGEkG4D5Xf4jU+/WMTyMNPZxigZW2wt/rV/ZQ e2l8EYNqcEvouJ9O3W7KvOJMBqdB/Eg7v3ipO2ftWbHKcjS5XGgZZunxUj3I3QkZiSMV MTiaY6bKdTeTNYEXF+i4TF4kmzMOObH+9Z5YgvTcBMs8tuay5s+p8sSe1Ng7X9S9dxU/ r/fA==
X-Gm-Message-State: AOAM531fKLIgM2tWGtB/+limbHs6NTpZ80rVJpNxgUiBYplvvii6p6Gn 1UNV+S96ImDGkidT5r+NoUA7EP/xSaZBEno79Yk=
X-Google-Smtp-Source: ABdhPJwH0tgxLB4H0eO6GytUsJEH6AxBF4pZ0aG0LjElt1bDVKcZ77UHFVwkeA8DtNI3a9Z9DQZxFweRgyrsshhRtR0=
X-Received: by 2002:a92:d785:: with SMTP id d5mr13296536iln.123.1600238973392; Tue, 15 Sep 2020 23:49:33 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: tirumal reddy <>
Date: Wed, 16 Sep 2020 12:19:21 +0530
Message-ID: <>
To: Eliot Lear <>
Cc: Ben Schwartz <>, opsawg <>, "<>" <>
Content-Type: multipart/alternative; boundary="000000000000909e6e05af68abe2"
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 06:49:36 -0000

On Tue, 15 Sep 2020 at 18:39, 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.
> 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).

Yes, GREASE requires special handling. The YANG model uses a flag to define
whether the client supports GREASE or not. The MUD TLS profile does not
advertise the GREASE values (see


> Eliot