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

Eric Rescorla <ekr@rtfm.com> Wed, 17 May 2017 00:44 UTC

Return-Path: <ekr@rtfm.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 BF35712EAC1 for <tls@ietfa.amsl.com>; Tue, 16 May 2017 17:44:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 sCjhy5V0jXPs for <tls@ietfa.amsl.com>; Tue, 16 May 2017 17:44:35 -0700 (PDT)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::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 EE22A12949D for <tls@ietf.org>; Tue, 16 May 2017 17:40:36 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id l74so46473426ywe.2 for <tls@ietf.org>; Tue, 16 May 2017 17:40:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ElRuGOR58JLyCbb6gCKMt8jDIWR0y0p4tyN8LkvtYvs=; b=WEK1yiTI6B8GsZZciWERby62l9vu1l0wt4BpViN2ZGs1KUR+PlNjFgZQz3lzTabj5R 5m4nSJSl0zxW4jI/rCV/FzjKmd+yoFT1QjhU8GSWW91TgprCNcA7Xd2JVFDJO7jaonrZ 0Hd5At68GcqOf0KLqbYAikx9pJ3nMfuMZ1bHpqxJfPm+8FuCnLo+8Xvn2JYA2E1EAslD uMAS/snzPn51bUp++54z78pNVp+Nj8RR01TlqIV4kG+w27FwyVloigrtAL1RnjladyUe 3ceqpmz5z5UxitH2VA9Nnjtt8WSpcKg5/rdAZNsBYYuwyK2V9JAT1NjWYJ+kxN8eQz3x UoUw==
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=ElRuGOR58JLyCbb6gCKMt8jDIWR0y0p4tyN8LkvtYvs=; b=ZIqkSZ89ZKh4/MKxO72XIaCFe74jnuz5J7y3dFeHUKBm3MklrBKwMaMVCddkHPygbC zsQ4osc2dAvZMfliYzPDSgQcZlboxe7R2FlFjhPZaiztzP8I9mVUx3N6W9Kp402IaKXz 2luXi5eyHn72KxULHPal6by457eQnjO+cjIx9Y0lePFVvKSwrw1em0shZMe/gi+Wg4FT /TCK7N/Ls9TihtPfNZvIE5AhpEqlqurW0X5kzh+2iRDIc5gKclcScxE2Xk2IHoZzOk5W d9R6oJ/jms6cwDZNc62v0QP6oo2cH7VLgAUl3FApW45c/rpi+Lz3be/dPIYRgBbrAMQZ qK3A==
X-Gm-Message-State: AODbwcDfpIiZP01IJLtzF9lg9+bIga+anAL7gQAnzpknDVQagiaQJ8xK +VC8wrP4jIJRr71fABtJ+MJWxo/YmID29Ig=
X-Received: by 10.129.85.83 with SMTP id j80mr577750ywb.283.1494981636125; Tue, 16 May 2017 17:40:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.131.150 with HTTP; Tue, 16 May 2017 17:39:55 -0700 (PDT)
In-Reply-To: <CABcZeBPuOupLTNKOtuCgOjYNdiuw571HM-pq1vNZz_8x-XX5mg@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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 16 May 2017 17:39:55 -0700
Message-ID: <CABcZeBMqALJ10cU7FMUhv8k5Q=tw3yu1-5pdrKzOBM3=g5PHJw@mail.gmail.com>
To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <colm@allcosts.net>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a113f3cbe5e0cce054fad89ef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/qTtO99dPqyM7h2XzF63lcFDDopQ>
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, 17 May 2017 00:44:38 -0000

On Thu, May 4, 2017 at 2:13 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> As promised:
> https://github.com/tlswg/tls13-spec/pull/1005
>
> Note: I may have to do a little post-landing cleanup, but I wanted to get
> people's senses of the text ASAP.
>

Thanks for everyone's comments. I've updated the text to address many of
them and
made comments in Github where I decided not to do so. Can those who have
read
the previous version please take a look?

I'd also like to merge PR#998. I haven't heard any real complaints about it
and it's
an improvement in any case. I'll await the chairs on that, though.

-Ekr



Comments welcome.
> -Ekr
>
>
> On Wed, May 3, 2017 at 8:21 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>>
>>
>> On Wed, May 3, 2017 at 8:20 PM, Colm MacCárthaigh <colm@allcosts.net>
>> wrote:
>>
>>>
>>>
>>> On Wed, May 3, 2017 at 8:13 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>>
>>>> I made some proposals yesterday
>>>> (https://www.ietf.org/mail-archive/web/tls/current/msg23088.html).
>>>>
>>>> Specifically:
>>>> 1. A SHOULD-level requirement for server-side 0-RTT defense, explaining
>>>> both session-cache and strike register styles and the merits of each.
>>>>
>>>> 2. Document 0-RTT greasing in draft-ietf-tls-grease
>>>>
>>>> 3. Adopt PR#448 (or some variant) so that session-id style
>>>> implementations
>>>> provide PFS.
>>>>
>>>> 4. I would add to this that we recommend that proxy/CDN implementations
>>>> signal which data is 0-RTT and which is 1-RTT to the back-end (this was
>>>> in
>>>> Colm's original message).
>>>>
>>>
>>> This all sounds great to me. I'm not sure that we need (4.) if we have
>>> (1.).  I think with (1.) - recombobulating to a single stream might even be
>>> best overall, to reduce application complexity, and it seems to be what
>>> most implementors are actually doing.
>>>
>>> I know that leaves the DKG attack, but from a client and servers
>>> perspective that attack is basically identical to a server timeout, and
>>> it's something that systems likely have some fault tolerance around. It's
>>> not /new/ broken-ness.
>>>
>>
>> Heh. Always happy to do less writing.
>>
>> Thanks,
>> -Ekr
>>
>>
>>>
>>>
>>>> Based on Colm's response, I think these largely hits the points he made
>>>> in his original message.
>>>>
>>>> There's already a PR for #3 and I'll have PRs for #1 and #4 tomorrow.
>>>> What would be most helpful to me as Editor would be if people could
>>>> review
>>>> these PRs and/or suggest other specific changes that we should make
>>>> to the document.
>>>>
>>>
>>> Will do! Many thanks.
>>>
>>> --
>>> Colm
>>>
>>
>>
>