Re: draft-nottingham-httpbis-origin-frame

This is a very powerful idea. I support further work in this direction.

On Tue, Mar 15, 2016 at 1:40 PM, Mike Bishop <Michael.Bishop@microsoft.com>
wrote:

> Per Mark's request:
>
> =========
> A new version of I-D, draft-bishop-httpbis-http2-additional-certs-00.txt
> has been successfully submitted by Mike Bishop and posted to the IETF
> repository.
>
> Name:           draft-bishop-httpbis-http2-additional-certs
> Revision:       00
> Title:          Secondary Server-Certificate Authentication in HTTP/2
> Document date:  2016-03-15
> Group:          Individual Submission
> Pages:          8
> URL:
> https://www.ietf.org/internet-drafts/draft-bishop-httpbis-http2-additional-certs-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-bishop-httpbis-http2-additional-certs/
> Htmlized:
> https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-00
>
>
> Abstract:
>    Many HTTP servers host content from several origins.  HTTP/2
>    [RFC7540] permits clients to reuse an existing HTTP connection to a
>    server provided that certain conditions are satisfied.  One of these
>    conditions is the inclusion of the secondary origin in the
>    certificate provided during the TLS [I-D.ietf-tls-tls13] handshake.
>
>    In many cases, origins will wish to maintain separate certificates
>    for different origins but still desire the benefits of a shared HTTP
>    connection.  This draft describes how frames which were defined to
>    transfer client certificates might be used to provide additional
>    server certificates as well.
> =========
>
> (Please note that this draft is me playing with an idea.  I can't promise
> implementer interest even from those implementations I work with. This is
> strictly "bored over Christmas" work product.)
>
> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net]
> Sent: Monday, March 14, 2016 4:18 PM
> To: Patrick McManus <pmcmanus@mozilla.com>
> Cc: HTTP Working Group <ietf-http-wg@w3.org>
> Subject: Re: draft-nottingham-httpbis-origin-frame
>
> Hi Patrick,
>
> > On 15 Mar 2016, at 4:40 AM, Patrick McManus <pmcmanus@mozilla.com>
> wrote:
> >
> > I support draft-nottingham-httpbis-origin-frame for wg adoption, if it
> were to be put forward.
>
> OK. I've had it on hold for a while, looking for more interest, so thanks
> for speaking up.
>
> I was also holding off because of our workload, but I think we can take on
> another draft or two. I've already talked to Barry about this one, so I'll
> do a CfA shortly.
>
>
> > I think it is a little unclear on whether or not it intends to include
> the use case of advertising origins that are covered by the traditional
> notion of authoritative (i.e. certificate checks, key pin, et al) but not
> necessarily overlapping DNS. I guess, upon reading, that it doesn't mean to
> include that - but I think it should.
> >
> > The DNS restriction of 7540 is really about sane routing of requests to
> the right server by getting an opt-in that indicates configuration. Its not
> really about security - DNS is not really part of the security model.
> >
> > Its a reasonable bootstrap, but DNS is rather imperfect for this signal;
> as much as we like to imagine a single and consistent DNS space that's not
> the way it translates in practice. Concerns over load balancing are just
> one of many reasons why a strict application of 7540 might not allow for
> coalescing where it was actually setup and desired. This seems as likely as
> the 421 case that motivates the draft. Both could be addressed.
> >
> > The origin frame is a place to put a strong signal that this established
> connection is suitable for the following set of origins no matter what the
> clients view of the DNS. (subject to certificate rules, of course). Indeed
> it would have the interesting property of removing the need to resolve DNS
> for the client for matching origins which is a definite additional
> performance win too even in cases where the DNS does overlap.
>
> That seems reasonable (acknowledging Martin's concern there too). I think
> this is something that's in-scope for discussion if we adopt.
>
>
> > Plausibly these extension frames could get fairly big. It would seem
> easy enough to define them as optionally compressed (with the header
> compression state) in the presence of a settings ack of the extension (and
> a flag bit).
>
> True, but I'm not sure using the HPACK state would help; straight gzip or
> similar might be better. Again, something to discuss.
>
>
> > As an aside, it probably makes sense at this time (different document)
> to add (back) the extension for including more certs serialized into the
> connection to allow more origins to be advertised
>
> Yes, that's been something lurking over the horizon for a while. It's good
> to see Mike's already working on it, and I'd encourage him to submit, so we
> can track it.
>
> Cheers,
>
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>
>