Re: Secondary certificates for HTTP servers

Hi Lucas,

Thank you for the great feedback.

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

I’m not opposed to this as an alternative; this seems like a good question to raise to the WG.

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

Grouping these two together; the exported authenticators might be large enough that it might be worth considering both the ability to transmit them in multiple frames; and use the SETTING. Your point about ORIGIN working without a setting is a somewhat compelling one though. Presumably a server should not be sending the certificates in the first place if it didn’t support subsequent requests.

That said, one potential reason for servers to know whether clients support it would be if they would need to do anything differently on their end based on whether a client would be reasonably expected to use a certificate or not (like open a connection or verify some header). So I’m not totally sure how I feel about not using settings at all. Certainly worth discussing though; and it would probably make things simpler to not use one.

Thanks,
Eric


> On Jul 5, 2023, at 5:32 PM, Lucas Pardue <lucaspardue.24.7@gmail.com> 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 <mailto: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.
> 
> 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. 
> 
> 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?
> 
> These a small technical points, I think HTTP would benefit from something like the draft proposes and the WG should consider it.
> 
> Cheers
> Lucas
>