Re: Secondary certificates for HTTP servers

Hi Eric,

On Thu, Jul 6, 2023 at 1:50 AM Eric Gorbaty <e_gorbaty@apple.com> wrote:

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

Agree its a good WG topic.


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

I'm not an expert on EAs. Would a server send just one or multiple? The
important thing for me is whether a single EA could be so big that it needs
to be sent over multiple frames, which might mean we need something like
H2's HEADERS and CONTINUTATION frames. Avoiding that complexity would be
great if possible.


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

If a client indicated support for CERTIFICATE frame, my server sent one,
but the client opened a new connection to issue a request, I don't think I
have much hope of correlating those two things on the server side. It's a
missed opportunity but beyond that everything still works.

My mental model (and correct me if I'm wrong wrt this proposal) is that the
server always needs to have a correct view of what it is authoritative for,
independent of whether it implements this extension or not. Today I'm
checking the ":authority" value in requests and rejecting stuff that isn't
valid. I don't think this draft changes the requirements of server-side
validation IIUC. In fact, I think the draft correctly highlights a
synchronization problem along these lines, where a server has its own
internal view of correctness but has not communicated it to the client yet
and a request arrives that would try to use an authority that client didn't
technically know about. I don't think we need to solve that synchronization
problem though. A server can just accept or reject misdirected requests
much as it does today.

Cheers
Lucas