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

Eric Rescorla <> Fri, 18 September 2020 22:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6FE0B3A08FB for <>; Fri, 18 Sep 2020 15:54:47 -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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id psIxdlPQOuxp for <>; Fri, 18 Sep 2020 15:54:45 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 90D203A0AD0 for <>; Fri, 18 Sep 2020 15:54:44 -0700 (PDT)
Received: by with SMTP id 77so464135lfj.0 for <>; Fri, 18 Sep 2020 15:54:44 -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=LkH3c8hXJCcD/jBTWtrAnfiq7KH1skuIrSh9X5oHEOQ=; b=UYghB57zDEBgWCiXjxpwriOqNXLDFShEX7X/oMJ8Z/EW+ocmz5/6uPtRpphQHFfbyL No6Cu5hosOin2iFKYroK0ftdvilDhsdNjCboYcMfoyMfO78Kn4aeEc92HxPa9dFJSYeu HzeAD2vX1k6ZzzVGaJkh0j6m8Dlgq/2VIfFE67F8u6Cv8vBx/5t8HqBZGFqH1WujwL/j mdtmSJCxpPnyWW52gOjHDS98lYnjqR/9jbelw62w2W8p54Rj1o0Y2Y2I44P8CVPgr4pI HGsyMrlLoMEYSc6mcY3nqIbFe1gudHOQPt/6ecCmkML7Wtcw7ceLzauIu8MSXccp3mAB BJmg==
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=LkH3c8hXJCcD/jBTWtrAnfiq7KH1skuIrSh9X5oHEOQ=; b=Xi6CiUpwnSsZmQTobGvt/dDZ7C9Kab/eNL38L02o4h+Ytr6jR6bt3XzzxnOtKPoDbv 6+dj4CSl54mckYIV+h7TFF5Nn424PWzZFc8/DapaxYiGqQbSvopwaTt2lpstvCvoFmsu geYZzcjZyq8QKeVZBYWeqnETFe4XM76DzQlJxeK+D0OuMfzbY1IqUTFm8upG6SNNDvc3 niYp1O3vole00BJRN8uX4Zp+BEdjsF99nYSlRBalugNkpSrdqrzYAaCT7Cal1vs4bwYq BQSyPrnnasxA7HNxHpbneSPzKRjiOmHOR2N6I9GCZC3ayrbK73yobyurPl62bY3GOY87 Qkmw==
X-Gm-Message-State: AOAM5325N6sGpaERAuz3xkn4B9c2EUwT2UriBnX2nLZ0gKScTxEc1ZEY 4/KRfWkeb5JJBkK4/97ER+5lqKqtYOlQMDxFGdZvfA==
X-Google-Smtp-Source: ABdhPJwsz2Z5VveBswFHPJhwNyfgzhqWRPQF7YQD3k3Jc2IvKkJbjk7jAyznO4C38dRMIbIwjgUUO6V2o2bANTtUGLU=
X-Received: by 2002:a19:8706:: with SMTP id j6mr10184628lfd.234.1600469682651; Fri, 18 Sep 2020 15:54:42 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <107735.1600467171@dooku>
In-Reply-To: <107735.1600467171@dooku>
From: Eric Rescorla <>
Date: Fri, 18 Sep 2020 15:54:06 -0700
Message-ID: <>
To: Michael Richardson <>
Cc: "<>" <>, opsawg <>
Content-Type: multipart/alternative; boundary="000000000000e89dee05af9e62fe"
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: Fri, 18 Sep 2020 22:54:47 -0000

On Fri, Sep 18, 2020 at 3:12 PM Michael Richardson <>

> ekr> Taking a step back from details, ISTM that the whole design of this
> ekr> document is antithetical to extensibility:
> I agree.  It was my first reaction as well.
> I then had another thought: there are dozens of entities out there that
> want
> to do this regardless, enough that it broke the TLS version system
> requiring
> the hack. (Does that hack have a name?)

There are actually two things here:

1. Changing the version system -- this was done mostly to accommodate
broken servers.
2. Compatibility mode (hiding the HRR, fake CCS, etc.) -- this was designed
to work around
broken middleboxes.

We can call them stupid, or we can try to understand their point of view,
> and
> try to help them be less stupid.

I don't believe that my note calls them stupid.

In any case, ISTM that the design principle that both 1.3 and QUIC have
converged on is
to opaque-ify as much of the handshake as possible, thus discouraging
passive protocol
enforcement of this kind.

ekr> TLS is a protocol with a number of extension points. What this document
> ekr> does is allow an endpoint to restrict its use of a certain set of
> ekr> extension points. However, the language provided here is
> insufficiently
> ekr> rich to allow the client to properly describe the use of those
> ekr> points.
> assuming that some language could be provided that was sufficiently rich,
> would your objection continue to stand?

I think it's quite likely that that language would have to be
Turing-complete. I note that
the current language is already very complicated and yet insufficiently

> ekr> As a concrete example: for extensions the model knows about
> ekr> (e.g., supported_versions) you can indicate the contents of the
> ekr> extension, but for extensions the model does not know about (e.g.,
> ECH)
> ekr> you cannot. That means that you're either stuck with allowing anything
> ekr> in those extensions (which means that your filtering effectiveness is
> ekr> reduced) or you don't allow those extensions, in which case you
> create ossification.
> ekr> As a thought example, consider a hypothetical TLS 1.4 which decided to
> ekr> adopt QUIC-style obfuscation of the CH and SH, putting the obfuscated
> ekr> CH/SH in extensions in a stereotyped outer CH/SH. The system described
> ekr> here would be unable to do anything useful with that, which creates
> ekr> pressure to block TLS 1.4 entirely, which obviously is not awesome.
> I believe that without a mechanism described in this document, many
> enterprises may conclude that they need to block TLS 1.3.

Perhaps you mean some hypothetical TLS 1.4?

There is already very widespread deployment of TLS 1.3 for HTTPS and
blocking it would cause breakage of a large number of sites. Perhaps you
could safely do it for non-443 ports...

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

Sorry, yes. I meant "client" in the sense that the client tells the
middlebox what rules to use. Whether it does so directly or by reference to
the manufacturer doesn't seem to matter too much for these purposes.

> The idea of having a WASM file is an
> interesting one, but being an executable of a sort, it has other security
> problems.

Well, one always has to worry about the security of processing data one
receives from the network, but I'm not sure that the distinction between
the kind of DSL we're talking about here and an executable is really that
sharp. The argument for WASM or something like it is that there has already
been enormous investment in building sandboxed interpreters for it, so one
gets to inherit all of that effort. This is not, of course, to say that the
WASM sandbox will never have vulnerabilities,but one can generally not say
that about any software.