RE: FW: New Version Notification for draft-thomson-http2-client-certs-01.txt

[Mike Bishop <[e-mail]>]

I believe the other comment is also around AUTOMATIC_USE, since both occurrences of "future streams" are in that context.  Basically, it means any future stream on which the server would have made the same request, the server can just use the provided cert and not burn an RTT asking.

Yes, the client loses visibility into whether the cert has been used, and loses the ability to *not* use the cert if it chooses.  That's a trade-off the client can make -- if it wants to retain those capabilities (at the expense of 1 RTT per request), it just doesn't set AUTOMATIC_USE.

The client makes the call -- and as Martin points out, it's state-changing for the connection.  Once you AUTOMATIC_USE a certificate, the server MAY apply it to any future request you make on the connection.  If you change your mind later, new connection (and presumably GOAWAY the old one).

As to requiring EMS, reducing exporter, and appropriate HashAndSignature algorithms, I'll defer to those with more expertise in TLS-land.

-----Original Message-----
From: Martin Thomson [mailto:[e-mail]] 
Sent: Tuesday, January 26, 2016 2:04 PM
To: Ilari Liusvaara <[e-mail]>
Cc: Mike Bishop <[e-mail]>; HTTP Working Group <[e-mail]>
Subject: Re: FW: New Version Notification for draft-thomson-http2-client-certs-01.txt

Thanks for the prompt feedback Ilari,

On 27 January 2016 at 08:38, Ilari Liusvaara <[e-mail]> wrote:
> - Needs to require EMS or TLS 1.3. Any use of TLS-EXPORTER for auth on
>   connections vulernable to THS is no-no.

Yes, absolutely.

> - What does "future streams associated with this request" mean exactly.
>   Covering a stream client did not intend to is no-no.

Context?

> - How does client revoke AUTOMATIC_USE on some certificate (or all
>   certificates) in sequentially consistent way? For the same reasons
>   as previous.

GOAWAY & close.  Note that you might be better off asking for the removal of AUTOMATIC_USE if this is a concern you have.  Also note that you are asking for a level of control that the server doesn't get.

> - Why 1024 byte exporter output? That seems excessively large. 64
>   bytes is already 512 bits, which is high even if actual security
>   is cut in half somehow.

Hmm, yes, 64 bytes is plenty.

> - There are all sorts of crappy TLS HashAndSignatureAlgorithm values
>   that need forbidding, like DSA or ones using MD5 or SHA1.

Good point.  We should limit this to DSA with SHA1.