Mark's coalescing proposal

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Mark's coalescing proposal

Martin Thomson-3
I think that this is mostly right:

>>>
Partial proposal: insert after 9.1 Connection Management second paragraph:

Clients MAY use a single connection for more than one origin when each
origin's hostname resolves to the same IP address, and they share the
same port. When an origin's scheme is "https", the server's
certificate MUST be valid for the origin's hostname to be used in this
fashion; this might be accomplished using a "wildcard certificate",
subjectAltName [RFC3280], or some other mechanism.
<<<

However, 3280 is out of date.  I wonder if 6125 is not a better
reference to use here.  As in:

When an origin's scheme is "https", the server MUST be authenticated,
either by validating the server certificate against the hostname in
the origin [RFC6125], or by some other mechanism.

Reply | Threaded
Open this post in threaded view
|

Re: Mark's coalescing proposal

Ted Hardie-2
On Fri, Jan 31, 2014 at 10:23 AM, Martin Thomson <[hidden email]> wrote:
I think that this is mostly right:

>>>
Partial proposal: insert after 9.1 Connection Management second paragraph:

Clients MAY use a single connection for more than one origin when each
origin's hostname resolves to the same IP address, and they share the
same port. When an origin's scheme is "https", the server's
certificate MUST be valid for the origin's hostname to be used in this
fashion; this might be accomplished using a "wildcard certificate",
subjectAltName [RFC3280], or some other mechanism.
<<<

However, 3280 is out of date.  I wonder if 6125 is not a better
reference to use here.  As in:

When an origin's scheme is "https", the server MUST be authenticated,
either by validating the server certificate against the hostname in
the origin [RFC6125], or by some other mechanism.


Honestly, I like Mark's text a little bit better, so I'd suggest:

Clients MAY use a single connection for more than one origin when each
origin's hostname resolves to the same IP address, and they share the
same port. For "https" scheme origins, the server's certificate MUST be valid
for each origin's hostname.    The considerations in RFC 6125 for verification
of identity apply.

I think the pointer to 6125 is useful, but since it defers to the PKIX standards
as authoritative for validation, I don't think it should be the reference for subjectAltName
or other core PKIX concepts.  (That's just following 6125's applicability statement).


Just my 2 cents,

Ted


Reply | Threaded
Open this post in threaded view
|

Re: Mark's coalescing proposal

Martin Thomson-3
On 31 January 2014 10:49, Ted Hardie <[hidden email]> wrote:
> Clients MAY use a single connection for more than one origin when each
> origin's hostname resolves to the same IP address, and they share the
> same port. For "https" scheme origins, the server's certificate MUST be
> valid
> for each origin's hostname.    The considerations in RFC 6125 for
> verification
> of identity apply.

This implies exclusivity for 6125, which is a trap I wanted to avoid.
Otherwise, I'm good with that.

Reply | Threaded
Open this post in threaded view
|

Re: Mark's coalescing proposal

Mark Nottingham-2
In reply to this post by Martin Thomson-3
As I was writing this, I was wondering whether the MAY ought to be a SHOULD; i.e., when possible, clients are encouraged to reuse connections.

Thoughts?


On 1 Feb 2014, at 5:23 am, Martin Thomson <[hidden email]> wrote:

> I think that this is mostly right:
>
>>>>
> Partial proposal: insert after 9.1 Connection Management second paragraph:
>
> Clients MAY use a single connection for more than one origin when each
> origin's hostname resolves to the same IP address, and they share the
> same port. When an origin's scheme is "https", the server's
> certificate MUST be valid for the origin's hostname to be used in this
> fashion; this might be accomplished using a "wildcard certificate",
> subjectAltName [RFC3280], or some other mechanism.
> <<<
>
> However, 3280 is out of date.  I wonder if 6125 is not a better
> reference to use here.  As in:
>
> When an origin's scheme is "https", the server MUST be authenticated,
> either by validating the server certificate against the hostname in
> the origin [RFC6125], or by some other mechanism.
>

--
Mark Nottingham   http://www.mnot.net/




Reply | Threaded
Open this post in threaded view
|

Re: Mark's coalescing proposal

Carsten Bormann
On 01 Feb 2014, at 05:25, Mark Nottingham <[hidden email]> wrote:

> whether the MAY ought to be a SHOULD; i.e., when possible, clients are encouraged

There is a wide spectrum between MAY (whatever you want) and SHOULD (you really have to have one of the following documented reasons not to).  This strikes me as a quality of implementation expectation, not an interoperability mandate, so maybe wording with “clients are encouraged” is actually appropriate.

Grüße, Carsten

(Meta note: it is a deficiency that 2119 does not discuss the subject of quality of implementation expectations, and even 6919 only skirts the issue.)


Reply | Threaded
Open this post in threaded view
|

Re: Mark's coalescing proposal

Alexey Melnikov
In reply to this post by Martin Thomson-3
Hi Martin,

On 31/01/2014 18:23, Martin Thomson wrote:

> I think that this is mostly right:
>
> Partial proposal: insert after 9.1 Connection Management second paragraph:
>
> Clients MAY use a single connection for more than one origin when each
> origin's hostname resolves to the same IP address, and they share the
> same port. When an origin's scheme is "https", the server's
> certificate MUST be valid for the origin's hostname to be used in this
> fashion; this might be accomplished using a "wildcard certificate",
> subjectAltName [RFC3280], or some other mechanism.
> <<<
>
> However, 3280 is out of date.  I wonder if 6125 is not a better
> reference to use here.  As in:
>
> When an origin's scheme is "https", the server MUST be authenticated,
> either by validating the server certificate against the hostname in
> the origin [RFC6125], or by some other mechanism.
If you want to do that, you need to define:
1) whether wildcards are allowed or not
2) whether CN-ID (CN=<hostname> in the subject DN) is allowed or not
3) whether DNS-ID is allowed or not.

So basically you can't just say "use RFC 6125", you need a bit more
information.


Reply | Threaded
Open this post in threaded view
|

Re: Mark's coalescing proposal

Martin Thomson-3
On 1 February 2014 11:23, Alexey Melnikov <[hidden email]> wrote:
> So basically you can't just say "use RFC 6125", you need a bit more
> information.

Ahh, I should really read that again.  Last time I tried, I only
barely managed to finish the title.

We're not looking to changing anything, so it's wildcards and CN.

Reply | Threaded
Open this post in threaded view
|

Re: Mark's coalescing proposal

Mark Nottingham-2
In reply to this post by Carsten Bormann

On 1 Feb 2014, at 9:20 pm, Carsten Bormann <[hidden email]> wrote:

> On 01 Feb 2014, at 05:25, Mark Nottingham <[hidden email]> wrote:
>
>> whether the MAY ought to be a SHOULD; i.e., when possible, clients are encouraged
>
> There is a wide spectrum between MAY (whatever you want) and SHOULD (you really have to have one of the following documented reasons not to).  This strikes me as a quality of implementation expectation, not an interoperability mandate, so maybe wording with “clients are encouraged” is actually appropriate.

We've used SHOULD to encourage behaviour with good network effects / social benefit before -- e.g., sending caching metadata. Personally, I think this falls in the same bucket; the client's behaviour here has strong impact on the network and server (indeed, the network impact is one of the major reasons we're doing /2).

Cheers,

--
Mark Nottingham   http://www.mnot.net/