Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
Michael Richardson <mcr+ietf@sandelman.ca> Fri, 18 September 2020 22:12 UTC
Return-Path: <mcr@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 372C63A098D; Fri, 18 Sep 2020 15:12:56 -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 0w2cSF4l7KTQ; Fri, 18 Sep 2020 15:12:54 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3FFC3A005C; Fri, 18 Sep 2020 15:12:53 -0700 (PDT)
Received: from dooku.sandelman.ca (CPE788a207f397a-CMbc4dfb96bb50.sdns.net.rogers.com [174.116.121.43]) by relay.sandelman.ca (Postfix) with ESMTPS id 678EC1F4A9; Fri, 18 Sep 2020 22:12:52 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 439131A022D; Fri, 18 Sep 2020 18:12:51 -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: <CABcZeBNWTSCj+UNO74gtZqnTWMYrsp-VvUkDDGfBK4N_DsJUPw@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> <CACd eXiLGD_o91nJ6fGrE_H78BO2noCP1VBnUbOXbr-E2d9MZFg@mail.gmail.com> <CABcZeBNWTSCj+UNO74gtZqnTWMYrsp-VvUkDDGfBK4N_DsJUPw@mail.gmail.com>
Comments: In-reply-to Eric Rescorla <ekr@rtfm.com> message dated "Wed, 16 Sep 2020 14:02:29 -0700."
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Fri, 18 Sep 2020 18:12:51 -0400
Message-ID: <107735.1600467171@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/sd-b1Lb4m0keysTetCtCUHxqIjI>
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: Fri, 18 Sep 2020 22:12:56 -0000
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?) We can call them stupid, or we can try to understand their point of view, and try to help them be less stupid. 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? 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. 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. The idea of having a WASM file is an interesting one, but being an executable of a sort, it has other security problems. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… Michael Richardson
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… Ben Schwartz
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… tirumal reddy
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… Nick Lamb
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… tirumal reddy
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… Ben Schwartz
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… Eliot Lear
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… Eric Rescorla
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… Ben Schwartz
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… Eliot Lear
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… tirumal reddy
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… Ben Schwartz
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… Eliot Lear
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… Watson Ladd
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… Nick Harper
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… tirumal reddy
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… tirumal reddy
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… Nick Harper
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… Dan Wing
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… Eric Rescorla
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… Michael Richardson
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… Eric Rescorla
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… Michael Richardson
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… Eric Rescorla
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… Eliot Lear
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… tirumal reddy
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… tirumal reddy
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… Ben Schwartz
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… tirumal reddy
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… Eliot Lear
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… Eric Rescorla
- Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy… Nick Lamb