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

On 23 September 2015 at 19:02, Amos Jeffries <squid3@treenet.co.nz> wrote:
>
> Option 2 risks the same mess if the AUTH frame is defined end-to-end.
> But a per-hop frame would work nicely as long as it is clear to server
> implementers that intermediaries may be the source of the certificate.
> Not some "user".

This would naturally be hop-by-hop, by virtue of extensions being
hop-by-hop and by virtue of the setting that enables it also being
hop-by-hop.

> An option 3 might be to use a SETTINGS instead of dedicated AUTH frame.
> So that the per-hop nature is made extra clear. That would also be more
> backward compatible with older h2 implementations and work in with
> clearing dynamic compression contexts at the same time as authenticating.

SETTINGS wouldn't allow the server to correlate the CertificateRequest
with a specific request/response exchange.

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.