Re: FYI: proposal for client authentication in TLS

Thanks Michael,

This is a great help.  Apologies for the rough state of the drafts,
they were done in a screaming hurry during the HTTP/2 design team
session.

On 25 March 2014 08:02, Michael Köller <michael.koeller@greenbytes.de> wrote:
> Hi Martin,
>
> Julian asked me to also review your drafts. So I took the opportunity to dive a into the subject.
> Here are the few things that caught my attention.
>
> 1) http://datatracker.ietf.org/doc/draft-thomson-tls-care/?include_text=1
>
> The TLS spec [1] reads: "In general, the specification of each extension type needs to describe the effect of the extension both during full handshake and session resumption."
> Currently I find no text about this. It seems clear that the new extension only applies to initial session handshakes. However, I think this should be stated explicitly.

Yeah, this applies to initial and renegotiation handshakes.  It can't
apply to resumption.  I have noted this.

> The HTTP spec [2] describes the realm parameter in terms of resources: A client may reuse an authorization that was previously cached as successful for this resource.
> It remains unclear, what the semantics of the realm parameter should be in context of this new authentication scheme. Even more so, since the client is expected to turn to the lower TLS protocol level, where resources have no meaning.
> How do clients interact with servers using more than one protection space?
> A realm (i.e. a protection space) is coupled to the server's host name. So taken to TLS this means that the SNI extension becomes mandatory?

The idea here is that you create a new connection for every protection
space.  SNI shouldn't be necessary, at least to the extent that it
isn't already needed, of course.

That needs more expansion, I'm sure.

I've made some edits, see:
https://github.com/martinthomson/drafts/commit/ffdb77053e0ca897943ae455e605351fda0ae1cb

Received on Tuesday, 25 March 2014 18:20:15 UTC