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 [tls-boun...@ietf.org] on behalf of Dan Harkins [dhark...@lounge.org] Sent: Sunday, April 03, 2016 5:43 PM To: Sean Turner Cc: tls@ietf.org 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 TLS@ietf.org 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= _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
