Re: Secondary certificates for HTTP servers

Hi Eric,

This draft looks great. I have a couple points of feedback:

* "A client MUST NOT send certificates to the server” - I don’t think it’s needed. I understand you’re focusing on server side certificates, but I think it’s fine to leave the door open to client certificates if folks have other use cases. Maybe we can change the "SETTINGS_HTTP_SERVER_CERT_AUTH” setting to mean the endpoint can *receive* certificate frames, so if a server wants to send but not receive these frames, it can set this setting to 0.

* In the second diagram in 3.2, it’d be nice to indicate the server still responds to the CONNECT request in stream N. A few options for how to show that:
<----------------------- (stream N) HTTP response —
<----------------------- (stream N) 200 OK —
<----------------------- (stream N) 405 METHOD NOT ALLOWED —

Thanks,
Ryan Globus

> On Jul 1, 2023, at 5:41 AM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> 
> 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 Wednesday, 5 July 2023 19:19:09 UTC