IETF Logo Mail Archive

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

Colm MacCárthaigh <colm@allcosts.net> Wed, 03 May 2017 00:30 UTC

Return-Path: <colm@allcosts.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E968E129B48 for <tls@ietfa.amsl.com>; Tue, 2 May 2017 17:30:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guBVwq02b0i1 for <tls@ietfa.amsl.com>; Tue, 2 May 2017 17:30:53 -0700 (PDT)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 10B9C129B82 for <tls@ietf.org>; Tue, 2 May 2017 17:28:41 -0700 (PDT)
Received: by mail-yw0-x22d.google.com with SMTP id 203so77799418ywe.0 for <tls@ietf.org>; Tue, 02 May 2017 17:28:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UU010+FdkYnx1AyCpdPXXJ6ZcbvuMZVGjQ/mddXLhHc=; b=lrfrVB/DFZS4OImVTnBXFi8haDmYlZw6zQI4dOQVuJvrzmMPxYogEpEQ6MuGlSWc/D Qr5losX/G5KyDUGefPOq0rWEYArU2Y5Brdzs9sBoNuZyKlVSasz2pPIZ1Ho2kBMCZieO I2CDBTjhDnA8kbT7yYe85uhd2NDuQ60rHDWZ5JU/AaNAU9MiIN3RPmEUwAcAO0nubpeK cX9l+hc75IiqC4YHlvnZOkyjO7m4nLJsyA8l1q8LirbbhjE8ZVkrn34J5GpLHyaMCfpQ rRxgDDISHecRq6PugWOx0VnfeNtt/IlH1gRyOlPBOWvL1XO+lKQ7kDXko1ZtfIEL3isc euFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UU010+FdkYnx1AyCpdPXXJ6ZcbvuMZVGjQ/mddXLhHc=; b=ObpesPPl1zJetxd4q2GxqPZBO+Q36EplTOyfhvQchsEw8zbXjjjIbATYHhCPhdhpj8 E6VQFqTtL3AaWrzexZvjy7doInt5WUeYOZwW2JN+21eASxunHy63nNe+uk3wJErHuqIp tsxJuCYbSi0g0cLYRoHxKVjqeonCGHYL+iyexe70JYCPw6XjI9FKSRmP2TZTbp2KbpkW 1ge60+T/sM8Yi2g3Uo7nYKJaoDtcJaUlsYMnMw4xtL+TLihE3hjCkpsoUtsOYVS5urxM gZVl1ZxeQ7E8xfr9ixWX+6EhgOC7yyrnwd1G7nOzrt8sHvyyHJ5hrp/h1hwMX71KO+an EYSA==
X-Gm-Message-State: AN3rC/7RpUIObg3ioJSR7JXflbqkmV76EjBDWcUNWQmW3IKDWLRBLhvx EgNa+n/+ozUVjynEUlAsJemD4B+ICZZx
X-Received: by 10.129.152.4 with SMTP id p4mr26904601ywg.1.1493771320234; Tue, 02 May 2017 17:28:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.57.67 with HTTP; Tue, 2 May 2017 17:28:39 -0700 (PDT)
In-Reply-To: <1493768953994.69753@cs.auckland.ac.nz>
References: <CAAF6GDcKZj9F-eKAeVj0Uw4aX_EgQ4DuJczL4=fsaFyG9Yjcgw@mail.gmail.com> <C29356B3-6D71-4088-9AB3-4954327F1E7B@dukhovni.org> <20170502173905.GC10188@localhost> <CAAF6GDeYc5o=eeeyV6HhK9vrLngB-Y=Ed5BdedrE8h2-py4oAw@mail.gmail.com> <20170502180049.GE10188@localhost> <CAAF6GDecd=x-Ob_eO1vSWr6cb6jAeyHBx7zf6cpX=GfxBosfLQ@mail.gmail.com> <20170502182529.GG10188@localhost> <d325ae84-ad24-859d-50a7-825dbabe3b24@akamai.com> <1493768953994.69753@cs.auckland.ac.nz>
From: Colm MacCárthaigh <colm@allcosts.net>
Date: Tue, 02 May 2017 17:28:39 -0700
Message-ID: <CAAF6GDfq0Rs86Zik7M-fCRv51981DO19rFaxRC8Of322RCg8eA@mail.gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: Benjamin Kaduk <bkaduk@akamai.com>, Nico Williams <nico@cryptonector.com>, TLS WG <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0bd9eeeb4692054e93bc45"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1XosBw1NPxgqEqmhtmcm8XS7BUA>
Subject: Re: [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: Wed, 03 May 2017 00:30:58 -0000

On Tue, May 2, 2017 at 4:49 PM, Peter Gutmann <pgut001@cs.auckland.ac.nz>
wrote:

> Benjamin Kaduk <bkaduk@akamai.com> writes:
>
> >I thought TLS clients were supposed to have even worse clocks (in terms of
> >absolute time) than Kerberos clients.
>
> Many of the devices I work with don't have clocks (at best they have non-
> persistent monotonic counters), so I guess that's true in some sense...
>

This whole problem of needing client-side clocks, and having to obfuscate
an age, goes away if we remove the ticket age entirely.

Hopefully the security review makes a strong case that the age is fairly
useless from a security point of view. Even with the age, an attacker can
still generate millions to billions of replays. Even with very conservative
numbers, e.g. to just one host, the attacker can still certainly generate
tens of thousands of replays within the permitted window.  Better to
require servers to reject duplicates (when used with Zero-RTT), and leave
it at that.

-- 
Colm

v2.23.0 | Report a Bug | By Email