W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

Re: draft-nottingham-httpbis-origin-frame

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 16 Mar 2016 10:33:51 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <82B3CCD1-EC5B-442B-BD5F-07F59FD859F8@mnot.net>
To: Mike Bishop <Michael.Bishop@microsoft.com>
Thanks, Mike. 

I've put that and the "decomposing" draft on the WatchList. Would you like some time to present about them in B-A?

Cheers,

> On 16 Mar 2016, at 7:40 AM, 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/
> 
> 
> 

--
Mark Nottingham   https://www.mnot.net/
Received on Tuesday, 15 March 2016 23:34:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:11 UTC