Re: Secondary certificates for HTTP servers

On Fri, Jun 30, 2023 at 08:43:06PM -0700, Eric Gorbaty wrote:
> Hello HTTP Enthusiasts,
> 
> I’ve put up a -00 draft, in collaboration with Mike Bishop (and
> others), a re-imagining of secondary certs.
> 
> - https://datatracker.ietf.org/doc/draft-egorbaty-httpbis-secondary-server-certs/
> 
> "This document defines a way for HTTP/2 and HTTP/3 servers to send
> additional certificate-based credentials after a TLS connection is
> established, based on TLS Exported Authenticators.”
> 
> It’s pretty similar to the older archived secondary certs draft
> (https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-http2-secondary-certs-06),
> with a few key differences:
> 1. It defines support for both HTTP/2 and HTTP/3
> 2. It is focused on unprompted authentication for servers; as it’s
>    the most flexible and simple to coordinate.
> 3. TLS Exported authenticators are now an RFC
> 
> A decent amount of the language and ideas are borrowed from the
> previous draft, credit goes to the previous authors and contributors.
> 
> The draft is still in early stages and could certainly use some
> feedback. We’re having some luck at Apple as far as useful
> implementation is concerned. One of the goals is to build this from
> the bottom up based on implementation. And probably to leave client
> authentication out of it. 

I would imagine the most common case for this is that the client
discovers that it already has connection to alt-svc, but that connection
is not authoritative. So it would like to ask the alt-svc it is
connected to to authenticate for the origin (as that would be doable
in 1-RTT, which is way less than setting up a new connection).

If client is in that position, it can not perform any speculative
actions, but needs to send pure authentication request.


A crazy idea I had was to transport this on global OPTIONS (not origin
OPTIONS).

1) Early in the connection:

- Client requests OPTIONS *
- Server responds indicating capability.

2) When needing to authenticate:

- Client requests OPTIONS * with header indicating this is EA requst,
  and EA request in the body.
- Server responds with header indicating this is EA, and EA in the
  body (or header indicating an error).


Reason not to use origin OPTIONS is that those may get dispatched, which
is very much undesired here. While global OPTIONS is never dispatched.




-Ilari

Received on Saturday, 1 July 2023 12:41:18 UTC