W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2015

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

From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 23 Sep 2015 20:41:24 -0700
Message-ID: <CABkgnnVq9FDeGf_=JF0m0AkgfO1G3DVV2QN_aPrbYnFtfRLFrw@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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

> 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.
Received on Thursday, 24 September 2015 03:41:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:46 UTC