Re: Secondary certificates for HTTP servers

On Thu, Jul 06, 2023 at 01:32:03AM +0100, Lucas Pardue wrote:
> Hi Eric,
> 
> Reviving the work is exciting, thanks to all the folks picking up the
> mantle. I think focusing on the server->client flow is good and useful.
> 
> On Thu, Jul 6, 2023 at 12:47 AM Eric Gorbaty <e_gorbaty@apple.com> wrote:
> 
> > Hi Ryan,
> >
> > Thanks for the 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.
> >
> > I do not disagree; we can downgrade the severity of that language or omit
> > a requirement for clients to not send certificates, but just not define any
> > behavior (if this stays scoped to servers).
> > I'm thinking that we still do want endpoints to be able to advertise that
> > they can send certificates as well (or, well, that they support the entire
> > flow here). That said, we could just decide that SETTINGS_SERVER_CERT_AUTH
> > is strictly indicating support for server auth, allowing the possibility of
> > SETTINGS_CLIENT_CERT_AUTH or something like that in the future if there was
> > interest there.
> >
> 
> We aren't running out of frame types. It would make things a lot clearer if
> we called the frame SERVER_CERTIFICATE (or something similar). Then it's
> clear that a server can never receive that frame type. In future if a
> client->server solution is desirable then it can have its own frame type.

How are authenticator requests transported? While it is technically
allowed for server to send authenticator without a request (other way is
not allowed), it is not exactly a great idea. E.g., due to
interoperability reasons.

And I suspect most of the time it will be client that wants to
authenticate the server for additional names (e.g., because client has
discovered server is alt-svc for something else). Authenticator requests
can carry hostname to request authentication for.


It is possible to tell apart authenticator requests, authenticators and
NAKs from the first byte:

- Authenticator requests start with 0x0D.
- Authenticators start with 0x0B.
- NAKs start with 0x14.

So overloading all to single frame type would be technically possible.


> The spec isn't making it clear to me why you need a setting at all. A
> client that doesn't understand the extension frame will ignore it. A client
> that does understand the frame might process it. There doesn't seem a
> strong need for a server to send a Setting. For example, ORIGIN frame
> doesn't use a setting and its interaction is quite similar. I might guess
> that its an optimization to avoid sending frames to clients that would
> ignore them - is the the Authenticator field bigger than the data in ORIGIN
> frames? If that is the motivation it might help to state it more clearly in
> the text.

I would imagine setting would only needed for server side, that would
advertise support to client, which would then use it at will.

And if client sends a request the server can not reply with valid
authenticator, it could send authenticated NAK defined in the EA
spec.


> On the note about size, how big does `opaque data returned from the TLS
> connection exported authenticator authenticate` tend to be? Can it fit into
> a single HTTP/2 frame that has a smaller size constraint than HTTP/3?

I don't think it is good idea to assume the authenticator fits in a
single frame, even if currently that is the case most of the time
(typical sizes are maybe 2.5kB to 7kB or thereabout). In the future,
with post-quantum certificates, authenticators will be quite a lot
bigger.




-Ilari

Received on Thursday, 6 July 2023 08:46:01 UTC