[TLS] Remove 0-RTT client auth

Martin Thomson <martin.thomson@gmail.com> Sun, 21 February 2016 19:31 UTC

Return-Path: <martin.thomson@gmail.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 6D28C1A21A1 for <tls@ietfa.amsl.com>; Sun, 21 Feb 2016 11:31:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 tDBZf52a5Wxw for <tls@ietfa.amsl.com>; Sun, 21 Feb 2016 11:31:05 -0800 (PST)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB9011A8748 for <tls@ietf.org>; Sun, 21 Feb 2016 11:31:04 -0800 (PST)
Received: by mail-io0-x235.google.com with SMTP id g203so157388382iof.2 for <tls@ietf.org>; Sun, 21 Feb 2016 11:31:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=SVS4nvvldvkYEVrkmUOgb3i8BNRup6eXiObJoEpQ+u0=; b=GEkwoEFZOvUtd1LC/OLvCeCL5Y6MOt+NhVVA9RDHmyp6NTKuzCooVYHvFTheioxsy0 liO0rG+9g37Nk7xmqjA1DSBI9nniFhzzTyFjd6D3H9u07T62dlq5082AGn8XqmHcwjIv /KMnqbnA/+ikNQx1dnrdhrtAwer9/SOrPHIqCKgQeEcTpqsDbCf3eDBBVBP21NP9eglB 9cUZAp2UUnHtyKI3CPkQhMpHGjL2V/cC+qDsU1+pBs7QK29D4VPTEP0vSxwW4zg8BMIW zQGfnvXhHWjMjwJXxjHTD4Baa7XDQaIKvYMKWXIYzrYPyHq8fdubAZXgUTyP4dyXB1wQ iH3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=SVS4nvvldvkYEVrkmUOgb3i8BNRup6eXiObJoEpQ+u0=; b=fdXQT2ZW5Ixw4x/bOj2PGeKn+MTAT1EDUsdo4dVeODf95FYt+rO4h7729GEg3WEW3d MJtifRneS8pi9QhQwnm/DAHSGqUM99JwyJLm9zFDrgfj3YuUiaeS2EZjbhxdEEPpesF0 L6ZX63+83tEOyvlAgt0amGZG4rrLNr9GLxLExTZfTtUfN1SXc6quN+w/rjj/kMG4dJMt yl0o3CxGE2LmXi36u1PdRW3EbVRpNi0Nu1QaGQRWPzZzCtsvI1QDkbzMmvzdwzLN6ZeU dQDWP1Uzq4OJ1k6cuH2dfMX9jNNaDnAYmZpAS7GiAOe64bvSPkVAy6kXl+NEB4PpmUrg LemA==
X-Gm-Message-State: AG10YOSmVQ7Ms1FVhGnIiP2f0bLAiXTMzx5S05l9FWkCTxHSUlSnN+PmOLIEJWkC5+uR2wJm2VyemclaUzez6Q==
MIME-Version: 1.0
X-Received: by 10.107.131.27 with SMTP id f27mr26137298iod.190.1456083064278; Sun, 21 Feb 2016 11:31:04 -0800 (PST)
Received: by 10.36.53.79 with HTTP; Sun, 21 Feb 2016 11:31:04 -0800 (PST)
Date: Sun, 21 Feb 2016 11:31:04 -0800
Message-ID: <CABkgnnWy3anGeLZ2a=EH+O2f4PnScJPGdBdEOkA7EmE+jgZ1pg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/mNo8sLhnPRX8xn8ZikCSMFztZLY>
Subject: [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: Sun, 21 Feb 2016 19:31:06 -0000

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.

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...

I propose that we remove client authentication from 0-RTT.

This should simplify the protocol considerably.

https://github.com/tlswg/tls13-spec/issues/420

[1] Compromising the server's long term key has the same impact, but
that's interesting for other, worse reasons.