Re: [TLS] something something certificate --- boiling a small lake

Michael Richardson <> Fri, 26 June 2020 22:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9E6153A0CF1 for <>; Fri, 26 Jun 2020 15:29:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tm0D_25YxAxx for <>; Fri, 26 Jun 2020 15:29:54 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id B1A443A0CEB for <>; Fri, 26 Jun 2020 15:29:54 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 28441389A0; Fri, 26 Jun 2020 18:27:09 -0400 (EDT)
Received: from ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id HaSQLlMUX0ZV; Fri, 26 Jun 2020 18:27:08 -0400 (EDT)
Received: from ( []) by (Postfix) with ESMTP id E01BA3899F; Fri, 26 Jun 2020 18:27:07 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 54CE31D3; Fri, 26 Jun 2020 18:29:51 -0400 (EDT)
From: Michael Richardson <>
To: Nico Williams <>, Brian Campbell <>,,
In-Reply-To: <20200625234212.GV3100@localhost>
References: <6663.1592585417@localhost> <20200625234212.GV3100@localhost>
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, 26 Jun 2020 18:29:51 -0400
Message-ID: <20929.1593210591@localhost>
Archived-At: <>
Subject: Re: [TLS] something something certificate --- boiling a small lake
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, 26 Jun 2020 22:29:58 -0000

Nico Williams <> wrote:
    > On Fri, Jun 19, 2020 at 12:50:17PM -0400, Michael Richardson wrote:
    >> 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:

    > HTTP/2 and, I imagine, /3, does header compression of the right sort
    > here.

The front-end/back-end connection is not likely to be HTTP/2 soon, but maybe
this would push it there.  Right now, it's a often pseudo-binary-HTTP
connection via uwsgi (across python/ruby/perl/npm) backends, fastcgi and
passenger has a protocol that I don't recall.

All avoid reparsing the HTTP headers excessively, while still letting the
whole thing evolve.   There are responses that allow the backend to ask the
front to serve up static content and/or cached results as well.

So it's not often pure HTTP/1, but it acts a bit like it.

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

    > Can TLS let a client authenticate multiple times?

What has been pointed out is that TLS can renegotiate client authentication.
(Also also server authentication, but that's not relevant here, I think).
If I had a monolithic web server with application code, I think that I would
have no idea what to do if such a thing happened: how I'd detect it, or what
I'd do with it.  I think it would look like an entirely new client identity.
(This would be particularly difficult for J2EE environments which basically
spin up a JVM per [authenticated] client)

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

    > Yes, this would also work.  In this case Client-Cert: would carry just a
    > URI.  This is nice because the backend can validate that the origin of
    > that URL is one it trusts.

Yeah, URI rather than URL, as it could even be ni: telling the client to go
look in a database/memcached/redis for the entire story.

This is more than a baby step, as Brian has pointed out.

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-