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

Colm MacCárthaigh <colm@allcosts.net> Mon, 22 May 2017 02:28 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 3B43B1200F1 for <tls@ietfa.amsl.com>; Sun, 21 May 2017 19:28:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 2j8V3Gk6E92L for <tls@ietfa.amsl.com>; Sun, 21 May 2017 19:28:47 -0700 (PDT)
Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::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 4676E1200C1 for <tls@ietf.org>; Sun, 21 May 2017 19:28:47 -0700 (PDT)
Received: by mail-yb0-x235.google.com with SMTP id p143so27363248yba.2 for <tls@ietf.org>; Sun, 21 May 2017 19:28:47 -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=YHjB42H15R2jTeDv1/C43m3c0pqEbivsLzZbiQYmhyo=; b=GiQJJhJzvhwvD0/9hiaX6pW8QvlQuU0kN58MfXhuvrWO6+AF09QTG9G+lV59JUYmfw Dkr4RQTqrJZTPneoLdVtfb+FpmIqPdFzsjT4tU500q+njmIyNBLGZRCxUpW3Gz8XT4Wv Y79xj48gYJgrSeocKsEQotIDK5XOYOb/aarjHO3lK5ntRpmMbZeYLISIPiPP8c1RTxKI 5AKm2YLVh70g9S2hWdoBtBddIaVdoDcK1jcdOHrWp/MCgDgPp3F6iNOozMizGGUJwMuq oBGjAv4nik7BB/iVsR4P5tlHAV1GepxIQhnVBfg7j0D6JxYt3cx1iFkwq28970R/Jzhd MP8Q==
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=YHjB42H15R2jTeDv1/C43m3c0pqEbivsLzZbiQYmhyo=; b=cyfuzMdmPRv+7TmhZwyrJYflVI1Jj+hI0E1rQfieVWiNN5zmS8FI1jLmYuP44FCxdG iF3IkGTtUrENVrFOqqNGVUIYsFBZFVU3O0tMcRDnD3nQEQ2Y9Zib/JP/StQv1QgMFv8s 7y0IqHNjUrDYxGjz3EJchCbACJJttoI3x3mNTEiqvkC/cjxaHAQaBjcKdkb39PxrXNH1 GQLRkLQZgh+innUasdxAzEZVld3KV1M4KZtF6jiYqI5xHJSqjRI0nimUyUGRqgpPj8a4 6fu9qmIdiQQgHA4218QKn8VpPrz5dnK8z56ZiuyE5Y0Z6wuLLvSP8512eKvlhDhRc/0F BYIA==
X-Gm-Message-State: AODbwcCdPP16r9kmf1tplk4g8fjroDufPLetVnLs4Ky+7YXuYuRcUxkg oRDnsz3xP/q5E8aZKDvvpG21t4Y3F2bj
X-Received: by 10.37.15.213 with SMTP id 204mr17374806ybp.127.1495420126366; Sun, 21 May 2017 19:28:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.97.3 with HTTP; Sun, 21 May 2017 19:28:45 -0700 (PDT)
In-Reply-To: <CABcZeBNj_X4qbXrH4732kQiAHrBpPZhW1nmn4Xnp-pm0gv1Psg@mail.gmail.com>
References: <CAAF6GDcKZj9F-eKAeVj0Uw4aX_EgQ4DuJczL4=fsaFyG9Yjcgw@mail.gmail.com> <CABcZeBNcnW9zEPZ4mEje1_ejR3npNFz65rw-6qUPn7cQt1Nz9w@mail.gmail.com> <CAAF6GDe1_ih1aUShrzAHUuTzbLx6+0BdVexpGnq90RZsST8GvA@mail.gmail.com> <CABcZeBOX5NXuhgfap2S0naO9PFXv+K-+fZVPbgck6yciVnrYbQ@mail.gmail.com> <CABcZeBPuOupLTNKOtuCgOjYNdiuw571HM-pq1vNZz_8x-XX5mg@mail.gmail.com> <CABcZeBMqALJ10cU7FMUhv8k5Q=tw3yu1-5pdrKzOBM3=g5PHJw@mail.gmail.com> <20170519095316.GA30080@LK-Perkele-V2.elisa-laajakaista.fi> <CAAF6GDeuRMZx9MRynrxMp1fCvRS2jjr0vcqt0R89cJEkD6u=rQ@mail.gmail.com> <20170520101616.GC32428@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBNj_X4qbXrH4732kQiAHrBpPZhW1nmn4Xnp-pm0gv1Psg@mail.gmail.com>
From: Colm MacCárthaigh <colm@allcosts.net>
Date: Sun, 21 May 2017 19:28:45 -0700
Message-ID: <CAAF6GDcEKaBaJZU0q822KqoJDL5kyZJGbOBKsnU9tnpU=YvoxA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Ilari Liusvaara <ilariliusvaara@welho.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a113f5ae66c3327055013a1a5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1HrFLik1rNlKOlPsudHPLO7CtZ4>
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: Mon, 22 May 2017 02:28:49 -0000

On Sun, May 21, 2017 at 3:47 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> - Clients MUST NOT use the same ticket multiple times for 0-RTT.
>>
>
> I don't understand the purpose of this requirement. As you note below,
> servers are ultimately responsible for enforcing it, and it's not clear to
> me why clients obeying it makes life easier for the server.
>

I think clients should duplicate them sometimes, just to keep servers on
their toes ;-) this is what we talked about maybe being a grease thing ..
if at all.

- Servers MUST NOT accept the same ticket with the same binder multiple
>>   times for 0-RTT (if any part of ClientHello covered by binder is
>>   different, one can assume binders are different). This holds even
>>   across servers (i.e., if server1 accepts 0-RTT with ticket X and
>>   binder Y, then server2 can not accept 0-RTT with ticket X and binder
>>   Y).
>>
>
> I assume that what you have in mind here is that the server would know
> which tickets it was authoritative for anti-replay and would simply reject
> 0-RTT if it wasn't authoritative? This seems like it would significantly
> cut
> down on mass replays, though it would of course still make
> application-level
> replay a problem.
>
> I'm happy to write this up as part of the first two techniques. I'd be
> interested in hearing from others in the WG what they think about:
>
> 1. Requiring it.
> 2. Whether they still want to retain the stateless technique.
>

I'm for requiring it, and for removing the stateless technique ... because
it prevents the side-channel and DOS attacks and those seem like the most
serious ones (and also, the new ones).

So far each case where we've thought "Actually stateless might be ok in
this case" ... like the example of DNS ... turns out not to be safe when
examined more closely (in DNSes case it would compromise privacy because
caches could be probed).

-- 
Colm