Re: Secondary Certificates

Looking at the two use cases, I’m more confident about the “hybrid” proxy model, where we allow a forward/MASQUE proxy to enable reverse proxying. This is something we’ve built and are using in some small cases, and think could be very useful for more MASQUE-style proxies that are also able to serve content directly. For this case, I think we can gain sufficient implementation and deployment experience in order to ship a spec.

For the more general-purpose coalescing, I’d be curious to see what server implementations (for CDNs or otherwise) would propose as examples of sending these secondary certs. As a client implementer, I think we could certainly add this into our coalescing logic, but I think that use case needs to be motivated by servers identifying cases where it would be beneficial.

Thanks,
Tommy

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