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

Eric Rescorla <> Wed, 16 September 2020 21:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3937D3A117F for <>; Wed, 16 Sep 2020 14:03:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 GOCkDtAcBWcz for <>; Wed, 16 Sep 2020 14:03:08 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2218C3A112A for <>; Wed, 16 Sep 2020 14:03:08 -0700 (PDT)
Received: by with SMTP id z19so8487845lfr.4 for <>; Wed, 16 Sep 2020 14:03:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=enz8wMdt3JPrktSnaQcBh/3pSmmEDuv9EtxURf/gRqk=; b=eMmMX9KSQRvwKtNvvcUlK/CT7/b4TjKu7LRELdjNiD429wUzj2WpsJkvu1IpZ87J6H NtTGq/xaBh/ilYyvIubXL2Emp4WOtSSfadxdI1/V/JWNsLKbOGea3TvH1gF8PRd5Dgrc zspC6LgSvIt2gydxqkX9o2jy+czPI+LFlaexkdHArUBIaQ56ZRVfEld7N2jF3Epg+MLk nQQTsuMOuI3DRw44D5GGGgFaUgXk1XkXvqaIf2As+hVwiV4kLcqfHLFYuQOJ7MaPGoWm VZlV9JLrGZWylfC9z2DvBkHJQyCzgNwClHHQNbAiaJ6EVJlZoZB1+MRI168+5OQf7n1S gd/A==
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=enz8wMdt3JPrktSnaQcBh/3pSmmEDuv9EtxURf/gRqk=; b=tqVoB5yw0wDy6fPyLU7gNUuaLGx5ZsDzNnojeP68qk3gCyypnVUVtyrKDsdmc8e52D +AnAQWbi1OMW0UzwTQMbzqxRY74Qd8WMeDyDTIgvlFkLydad4mtTvo9gYCViqVpQFhHJ vx3RXw7nFhqUOVf0NDJrK1lCA5yoQHGP7h5zEfOi7zop5gkyjKToxuAiCS5BnBDammod P/91LHP1cphldEhOf9/Ag5FKaoKCyWdeqFPVbeioDC4+0kgYESkupq5cqC55rfUZABtr LirCikCppavK7Ey16qtyHtNPe6gvbZY7/nDwbsiRr8ZmueIuvmnS8Or3gXcuANqSuBAN Ea8A==
X-Gm-Message-State: AOAM5323nuP3yFywvd77/v2wcX5nD5YPQjjYsY4p5RIMmpVClIGAM2C0 Yrx7BE/xoEgZrtFBqTipDUL3s9vMcHOlbpdAu3Ccbg==
X-Google-Smtp-Source: ABdhPJwAffYfUEHa8VmbCxXoTqbANLbzXKzxORnxNolpsjOlQUdPm018gBHt8iv00chmon6Zca6JIjdMG/CtV7Pd9io=
X-Received: by 2002:a19:8296:: with SMTP id e144mr8934404lfd.463.1600290186162; Wed, 16 Sep 2020 14:03:06 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Wed, 16 Sep 2020 14:02:29 -0700
Message-ID: <>
To: Nick Harper <>
Cc: tirumal reddy <>, opsawg <>, Eliot Lear <>, "<>" <>
Content-Type: multipart/alternative; boundary="000000000000158c8305af7498f1"
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 21:03:10 -0000

Taking a step back from details, ISTM that the whole design of this
document is antithetical to extensibility:
TLS is a protocol with a number of extension points. What this document
does is allow an endpoint to restrict its use of a certain set of extension
points. However, the language provided here is insufficiently rich to allow
the client to properly describe the use of those points. As a concrete
example: for extensions the model knows about (e.g., supported_versions)
you can indicate the contents of the extension, but for extensions the
model does not know about (e.g., ECH) you cannot. That means that you're
either stuck with allowing anything in those extensions (which means that
your filtering effectiveness is reduced) or you don't allow those
extensions, in which case you create ossification.

As a thought example, consider a hypothetical TLS 1.4 which decided to
adopt QUIC-style obfuscation of the CH and SH, putting the obfuscated CH/SH
in extensions in a stereotyped outer CH/SH. The system described here would
be unable to do anything useful with that, which creates pressure to block
TLS 1.4 entirely, which obviously is not awesome.

If we want to pursue this kind of idea -- and I'm not at all sure we should
-- ISTM that rather than trying to invent some new DSL for filtering TLS we
allow the client (who by hypothesis is trusted as to what it will generate)
to provide a general program that the middlebox can interpret that will
describe what it will do. For instance, you could provide a WASM file which
gets fed the CH and just says "this is me" or "this doesn't look like me".
That way we don't need to continue extending the language here whenever TLS
evolves. Note that that doesn't prohibit having a language like this as a
programming convenience, but it wouldn't restrict the semantics of what you
could say about the connection.


On Wed, Sep 16, 2020 at 1:09 PM Nick Harper <nharper=> wrote:

> On Wed, Sep 16, 2020 at 12:24 AM tirumal reddy <> wrote:
>> Hi Nick,
>> Please see inline
>> On Wed, 16 Sep 2020 at 06:00, Nick Harper <> wrote:
>>> 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.
>> The grease_extension parameter in the YANG model is a "boolean" type to
>> indicate whether the GREASE values are offered by the client or not.  The
>> MUD YANG model does not convey the GREASE values.
> This is still problematic.
> Unknown values MUST be ignored; GREASE is a mechanism used by endpoints to
> check that their peers correctly ignore unknown values (instead of closing
> the connection). If a device special-cases GREASE values when processing
> TLS messages, that device has completely missed the purpose of GREASE and
> is likely to cause interoperability failures when in the future it sees a
> TLS message that contains a new extension/cipher suite/etc. that isn't a
> GREASE value.
> The IETF should not be encouraging devices to special-case GREASE values.
> I can see no use of the grease_extension parameter in the YANG model that
> does not involve special-casing GREASE values. Hence it needs to be removed.
> _______________________________________________
> TLS mailing list