Re: FYI: proposal for client authentication in TLS

On Tue, Mar 11, 2014 at 9:10 AM, Julian Reschke <julian.reschke@gmx.de>wrote:

> On 2014-03-11 07:16, Yoav Nir wrote:
>
>> Hi, Martin
>>
>> Thanks for writing these drafts. Three comments about this one:
>>
>> 1. I would prefer a special response code that says "go away and don't
>> come back without a certificate" rather than reusing 401, but that's
>> just an aesthetic issue, not substantive.
>>
>
> Why?
>
> It seems to me that 401 is totally applicable here.


Only because it is not followed by the same request with an Authorization
header.

 2. I'm wondering if the message sent to the client can be expanded
> enough so that the browser sometimes does not need to pop up a
> certificate picker. For example, suppose I use a certificate with DN
> "CN=ynir,OU=users" to log in to my SSL-VPN portal. The portal has stored
> this information in my browser via a cookie. If a string representation
> of this DN in sent in the 401 message, the browser can open the new
> connection without bothering the user.
>

<http://tools.ietf.org/html/draft-thomson-httpbis-catch-00#section-2>
> already says:
>
>    A challenge with this auth-scheme does not define the use of any
>    parameters other than "realm".  Other parameters MAY be used to
>    provide a client with information it can use to select an appropriate
>    certificate.  Unknown parameters MUST be ignored.
>
> The question is whether the draft needs to be more specific.


I think if we say that paramteres MAY provide a client with information, we
should say what such parameters could be.


>  3. There is the issue of discovery. With current browsers (and TLS
>> 1.0-1.2) the server initiates a renegotiation. A new browser (with TLS
>> 1.0-1.3) would use this new mechanism. How does the server tell an old
>> browser from a new one?
>>
>
> In HTTP/2, we forbid renegotiation (I believe), that a UA that speaks
> HTTP/2 will know what to do. (But then, how does this work for 2.0<->1.1
> intermediation?)
>

This creates a strange dependency between HTTP versions and TLS versions.

HTTP/2 forbids renegotiation and TLS 1.3 doesn't have it. OK for a new
server, new browser, and new TLS library.

HTTP/1 servers that need client authentication will have to downgrade to
TLS 1.2 so they can get renegotiation.
HTTP servers that support both HTTP versions will need to have convoluted
logic in the TLS stack that says that if the ALPN did not include http2
then the ServerHello has to cap the versions at TLS 1.2.

I'd much rather this new authentication scheme was HTTP version
independent.

Yoav