RE: Client certificates in HTTP/2

The doc conflates a few things -- the extension and the quirks of our implementation that we're required to document.  I would really rather have had the extension in a separate doc for easy reading, and the original text of it does still live at http://tools.ietf.org/html/draft-bishop-support-reneg-00 as a stand-alone doc.  (Far fewer pages, and less boilerplate.)  However, I was advised that an independent document would be easier to manage, so it got folded into our quirks/profile doc that we had to publish anyway.

The short form is that mutually-consenting HTTP/2 implementations can agree to change the rules, and we didn't see a good alternative to being able to change the reneg rule in some scenarios.

-----Original Message-----
From: Adrien de Croy [mailto:adrien@qbik.com] 
Sent: Tuesday, June 9, 2015 3:46 PM
To: Martin Thomson
Cc: Mike Bishop; Yoav Nir; HTTP Working Group
Subject: Re: Client certificates in HTTP/2



------ Original Message ------
From: "Martin Thomson" <martin.thomson@gmail.com>
To: "Adrien de Croy" <adrien@qbik.com>
Cc: "Mike Bishop" <Michael.Bishop@microsoft.com>; "Yoav Nir" 
<ynir.ietf@gmail.com>; "HTTP Working Group" <ietf-http-wg@w3.org>
Sent: 10/06/2015 10:40:58 a.m.
Subject: Re: Client certificates in HTTP/2

>On 9 June 2015 at 15:26, Adrien de Croy <adrien@qbik.com> wrote:
>>
>>  so the proposal is to include some flag in all requests (but maybe 
>>not by
>>  some browsers) which can't be used by the server.
>
>Sure it can be used.

so the server is entitled to send a request if it sees the flag, is that the intention?

In which case, why not just let the server send the request if it wants a client cert, and the client can bounce the request if it doesn't want to support that.  That has several benefits.

1. reduced cost.  Only incur cost when the server wants a client cert, rather than on all connections.
2. clients can measure how often they are asked for a cert so that devs can make decisions about whether to support it or not.


>
>>  That doesn't seem like a good use of resource.
>
>It's a few bytes.  We've wasted a lot more elsewhere for less worthy 
>reasons.  Not that I think this is a great idea, but I can appreciate 
>that Microsoft have to do *something*.  It's an existing use that isn't 
>well served.  I'd rather the option I proposed, but we're not seeing a 
>lot of movement on the client authentication piece.
OK, I agree something needs to be done to carry over client cert auth.

>
>Maybe when Microsoft produce a proposal for TLS 1.3, we'll be a better 
>position.  Maybe that will be possible when the TLS 1.3 key schedule 
>and handshake becomes stable (which should be very soon).
>
>>  Or is tongue firmly planted in cheek on this one?
>
>Not this time.  I refer you to:
>http://download.microsoft.com/download/C/6/C/C6C3C6F1-E84A-44EF-82A9-49

>BD3AAD8F58/Windows/%5BMS-HTTP2E-Preview%5D.pdf
thanks for the link

Adrien


>
>>  Did you forget Chromium as well?
>
>I never forget Chromium, or Safari, or Opera, or Yandex, or UC 
>browser...  I just don't know what they plan to do yet.  I think that 
>Chromium have disabled renegotiation, but I wasn't sure.

Received on Tuesday, 9 June 2015 23:04:24 UTC