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

Benjamin Kaduk <bkaduk@akamai.com> Sun, 04 June 2017 20:51 UTC

Return-Path: <bkaduk@akamai.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 DF310129420 for <tls@ietfa.amsl.com>; Sun, 4 Jun 2017 13:51:54 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 k-E7bQKH-cm3 for <tls@ietfa.amsl.com>; Sun, 4 Jun 2017 13:51:53 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A08BB128D2E for <tls@ietf.org>; Sun, 4 Jun 2017 13:51:53 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v54KkwMR014009; Sun, 4 Jun 2017 21:51:51 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=D3Tx06jx1mV6DoxTznEKcM9qrHqSEhDznZyfZDkuRy8=; b=H66kJvAlxhNNnzV+4Hpu2Yn0HpxaEOBn0SxolqjVro72zbPSZ7h3h1hsNweeEeC+1GXf UKusWsxw8mOZXyNBKMGzMP/dPXaNuTNpFa8aADDc6PMzYFbQnsKAG5iGUB56qMZgNzWo 9zlq80Xlm+2ErynbtBWy4XWOKlPqQJ06zhv3RgRw1BeGit8N34gidy6k2d3xvvHntdea TpU++zhbVggIuRJsAomuQIXxV3EfQZy82MvuLpkHfqcC6HsJor9UKbNPiC1YXvCzIYHX wiUhuIZBFIjY3ogWArawkIufyKlzk8dgNXfWt1uvZM51Dv532TtDgKWwDNlbXhH3h5+0 LQ==
Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2aumn3frs7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 04 Jun 2017 21:51:51 +0100
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v54Kp7P1032638; Sun, 4 Jun 2017 16:51:50 -0400
Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint3.akamai.com with ESMTP id 2avfe58v3a-1; Sun, 04 Jun 2017 16:51:50 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 23C7B80059; Sun, 4 Jun 2017 14:51:50 -0600 (MDT)
To: Bill Cox <waywardgeek@google.com>
Cc: "tls@ietf.org" <tls@ietf.org>
References: <CAAF6GDcKZj9F-eKAeVj0Uw4aX_EgQ4DuJczL4=fsaFyG9Yjcgw@mail.gmail.com> <CAAZdMacpJ-qoQt2pDBjTq6ADwmRKOHXTHDyDTzb+g2gYPvtZzQ@mail.gmail.com> <CAAF6GDdobkQh9_iqX1oU_BO9O2aK2_7Cbaper0AY4qEGYXAcvA@mail.gmail.com> <CAAZdMaeTdcgdCj26kVuq6-0EX1nmehvJJCq+YzB-4r84aRjhuA@mail.gmail.com> <CAAF6GDesLzMDN_LVYr6sFU8Z04jpXhFZphOAet-0JPsFF56Oig@mail.gmail.com> <CAAZdMadDctG0sMyDV49+8UUiagqQpi0bSehtQuKPELMU-+Gg5g@mail.gmail.com> <CAAF6GDfZr_zEuttf2zQhJ9vv2T-e1Mzb3G09_auLReftSJveeg@mail.gmail.com> <CAAZdMacwnX2-eu5Ts_XEbiq7bx=XttpM95tZb7qJeBf7BsrYog@mail.gmail.com> <CAH9QtQET_1WzdHfgO1DbeM5yYKYORyimCy3Kbz5yjGNmBF63Jg@mail.gmail.com>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <56993d9b-d642-13e7-ba1d-17d8347e0294@akamai.com>
Date: Sun, 04 Jun 2017 15:51:49 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <CAH9QtQET_1WzdHfgO1DbeM5yYKYORyimCy3Kbz5yjGNmBF63Jg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------A922BC15B850B2436763505E"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-04_16:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706040402
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-04_16:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706040400
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/15JV9uppR6ENGgVnRGzuxTnnmtw>
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: Sun, 04 Jun 2017 20:51:55 -0000

On 06/04/2017 02:08 PM, Bill Cox wrote:
> My feeling is that when talking to stateless 0-RTT servers, browsers
> should send only idempotent HTTP requests, and accept
> less-than-perfect FS.  I also feel they should avoid attempts at
> client auth over 0-RTT.  However, when talking to servers that prevent
> replay (but not re-transmission) I think browsers should be free to
> send any HTTP requests over 0-RTT, and also attempt client auth.  The
> security properties of 0-RTT data are still different, but for
> browsers, where it does not matter whether the re-transmission is in
> the browser or TLS layer, the security seems equivalent to me.

I think we're at a point where multiple people have expressed what their
(subjective) feeling on the desired behavior is, and those feelings are
not in agreement.

So, some more concrete reasoning and deductions seem required in order
for such contributions to be useful towards reaching consensus.

-Ben

P.S. It seems pretty well established that a client will not in general
have a good idea whether it's talking to a server that prevents replay
or is stateless.