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

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 19 September 2020 22:07 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35FAA3A0138; Sat, 19 Sep 2020 15:07:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l24YVh9oFoPK; Sat, 19 Sep 2020 15:07:53 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E06393A0128; Sat, 19 Sep 2020 15:07:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 0CB05389CB; Sat, 19 Sep 2020 17:46:32 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZhlVcLPvmI1S; Sat, 19 Sep 2020 17:46:31 -0400 (EDT)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:103c:9eff:fecb:2eac]) by tuna.sandelman.ca (Postfix) with ESMTP id 20000389A9; Sat, 19 Sep 2020 17:46:31 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C0A5C72; Sat, 19 Sep 2020 18:07:50 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Eric Rescorla <ekr@rtfm.com>, "<tls@ietf.org>" <tls@ietf.org>, opsawg <opsawg@ietf.org>
In-Reply-To: <CABcZeBP_yYdKvvt5ry3w0RRQzNpj2PKGrmzPW0a2zVWSygUzhw@mail.gmail.com>
References: <21BA8D05-DD83-44DE-81B9-457692484CAD@cisco.com> <053b286e-4780-1818-a79d-71b9c967bbd2@sandelman.ca> <CAHbrMsANEA4omTm5dPYLN9zGde2YdT_71ujpBcCEer_xSkPhbw@mail.gmail.com> <CAFpG3gepojPJoK8W+o9Qr66gPSUqHY+sDX-v+-fuwcM9Y56C_g@mail.gmail.com> <20200911114054.184988dc@totoro.tlrmx.org> <CAFpG3gdRUAAYmvV1+m=+4_0GUd_SDS0hZHhpSXa2qQ6Civtf-g@mail.gmail.com> <CAHbrMsD=BOxYLaJyOkv-t9p+Cm4cEpOui7sQdL9Mmfi=Ufh3mA@mail.gmail.com> <7207C73E-FB80-4BD3-AE68-627355B10708@cisco.com> <CAHbrMsBLrGsg+beMhNadqs+QC9icOsGLxLJYGghEg339=c0b0Q@mail.gmail.com> <5F503ED8-38B0-414A-906A-FE8DCF94AC92@cisco.com> <CAFpG3gdcy2Drm+7j6M_oSfuG5VRH5qE+0nY8joZG3g9yszKf2Q@mail.gmail.com> <CAHbrMsBOhZ+sMxM3KJYT=OkZGzp_1GipkFpwxLKVBckXhDRt2Q@mail.gmail.com> <FFAAF9F3-CAB7-4AC1-A15B-4AF58345331D@cisco.com> <CACsn0cnphGR2dgLcUjWLDs+PvRjmF-7JA7JGjhambArOQGUC2w@mail.gmail.com> <CACdeXiLb8exX-x1RrqJFVNEf1Fck9_nwy48Ywigv2j9ifrxKiA@mail.gmail.com> <CAFpG3gedM=ZqjxGtQ6g64n99Ke21jc2aG5Nh3WmJnQhEYq0DSg@mail.gmail.com> <CABc ZeBNWTSCj+UNO74gtZqnTWMYrsp-VvUkDDGfBK4N_DsJUPw@mail.gmail.com> <107735.1600467171@dooku> <CABcZeBP_yYdKvvt5ry3w0RRQzNpj2PKGrmzPW0a2zVWSygUzhw@mail.gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sat, 19 Sep 2020 18:07:50 -0400
Message-ID: <15520.1600553270@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/h_-A3dTSDw8FvZvoDwsB67nsT1k>
Subject: Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Sep 2020 22:07:55 -0000

Eric Rescorla <ekr@rtfm.com> wrote:
    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?

No, I do mean 1.3.   Many enterprises still think that they can stop it.
Are they winning? probably not.

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

okay.

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

Such as DSL would have to limit the number of cycles it is allowed to
consume, otherwise the middle box might have to solve the halting problem :-)
BPF could be another model.



--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide