[TLS] Security review of TLS1.3 0-RTT

Colm MacCárthaigh <colm@allcosts.net> Tue, 02 May 2017 14:49 UTC

Return-Path: <colm@allcosts.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 37D181316D5 for <tls@ietfa.amsl.com>; Tue, 2 May 2017 07:49:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.801
X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id os1yBCYY6e13 for <tls@ietfa.amsl.com>; Tue, 2 May 2017 07:49:00 -0700 (PDT)
Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (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 D9BA01316E7 for <tls@ietf.org>; Tue, 2 May 2017 07:44:36 -0700 (PDT)
Received: by mail-yb0-x236.google.com with SMTP id p143so35331016yba.2 for <tls@ietf.org>; Tue, 02 May 2017 07:44:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=yiQUBpoyUeQwajOLuhjJUYDaR/1CePm+T2g0e/kKjAA=; b=HUPmZpyKwT7hbQTdbTpifZ5SWxEDsPMXblDdy8zlxXcVMn05MtWVSSMd0Ma9cRGPo3 Ri36rsYiLtwoA2J01fU5mjjKJPgfgA7uGw8pwyI5mViBwl/yja5UNtqYeMTfdmDb5nm7 YBGD1nyL7o9/MclQ24yQHZyfjQ5DIVARsLYN/rS6lEDr93jqYcgSVRn+47UpTTa+I5mU DEkeYvDOwM3G/gwtLZtE62C0QBnW8Xtd+UqntzF12Ke4NBDmsFFDfmyR+7qBRnOeq8h/ O5sf/RD+OTHzUJSw57ryJp5A1o/ktgqk1eVGzozf7KBChKVwDCVysY7OHg6OVswMNYkc Cpvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yiQUBpoyUeQwajOLuhjJUYDaR/1CePm+T2g0e/kKjAA=; b=ZGlhaTa6BrxCdG41IhYu2kioGKO894o535ahtJ3Z9kBAVYseW64b1BA8kJ4Kl+nuwK ZCQIb5WGQkyZUFHbHD+LB+v1rfvHRHVmUW4+5J6jFDwZ+AWLSCVP0NlAQHdei3nLOYG0 Lyw1yu3DKL+9q85tTtVZZmcZsmAei/fekWgKFebLF5kTcK9IuakEfVaBdAXqRdlTD31g IrCkMemN8XN+I1p2153kop2M/8du/jDMmGN8nvjQPFxiRfrT4YnXbJNp1fHfxelNNU7B gABfZBxDS6xU4/RSI12c1O+ovOcdemIxoEiD/rmOGoEYWFal7gf1CiOkeA47cGwpxGIr wnWA==
X-Gm-Message-State: AN3rC/4aNEqS3lewgZG5+/KF/W7WFRn8fygNTGHTDok5dxbxlGnmNCPT mU0u8lRmNOP/bXBz9dmRIlbxZoqR4zUM
X-Received: by with SMTP id 203mr11617456ybq.90.1493736275864; Tue, 02 May 2017 07:44:35 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 2 May 2017 07:44:35 -0700 (PDT)
From: Colm MacCárthaigh <colm@allcosts.net>
Date: Tue, 02 May 2017 07:44:35 -0700
Message-ID: <CAAF6GDcKZj9F-eKAeVj0Uw4aX_EgQ4DuJczL4=fsaFyG9Yjcgw@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c0ff041c8acc054e8b9496"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/mHxi-O3du9OQHkc6CBWBpc_KBpA>
Subject: [TLS] Security review of TLS1.3 0-RTT
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 02 May 2017 14:49:02 -0000

On Sunday at the TLS:DIV workshop I presented a summary of findings of a
security review we did on TLS1.3 0-RTT, as part of implementing 1.3 in s2n.
Thanks to feedback in the room I've now tightened up the findings from the
review and posted them as an issue on the draft GitHub repo:


I'll summarize the summary: Naturally the focus was on forward secrecy and
replay. On forward secrecy the main finding was that it's not necessary to
trade off Forward Secrecy and 0-RTT. A single-use session cache can provide
it, and with the modification that ekr has created in
https://github.com/tlswg/tls13-spec/pull/998 , such a cache works for both
pre-auth and post-auth tickets, and it allows clients to build up pools of
meaningfully distinct tickets.

There's also an observation there that it should really be that clients
"MUST" use tickets only once. Any re-use likely discloses the obfuscated
ticket age, which is intended to be secret. Right now it's a "SHOULD".

On replay, the main finding is that what's in the draft is not workably
secure, and the review includes 5 different attacks against 0-RTT data to
illustrate that. Attacks 1 and 2 show that the kind of replay permitted by
the draft is very different from the kind of replay permitted by dkg's
existing downgrade-and-retry attack. I also go over why it very very
difficult to many applications to achieve that idempotency, and why one
idempotency pattern actually relies on non-replayable messages.

Attack 3 shows that idempotency is not sufficient, applications must also
be free of measurable side-effects, which is not practical.  Attack 4 shows
that 0-RTT breaks a common security mechanism: spoofing-resistant
throttles. Attack 5 shows that 0-RTT replay-ability enables an additional
form of traffic analysis.

The recommendation in the review is that implementations "MUST" prevent
replays of 0-RTT section, with some additional discussion about why the
existing advice is unlikely to be followed, and why consistent
interoperability matters here.

Unfortunately, I wasn't aware until Friday that this review would be coming
so late in the TLD1.3 draft process, and my apologies for that. I am now
planning to attend the future WG in-person meetings and look forward to
seeing many of you there.