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

GIthub is unicorny again [1], so I'm going to dump this into email for
later action.

This should say that only the signature algorithms supported in the
negotiated version of TLS can be used.  Plus the following MUST NOT be
used:
 - MD5
 - SHA1
 - SHA224
 - DSA
 - ECDSA with curves on prime fields that are less than 240 bits wide
 - RSA with a prime modulus less than 2048 bits

I think that's about as aggressive without starting to prohibit some
things that are in common use.  Would that work for you Ilari?


[1] translation: argh, my Internet is down again

On 28 January 2016 at 10:01, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
> Require EMS:  https://github.com/MikeBishop/http2-client-certs/commit/dfa59df62aec64044a407b0e8f67704e8eb91981
> Smaller export:  https://github.com/MikeBishop/http2-client-certs/commit/3880e6069480523fcdfa6130fd28bc26ff6ebe9f
> Cautions on AUTOMATIC_USE:  https://github.com/MikeBishop/http2-client-certs/commit/f1479486149e3d815662358d60d7be0bd877952c
>
> I'm not doing the signature/hash changes quite yet, because I'm not sure what we want to restrict.
>
> -----Original Message-----
> From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com]
> Sent: Wednesday, January 27, 2016 12:48 AM
> To: Mike Bishop <Michael.Bishop@microsoft.com>
> Cc: Martin Thomson <martin.thomson@gmail.com>; HTTP Working Group <ietf-http-wg@w3.org>
> Subject: Re: FW: New Version Notification for draft-thomson-http2-client-certs-01.txt
>
> On Wed, Jan 27, 2016 at 12:00:36AM +0000, Mike Bishop wrote:
>> 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.
>
> And requests where that cert is inapporiate MUST NOT made on that connection.
>
> Also, can it apply to streams that are none of:
> 1) The stream AUTOMATIC_USE is sent on
> 2) Stream in IDLE.
> 3) Stream in PUSH_PROMISE
>
> At the time AUTOMATIC_USE is sent?
>
> If yes, that would be a nasty surprise...
>
>> 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.
>
> I don't think server chosing to ignore cert is a problem, as it is equivalent to cert just provoding no privilege at all. But using a cert that should not be used is a *serious* security problem in presence of more than 2 parties (like in Web (but Web is far from being the only place where security problems happen)).
>
>> 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).
>
> Actually, in many cases where one would want to revoke certificate use, the old connection is not GOAWAY'd as it still might be useful.
>
>> As to requiring EMS,
>
> Basically, if you don't require EMS, maliscous server can hijack autenticated connection and misuse the certificates. HTTP/2 TLS use guidelines don't even come close to being able to prevent attacks like this.
>
>> reducing exporter, and appropriate HashAndSignature algorithms, I'll
>> defer to those with more expertise in TLS-land.
>
> Basically, I favor dropping insecure or excessively weak algorithms from new specifications or versions, even at severe cost to deploy- ability. We have gotten burned *far* too many times from not doing that, and *will* get burned in future if we continue allowing those.
>
>
>
> -Ilari

Received on Thursday, 28 January 2016 01:02:21 UTC