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

From: Michael Richardson <[email-masked]>
Date: Fri, 19 Jun 2020 12:50:17 -0400

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   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian Campbell <[email-masked]>
Date: Thu, 25 Jun 2020 15:31:10 -0600

My aim with something-something-
<https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/>
certificate
<https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/>
is/was to address a narrow but existing need by documenting current
practice while introducing enough commonality to the header name and its
content/encoding so as to facilitate relatively simple interoperability
between independently developed systems. I see where you are going with
this boiling of a small lake but it's well beyond the scope of the kind of
solution I'd envisioned or think would be practically deployed and useful
in any meaningful numbers.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Jun 2020 17:55:44 -0400

> in any meaningful numbers.

I agree with you.

I think it's useful to think about what the next step of complexity would be
in order to understand the ROI for this simiplicity.

I think that a key line is figuring out how/if the certificate chain will be
provided with the simplest design.

---

From: Nico Williams <[email-masked]>
Date: Thu, 25 Jun 2020 18:42:14 -0500

BTW, thanks for the something-something-certificate work.  Looking at
the I-D, draft-bdc-something-something-certificate-04, I see there's no
way to send the certificate chain on.  I understand the motivation
(compression), but it really would be best to send on the full chain
sent by the client.  More on this below:

> I think we have a choice between:

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

If the backend is HTTP/1, then... that sucks, but maybe this is a good
way to encourage migration to /2 or /3.  That said, I think we can
compress in the /1 case by first sending the certificate (and chain,
please) and in subsequent requests in the same connection sending only a
hash of the certificate.  This would force a /1 backend to keep the kind
of state that a /2 backend would for header compression.

>    seems like a good thing.  TLS structures are another obvious choice, but

There's no need.  HTTP/2 already does header compression.

>    HTTP PATCH methods, but I'm not sure I mean this literally.

Can TLS let a client authenticate multiple times?

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

Nico
--

---

From: Michael Richardson <[email-masked]>
Date: Fri, 26 Jun 2020 18:29:51 -0400

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

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.

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

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

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 26 Jun 2020 22:41:02 +0000

>    What has been pointed out is that TLS can renegotiate client authentication.

Not in TLS 1.3.  And with TLS 1.0 and TLS 1.1 on their way out the door ...

---

From: Nico Williams <[email-masked]>
Date: Fri, 26 Jun 2020 17:43:37 -0500

> Not in TLS 1.3.  And with TLS 1.0 and TLS 1.1 on their way out the

That's what I thought.  So there's just the header compression issue.

BTW, this also comes up with cookies, tokens, etc.

Nico
--

---

From: Michael Richardson <[email-masked]>
Date: Fri, 26 Jun 2020 20:22:14 -0400

> Not in TLS 1.3.  And with TLS 1.0 and TLS 1.1 on their way out the door ...

okay, I thought that this was brought up as an issue as we move towards
universal deployment of TLS 1.3.

If that's not a concern, then it makes the whole problem.
I guess I misunderstood the discussion.

---

From: Jim Schaad <[email-masked]>
Date: Sat, 27 Jun 2020 08:01:23 -0700

Ah - Post-Handshake Authentication?

> -----Original Message-----
> From: TLS <[email-masked]> On Behalf Of Salz, Rich
> Sent: Friday, June 26, 2020 3:41 PM
> To: Michael Richardson <[email-masked]>; Nico Williams
> <[email-masked]>; Brian Campbell <[email-masked]>;
> [email-masked]; [email-masked]
> Subject: Re: [TLS] something something certificate --- boiling a small
lake
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 27 Jun 2020 18:17:18 +0000

>    Ah - Post-Handshake Authentication?

Yeah, that.

---

From: Nico Williams <[email-masked]>
Date: Sat, 27 Jun 2020 17:50:35 -0500

> >    Ah - Post-Handshake Authentication?

There's no limit to how many of those there can be, correct?

---

From: Jim Schaad <[email-masked]>
Date: Sat, 27 Jun 2020 16:16:11 -0700

> From: Nico Williams <[email-masked]>
> Sent: Saturday, June 27, 2020 3:51 PM
> To: Salz, Rich <[email-masked]>
> Cc: Jim Schaad <[email-masked]>; 'Michael Richardson'
> <[email-masked]>; 'Brian Campbell' <[email-masked]>;
lake
> There's no limit to how many of those there can be, correct?

As far as I know there is no limit.  There are going to be a large number of
arguments about what it means.

Jim