Re: [TLS] Remove 0-RTT client auth

Ilari Liusvaara <ilariliusvaara@welho.com> Mon, 22 February 2016 05:46 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CFE1AD0A3 for <tls@ietfa.amsl.com>; Sun, 21 Feb 2016 21:46:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKiJX7GqoP_U for <tls@ietfa.amsl.com>; Sun, 21 Feb 2016 21:46:16 -0800 (PST)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3913D1A90A4 for <tls@ietf.org>; Sun, 21 Feb 2016 21:46:15 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id DDC4098A; Mon, 22 Feb 2016 07:46:13 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id LLkqQMOydcrm; Mon, 22 Feb 2016 07:46:13 +0200 (EET)
Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 943792313; Mon, 22 Feb 2016 07:46:13 +0200 (EET)
Date: Mon, 22 Feb 2016 07:46:09 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Martin Thomson <martin.thomson@gmail.com>
Message-ID: <20160222054609.GA20873@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CABkgnnWy3anGeLZ2a=EH+O2f4PnScJPGdBdEOkA7EmE+jgZ1pg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABkgnnWy3anGeLZ2a=EH+O2f4PnScJPGdBdEOkA7EmE+jgZ1pg@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/095iuhZbHXQYCYqVuG_7C_aEqko>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Remove 0-RTT client auth
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Feb 2016 05:46:18 -0000

On Sun, Feb 21, 2016 at 11:31:04AM -0800, Martin Thomson wrote:
> I'm sitting here in TRON listening to Karthik describe all the various
> ways in which client authentication in 0-RTT is bad.  I'm particularly
> sympathetic to the perpetual impersonation attack that arises when the
> client's ephemeral key is compromised.

It also seems like a footgun to me (yes, I realize one isn't
supposed to transport "non-safe"[1] data on it, but...).

> We originally thought that we might want to do this for
> WebRTC/real-time.  As it so happens, we have an alternative design
> that doesn't need this, so...

Got mailarchive or draft link?

Some sort of "sign ClientHello" scheme? Or just taking the 1RTT for
the authentcation?

> I propose that we remove client authentication from 0-RTT.
> 
> This should simplify the protocol considerably.

Yes, there are all sorts of obscure corner-cases with 0-RTT auth
that don't happen with 0-RTT data, and seemingly some existing
extensions if implemented bring even more (and the current spec
doesn't even begin to explain those extension issues).



[1] "idempotent" isn't enough: e.g. HTTP considers unconditional DELETE
to be idempotent, but effects of making such thing replayable with
authentication might not be desirable...


-Ilari