Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

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.

David

On Wed, Oct 12, 2016 at 4:36 AM Hannes Tschofenig <hannes.tschofenig@gmx.net>
wrote:

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.

>

>

> -Ilari

>

_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls