Re: FYI: proposal for client authentication in TLS

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.

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.

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?

Yoav



On Sun, Mar 9, 2014 at 9:37 AM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 8 March 2014 11:39, Martin Thomson <martin.thomson@gmail.com> wrote:
> > Pursuant to our discussion on TLS renegotiation, I've submitted part 1
> > of the solution I proposed as an internet draft.
> >
> > http://datatracker.ietf.org/doc/draft-thomson-tls-care/
> >
> > If we agree to a mechanism whereby we augment the 401 status code with
> > a "go away and make a new TLS connection with client authentication",
> > then this is necessary, so that the server knows to request a client
> > certificate.
>
> Now with part 2:
>
> http://datatracker.ietf.org/doc/draft-thomson-httpbis-catch/
>
>