Re: Secondary certificates for HTTP servers

Hi Ilari,
Apologies for the delay on responding here, and thank you for the detailed discussion and feedback!

The points you have raised about wanting to validate alt-svc are certainly interesting; I didn’t fully consider that.
While in theory I believe that certificates could stay strictly unprompted; in practice I imagine a lot of use-cases and implementations would just resort to non-standard application logic to get around that and allow for an intentional coordination of this (ie: sending a dummy request just to tickle an authenticator out of the server). For something like alt-svc, that seems particularly suboptimal.

I do think it would be a worthwhile topic to discuss a capability to prompt for certs from the server and provide more full support for mechanisms described in RFC 9261. It’s not clear to me what the best way to approach that is yet (another frame type? Clients able to send SERVER_CERTIFICATE with EA requests instead of authenticators?); and there’s certainly a lot of added complexity. But it certainly seems worth discussing; I’ll include it in the slides; though this seems like a problem that might not be totally be solved in the 15 mins of agenda time we have for 117.

Thanks,
Eric


> On Jul 6, 2023, at 1:45 AM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> 
> 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