Re: Secondary Certificates

For clarification: Is the concern specifically around the “at the same time” part? As in, moving more requests over that same pipe has desirable properties sometimes, but we end up with a potential footgun if too many requests end up going out in parallel?

If that’s the case, I see secondary certificates being a potential solution to concerns here, if anything. It gives very granular control to a server as far as which origins get coalesced. So servers can have clients gradually put new origins (and requests out to them) down the pipe up to some boundary that it can handle. This is opposed to a massive “cruise-liner” that opens the pipe to a lot of different origins immediately, with no ability for adjustment after the fact. 

I suspect a lot of uses for this will be heuristic in nature, where a server might see that a request is going out to a specific domain, and think  “I know that requesters for this particular origin generally request from x,y, and z too” (anthropomorphizing).

Eric Gorbaty
Apple
> On Oct 12, 2023, at 5:46 PM, Lucas Pardue <lucaspardue.24.7@gmail.com> wrote:
> 
> Personally I am in favor of a the simplified server-only flow. I think the use cases for coalescing and hybrid proxy are interesting enough to make this worth the time.
> 
> That said, coalescing more things has always nagged me a little because it potentially requires shoving more requests down the same pipe at the same time. There's two things I see related to this already being discussed in the IETF. First, the WebTransport pooling discussions related to how to avoid one "partition domain" from gobbling up the connection resources. Second, the recent gotchas around stream concurrency. I don't see this as blockers to potential adoption but I do see it as something we need to address should this work get adopted.
> 
> Cheers
> Lucas
> 
> P.s. the email isn't an adoption call but I would support adoption based on my statements.
> 
> 
> On Fri, 13 Oct 2023, 01:21 David Schinazi, <dschinazi.ietf@gmail.com <mailto:dschinazi.ietf@gmail.com>> wrote:
>> This is definitely an interesting area of work. I think the use cases are useful and I'll happily volunteer to review drafts and all that.
>> Consider this a statement of support for spending WG time on this topic.
>> David
>> 
>> On Thu, Oct 12, 2023 at 1:07 PM Eric Gorbaty <e_gorbaty@apple.com <mailto:e_gorbaty@apple.com>> wrote:
>>> Hi everyone,
>>> 
>>> Following up on this: I've made some revisions to the draft to clarify usage and related mechanisms, see the updated version: https://datatracker.ietf.org/doc/draft-egorbaty-httpbis-secondary-server-certs/01/
>>> 
>>> Mainly, these revisions address:
>>> - Removing any remaining references to client certificates to focus on server authentication
>>> - Clarify the usage of the spontaneous server certificates flow from TLS Exported authenticators
>>> - More strongly suggest the usage of ORIGIN in the event that a DNS check is not used
>>> 
>>> Other changes (Like using multiple frames to send authenticators over HTTP/2), should come later; but those are less interesting as far as the vision of the draft is concerned.
>>> 
>>> Regarding use cases, it seems that discussion so far has revolved around two main uses for this:
>>> - CDNs being able to make additional origins that they support available to particular requesters at a much more controlled, granular level than massive "cruise-liner" certificates at TLS establishment
>>> - Forward-proxies like MASQUE being able to switch to a reverse-proxy mode for particular origins, either optimistically or in response to particular requests
>>> 
>>> Feedback on all of this would be appreciated!
>>> 
>>> Thanks,
>>> Eric Gorbaty
>>> Apple
>>> 
>>> 
>>> > On Oct 11, 2023, at 5:34 PM, Mark Nottingham <mnot@mnot.net <mailto:mnot@mnot.net>> wrote:
>>> > 
>>> > Hello everyone,
>>> > 
>>> > At IETF 117, we had a discussion about reviving the Secondary Certificates work:
>>> >  https://httpwg.org/wg-materials/ietf117/minutes.html#secondary-certificate-authentication-of-http-servers---eric-gorbaty
>>> > 
>>> > The Chairs are considering issuing a Call for Adoption for this work, because there seems to be significant interest in this area still. However, more discussion about the use cases would help us make a decision about re-starting this work. 
>>> > 
>>> > If necessary, we can reserve some further time in Prague, but mailing list discussion is preferred.
>>> > 
>>> > Cheers,
>>> > 
>>> > --
>>> > Mark Nottingham   https://www.mnot.net/
>>> > 
>>> > 
>>> 
>>>