Re: [TLS] Call for Consensus on removal of renegotiation

[Brian Hamon <[e-mail]>]

From: Eric Rescorla [mailto:[e-mail]] 
Sent: Friday, June 27, 2014 9:29 AM
To: Martin Thomson
Cc: Brian Hamon; <[e-mail]>
Subject: Re: [TLS] Call for Consensus on removal of renegotiation


On Fri, Jun 27, 2014 at 9:29 AM, Eric Rescorla <[e-mail]> wrote:
>On Fri, Jun 27, 2014 at 9:25 AM, Martin Thomson <[e-mail]> wrote:
>>On 27 June 2014 09:10, Brian Hamon <[e-mail]> wrote:
>>> Unless someone makes a case otherwise, I think that the answer to my question is that client authentication (assuming Martin's proposal is accepted) is either required from initial ServerHello or unavailable?

>> There are other options:

>> 1. TLS 1.3 could allow clients to authenticate unilaterally (i.e., not
require the CertificateRequest message to be sent before sending a
client cert, or mandating that servers provide a CertificateRequest
always).

>> 2. Authentication might be provided with a separate type of control
message.  This has been discussed.

>> And any combination of the above, depending on what we think best fits
the complexity/functionality trade-off.

>> Personally, I like the idea of doing option 1 here.  With
confidentiality protection for handshake messages, it could make
client authentication considerably more accessible than it was in
previous TLS versions.

Interesting and elegant proposal... Assuming we don't create headaches for implementers or 
opportunities for DoS, I would favor this also.

>>> [...] perhaps this committee should eliminate client authentication completely from TLS.

>> I haven't seen much interest in doing that.  My proposal still relies
on TLS providing a binding to client credentials.

> I would oppose that. There are plenty of situations where mutual authentication
is needed in TLS.

I engaged in reductio ad absurdum there, because without either of these additional mechanisms,
client authentication is impossible (in some very specific use cases over which apparently I uniquely 
obsess). 

We must have server authentication at the transport layer, in order to securely negotiate the master 
secret. TLS strives for symmetry, allowing the same implementation to be used in clients and servers. 
Therefore client authentication must be in TLS, even though authentication in the transport layer
is a violation of the OSI model. Anything that moves the Internet away from password-based
authentication is a win.

Making "client authentication considerably more accessible than it was in
previous TLS versions" should be a high priority goal for TLSv1.3.