Re: Secondary certificates for HTTP servers

Hey,

On Wed, Jul 26, 2023 at 1:03 AM Eric Gorbaty <e_gorbaty@apple.com> wrote:

> On this, I wanted to comment on a point that Guoye Zhang raised as far as
> SETTINGS is concerned:
>
> In discussion that I’ve had about this here at IETF117, one of the things
> that has been suggested is more explicitly discussing the interaction
> between this mechanism and the ORIGIN frame. It’s likely that clients will
> want to use this in conjunction with ORIGIN frames, especially if they’re
> using ORIGIN to tightly scope coalescing on domains in the SAN list.
>
> What seems to be the most widely acceptable behavior for servers, with
> this in mind, is for them to send both an ORIGIN (what should be coalesced
> on this connection) and a CERTIFICATE (proof that it can be done). If a
> client is already very permissive with coalescing on domains in their SAN
> list, then ORIGIN could be ignored. If it was important for clients to get
> an explicit signal like ORIGIN, then it can use both frames that have been
> sent.
>
> But clients that use (and expect) ORIGIN frames to scope coalescing, and
> do *not *support this mechanism, might have an undesired interpretation
> of both of these frames being sent: The CERTIFICATE gets ignored, and the
> ORIGIN they receive contains names which are not recognized (as they were
> in the CERTIFICATE they missed). It’s not unreasonable that the client
> might deem that as malicious behavior from the server. ORIGINs without
> proof (in the initial cert, or secondary certs) are not secure; and could
> be deemed as an attempted attack. In this case, the client *has* been
> sent proof, but they do not know how to use it.
>
> I’m not entirely clear on how much of a problem that might be; but giving
> servers the ability to know in advance whether the client is prepared to
> handle a CERTIFICATE seems useful for scenarios like this. Whether that
> should be a SETTING or something synchronous like a request header, it’s
> not clear. Thought this would be worth considering.
>

I don't think this is a problem in practice for clients that follow the
ORIGIN spec. RFC 8336 section 2.4 [1] makes it pretty clear that servers
need to authenticate with a certificate (carried by some mechanism).

There is value in a (SERVER_)CERTIFICATE frame setting sent by the client
we've overlooked, Let's assume there is interest in this work and we need
to change the format of it for some reason - yes a client will ignore a
frame it doesn't support but that puts a burden on a server to either a)
pick one format or b) send all formats. Neither of those is very good.

Cheers
Lucas


[1] - https://httpwg.org/specs/rfc8336.html#rfc.section.2.4