Re: Secondary certificates for HTTP servers

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.

Thanks,
Eric


> On Jul 25, 2023, at 11:07 AM, Lucas Pardue <lucaspardue.24.7@gmail.com> wrote:
> 
> 
> 
> On Tue, 25 Jul 2023, 11:02 Mike Bishop, <mbishop@evequefou.be <mailto:mbishop@evequefou.be>> wrote:
>> Personally, I feel like the calculus changes a little bit in the presence of QUIC.  When you can open a new connection in 0-1 RTT, spending an RTT asking whether an existing connection can add a particular certificate *might* not be the approach a client would choose.  If the server fails to supply the certificate, the client still has to do a full connection setup after the prompt fails.
>> 
>> On the other hand, the server being able to avoid or match that RTT is interesting in two cases:
>> 
>> - A content origin sending certificates in parallel with content that references that origin
>> - A forward proxy responding to a CONNECT request with a certificate for the target
>> 
>> My current inclination is to start with unprompted; we can consider a mechanism to prompt if we find we need it, possibly in a subsequent document.  Exported Authenticators already supports a certificate request, so it's not going to require a change to the dependency if we decide to add it later.
> 
> 
> I agree with Mike.
> 
> I could see some benefit from a client SETTING that tells the server the frame is supported, which could help avoid costs related to creating and sending the payload when it would just get dropped on the floor.
> 
> Client prompting for each cert creates more interactions, which creates more coordination issues and possible failure cases. I don't see much benefit in ant of that.
> 
> Cheers
> Lucas
> 
>> 
>> -----Original Message-----
>> From: Watson Ladd <watsonbladd@gmail.com <mailto:watsonbladd@gmail.com>> 
>> Sent: Tuesday, July 25, 2023 9:20 AM
>> To: Eric Gorbaty <e_gorbaty@apple.com <mailto:e_gorbaty@apple.com>>
>> Cc: Ilari Liusvaara <ilariliusvaara@welho.com <mailto:ilariliusvaara@welho.com>>; ietf-http-wg@w3.org <mailto:ietf-http-wg@w3.org>
>> Subject: Re: Secondary certificates for HTTP servers
>> 
>> I feel like the wheel is turning for this set of ideas: First we had CERTIFICATE frame, that people agreed did the things but was too complex. Then we had SERVER_CERTIFICATE, and it was simple, but then we wanted prompting and applying to streams etc. So how do we figure out the balance without topping all the way over to the old proposal, or was it the right idea in the first place?
>> 
>> Sincerely,
>> Watson
>> 
>> --
>> Astra mortemque praestare gradatim
>>