[TLS] something something certificate --- boiling a small lake
Michael Richardson <mcr+ietf@sandelman.ca> Fri, 19 June 2020 16:50 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 4FCDD3A0CC5 for <tls@ietfa.amsl.com>; Fri, 19 Jun 2020 09:50:22 -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 v0UmIqDBIAWW for <tls@ietfa.amsl.com>; Fri, 19 Jun 2020 09:50:20 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AA943A0CC8 for <tls@ietf.org>; Fri, 19 Jun 2020 09:50:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id AED3E389D2; Fri, 19 Jun 2020 12:47:41 -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 Cai8VIN_avNN; Fri, 19 Jun 2020 12:47:40 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7A2A5389AF; Fri, 19 Jun 2020 12:47:40 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 62978240; Fri, 19 Jun 2020 12:50:17 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Brian Campbell <bcampbell@pingidentity.com>, ietf-http-wg@w3.org
cc: tls@ietf.org
X-Attribution: mcr
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: Fri, 19 Jun 2020 12:50:17 -0400
Message-ID: <6663.1592585417@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/_yjyPwG2Ua1IdSa9nfPNTIms03k>
Subject: [TLS] something something certificate --- boiling a small lake
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, 19 Jun 2020 16:50:33 -0000
Brian, {I have been on the httpbis list, but I'm not right now, and I know that w3 and IETF do not share their whitelists, so this might not work} I was thinking about something-something-certificate yesterday while cleaning/swimming my pool. (A long thankless task, as the pool is not heated, we've been getting very a-seasonal *snow*, and nobody in my family but me will swim in it until it's "perfect". Also we have many many trees, which we won't cut down. You can see how my mind might wander) [This discussion would be better done with beer and napkins.] So I am thinking that we need to create a "digital twin" in the back-end server for the front-end TLS state machine. It needs to reflect the current state at a level of detail appropriate for the application. Thus, a single header isn't enough, although there could be some degeneration that results in a single header. We need a few variables to update. I think we have a choice between: 1) sending the state (possibly a few kb) on every transaction, which keeps the protocol stateless. We could explore ways to encode it: CDDL+CBOR seems like a good thing. TLS structures are another obvious choice, but that's a detail. 2) assuming that state will be maintained by both ends, and simply updating the state appropriately. When it comes to this, I think of the HTTP PATCH methods, but I'm not sure I mean this literally. It's the model of having a few objects per-connection that the TLS front-end might update on the backend, and making the management of the TLS connections explicit. Alternately, the TLS front-end could maintain a RESTful interface on a per-connection basis that the back-end could interrogate. The header would just provide the right reference to that. The RESTful interface could even be pushed/updated into some other CPU on the TLS terminator. This is cleaner, but this has read-latency round trip issues, while pushing the state out on each HTTP request (or uwsgi, fastcgi, ...) seems a lot more pipelined. Or MQTT :-) To this, I think we'd have to look at the RFC8446 Appendix A.2 state machine and figure out how to express this. I don't really see re-auth in that diagram. Maybe I'm overthinking here, but given the opportunities in TLS 1.2 and 1.3 for newer states, and the review from TLS experts on the header, this might be cleaner and less of a hack to get the additional things in. This data model mechanism also better accomodates the split between those who need the entire certificate chain (w/ and w/o trust anchor used), and those that just care about the EE involved. --- I don't know, in a HTTP/3(QUIC) world, what the TLS front-end/backend connection looks like. I haven't entered such a world personally. TLS front-end systems *are* collecting/storing state on a per-client connection basis, whether the transport is QUIC or not. I don't think it scales well to try to spread that state across load balancers, you want to split the traffic before the TLS terminators in order to horizontally scale them. A thought that I have is that with a move to HTTP/3, that the need for something-something-certificate declines. A model that I could see in such a situation is that since the bulk of the transport is via QUIC, it could be that it makes less sense to have TLS hardware terminators; by careful use of port numbers to demux upon, and/or IPv6 addresses, it might be easier to load balance directly to application servers, and just horizontally scale them wider. The hardware TLS offload box then is only important for adapting HTTP 1 and HTTP/2 connections to HTTP/3. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- [TLS] something something certificate --- boiling… Michael Richardson
- Re: [TLS] something something certificate --- boi… Brian Campbell
- Re: [TLS] something something certificate --- boi… Michael Richardson
- Re: [TLS] something something certificate --- boi… Nico Williams
- Re: [TLS] something something certificate --- boi… Michael Richardson
- Re: [TLS] something something certificate --- boi… Salz, Rich
- Re: [TLS] something something certificate --- boi… Nico Williams
- Re: [TLS] something something certificate --- boi… Michael Richardson
- Re: [TLS] something something certificate --- boi… Jim Schaad
- Re: [TLS] something something certificate --- boi… Salz, Rich
- Re: [TLS] something something certificate --- boi… Nico Williams
- Re: [TLS] something something certificate --- boi… Jim Schaad