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

David Benjamin <davidben@chromium.org> Fri, 19 May 2017 20:49 UTC

Return-Path: <davidben@google.com>
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 1E51A129B23 for <tls@ietfa.amsl.com>; Fri, 19 May 2017 13:49:56 -0700 (PDT)
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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 gsgJ5t0zbnkO for <tls@ietfa.amsl.com>; Fri, 19 May 2017 13:49:54 -0700 (PDT)
Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (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 61DEC129B19 for <tls@ietf.org>; Fri, 19 May 2017 13:49:54 -0700 (PDT)
Received: by mail-pg0-x22b.google.com with SMTP id x64so42997705pgd.3 for <tls@ietf.org>; Fri, 19 May 2017 13:49:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b4lt4YyChyTKzQOgpBN3zVNwq0mQ5kAxcRfknxj5izY=; b=CSoZCjcv4PQT+vibNrvoIM8MCsF+K298rjYpvwi2VhpNZ25mAEF8dOMbFJ6c6i0Fmv oRLN0CUCQU/a80eoJRlYRfAgwUAyicaNcjB3+hrpVv8GfAsxX6/AlAL76sY9W6fwUVpY wJ5O54Ldh91f04+HxwSJTbZMZRdM3wIxeBgsc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b4lt4YyChyTKzQOgpBN3zVNwq0mQ5kAxcRfknxj5izY=; b=cFA03cbd3cfCctJwCVEpOGBw7MRuVVCit9DOqIWoFrOvSrUXIm/sAk43w8OS/W5VUo TblF8IN4dmdxzd7h++8r3nqYKC9VSEl2h3SMtxeJQUMz7d0p21S7L6F70vycOcyKB/kH 3+IZ2ZhbxbBJIbxkN2YAmN4p0EYGcg5sD/mGECp2umktKjtl25mSWNxou8gptO3HcO6x AHkb/eWFP6xrVeHaqP6VwnscrvAt7bI/xVXBolE2KqqnWTMH4OhQzP8GZfONWkF3q46i glwIkHrS5C5NPfwhOEI5I3BTh7q73yYbKwVJ8xq3utxmnCMMi2bkeuyDC5qYdPvwiV4S af8Q==
X-Gm-Message-State: AODbwcC+cCHj/G3z3yj28qmHgpg/w2S4M5O+Flm7oumHE7OQkl45+JjJ bm/BWsbKM8dGLUBxQgKX9JTKekIPa0PT
X-Received: by 10.98.153.76 with SMTP id d73mr12490725pfe.223.1495226993856; Fri, 19 May 2017 13:49:53 -0700 (PDT)
MIME-Version: 1.0
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> <20170519184051.GA31741@LK-Perkele-V2.elisa-laajakaista.fi> <CAAF6GDcP3_+WOB1xsc7JecpCo2-MfeuHgkN7PVrUiLweeurv2g@mail.gmail.com>
In-Reply-To: <CAAF6GDcP3_+WOB1xsc7JecpCo2-MfeuHgkN7PVrUiLweeurv2g@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Fri, 19 May 2017 20:49:42 +0000
Message-ID: <CAF8qwaByGeGtap8gDB-p3n-0DMqEL9uJGJQ4EErfkq-SFcbHGQ@mail.gmail.com>
To: Colm MacCárthaigh <colm@allcosts.net>, Ilari Liusvaara <ilariliusvaara@welho.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0bd3ead4483f054fe6a9ca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/QRQ1_4Rv-e4ToaP6kVwuT7JUq8k>
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: Fri, 19 May 2017 20:49:56 -0000

Seeing as this utterly ridiculous ticket_age_add thing is partially my
fault, I suppose I should respond:

On Fri, May 19, 2017 at 4:10 PM Colm MacCárthaigh <colm@allcosts.net>
wrote:

> > And then separate to all of the above, and lower priority:
>> >
>> > * There's a contradiction between the obfuscated ticket age add
>> parameter
>> > and the desire to use tickets multiple times in other (non-0RTT) cases.
>> We
>> > can't do one without defeating the point of the other. Either remove the
>> > obfuscation because it is misleading, or move it into an encrypted
>> message
>> > so that it is robust.
>>
>> The purpose of obfustication is not to hide sibling sessions. The
>> client already blows its cover by using the same session ID twice. The
>> purpose of obfustication is to hide the parent session.
>
>
>> Are you talking about attackers being able to determine the rate of
>> client clock?
>>
>
> Right now if a ticket is used multiple times, then the ticket age can be
> derived (trivial cryptanalysis due to re-using the same obfuscated offset,
> and because the progression of time between the ticket uses is public);
> that means the parent session can be identified. So the point is defeated.
>

Could you expand on your cryptanalysis? I don't believe this is actually
leaked. It's addition mod 2^32, not XOR, which means you effectively
randomize the parent starting time. (It was initially XOR, and then
shortly changed
to addition
<https://www.ietf.org/mail-archive/web/tls/current/msg20376.html>.)
Consider:

initial connection at time t1, issues a ticket with ticket_age_add = x. Let
t1' = t1 - x.
Resumption 1 at time t2, offers t1's ticket. The attacker learns t2 - t1 +
x = t2 - t1'.
Resumption 2 (or HelloRetryRequest) at time t3, offers t1's ticket. The
attacker learns t3 - t1 + x = t3 - t1'.

x is uniformly distributed over [0, 2^32), so t1' = t1 - x is as well. This
is a one-time pad on t1, correctly used only once. x is only ever used to
encrypt one timestamp, t1.

Of course, the attacker can correlate t2 and t3 by subtracting the two
public values and checking against the public difference between
connections they observe. But the ticket's already leaked anyway.


> Either the one-time-pad can be used just one time (which means the ticket
> can be used just once) or we should move it to an encrypted message. Or
> just get rid of it and not be so misleading. But the current state is
> weird, to say the least.
>

I believe stuffing something into an AEAD was proposed and then rejected by
the cryptographers for some reason? You'd have to ask other folks for
details. I just recall being told that was a previous rejected proposal.
Accordingly, I suggested the dumbest thing that could possibly work,
intending it be so dumb that it could not possibly have consequences beyond
patching that correlation hole. :-)

David