Re: Report on preliminary decision on TLS 1.3 and client auth

[Martin Thomson <[e-mail]>]

On 23 September 2015 at 20:56, Amos Jeffries <[e-mail]> wrote:
> If it is stream-specific in terms of HTTP/2 streams rather than TLS
> streams, then the frame as in option 2 should be okay. Option 1 still
> has major issues with www-auth vs proxy-auth.

Right.  To expand on the problem here, at least in the browser context
- and likely in other cases as well - it is important for the client
to be able to identify which request triggered the certificate
request.  If there are requests from multiple browser windows (or even
applications) sharing the same connection and a CertificateRequest
appears, the client needs to know where to show the associated UX, if
there is any.

I certainly agree about the e2e and hbh concerns.  An end-to-end
message would prevent the hop-by-hop TLS from being tweaked.

>> Also, while I think of it, we should probably forbid the use of this
>> on server-initiated streams (i.e., with server push).  That could
>> cause problems.
>>
>
> I can see that as being a SHOULD NOT, or forbid on PUSH_PROMISE
> specifically. But using a more general definitio like "server initiated"
> may cause conflicts with the bi-directional h2 extension.

mhm.