Re: [TLS] Call for consensus: Removing 0-RTT client auth

[Subodh Iyengar <[e-mail]>]

If DH 0-RTT client auth is removed, most apps will start using client auth with PSK 0-RTT handshakes which is the current state in TLS 1.2 (with tickets) as Bill previous mentioned. We've encountered implications of this when using TLS1.2 for internal authentication. The tradeoff here is that a server that shares a ticket key with another server can masquerade as any client to the other server. This is a performance / security tradeoff here, and we solve this using partitioning of ticket keys between untrustworthy servers. There are several other implications of session tickets that we already deal with for this security / performance tradeoff, and this is not the worst one. 

I don't think having some form of 0-RTT client auth is a bad thing since there are engineering implications of not providing client auth during 0-RTT. 
A server app is using TLS for cert authentication and doing it's own authorization, it might provide certain methods to be accessible without authorization, but others with authorization. In a lot of application protocols, the client would not know about this aproiri. Not having a form of client auth would obviate these from using 0-RTT completely which would be sad.

Since 0-RTT DH is still under discussion, maybe we should revisit 0-RTT DH client auth after that is decided?

Subodh Iyengar
________________________________________
From: TLS [[e-mail]] on behalf of Dan Harkins [[e-mail]]
Sent: Sunday, April 03, 2016 5:43 PM
To: Sean Turner
Cc: [e-mail]
Subject: Re: [TLS] Call for consensus: Removing 0-RTT client auth

  Hi Sean & Joe,

On Tue, March 29, 2016 5:59 am, Sean Turner wrote:
> All,
>
> To make sure we’ve got a clear way forward coming out of our BA
> sessions, we need to make sure there’s consensus on a couple of
> outstanding issues.  So...
>
> It seems that there is a clear consensus not to support 0-RTT client
> authentication in TLS 1.3 at this time.  If you think 0-RTT client
> authentication needs to be supported please indicate so now and provide
> your rationale.

  I don't think it needs to be supported and would be happy if
it was removed. It's a dangerous and flawed feature. My concern
is that if (which I fear is pronounced "when") an exploit is found
it might be easy to remove in a browser update but there's gonna
be some large TLS concentrator vendor that'll have a helluva time
getting its deployed boxes patched and it'll be ugly.

  The rationale for this-- to get an ad to me just that much faster
(an ad, I note, that I sure hope my ad blocking software will prevent
me from seeing), and that the people who want to do this know what
they're doing so it'll all be fine (which is not reassuring in the
least)-- just does not justify the risk.

  regards,

  Dan.


_______________________________________________
TLS mailing list
[e-mail]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwIFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=0Wl8UysaIyWxp0Iw_9TKo4jE9Iwn7DnABCdnYWj_2Kk&s=2SuDKxG_YMEaEm1zqgKy4-aHt4NzUB9QVq8SzByaqp8&e=