Even without the Finished computation, rejecting a CertificateRequest would
hit the same unboundedness problem the previous generation of KeyUpdate had.
Our implementation currently treats all post-handshake CertificateRequests
as a fatal error. I think the only context where we'd conceivably change
this is if we need to support HTTP/1.1 + TLS 1.3 + reactive client-auth,
which means it would be under the same constraints the old renego hack was
under. (Forbidden by default, forbidden in HTTP/2, all application
interleave forbidden to prevent unboundedness, and only handled if exactly
between HTTP/1.1 request and response.)
This entire feature is a legacy hack to retain support for some legacy
mechanisms by HTTP/1.1 and others. We need to have some story here, but it
should not burden the protocol any more than is absolutely necessary. I
think EKR's PR is the simplest option here.
On Wed, Oct 12, 2016 at 4:36 AM Hannes Tschofenig <hannes.tschofe...@gmx.net>
I agre with Ilari. Currently, the way to reject a request is more than
just saying "no, thanks.".
On 10/12/2016 10:17 AM, Ilari Liusvaara wrote:
> On Wed, Oct 12, 2016 at 03:10:54AM -0400, Daniel Kahn Gillmor wrote:
>> I don't think it's too much to ask that implementations be able to
>> reject a post-handshake CertificateRequest gracefully, even if they have
>> no intention of ever implementing a proper Client Certificate response.
> Unfortunately, currently it is too much:
> One can't just send a message saying "NAK CertficiateRequest X", since
> that message is followed by Finished message, that is quite annoying
> to compute (even requires forkable hash, when nothing else requires
> that, and if one is to be able to freeze connection, requires very
> exotic features from hash implementation.
TLS mailing list
TLS mailing list