Re: [TLS] 2nd WGLC: draft-ietf-tls-tls13

Benjamin Kaduk <bkaduk@akamai.com> Tue, 18 July 2017 18:10 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 E8799131B3B for <tls@ietfa.amsl.com>; Tue, 18 Jul 2017 11:10:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, 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 VRiPoDzz0JEr for <tls@ietfa.amsl.com>; Tue, 18 Jul 2017 11:10:58 -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 3323A129AD3 for <tls@ietf.org>; Tue, 18 Jul 2017 11:10:58 -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 v6II7LT9005068; Tue, 18 Jul 2017 19:10:56 +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=6Xx626qt7Q37dKfgZpBw/vLbEZsppoUnefm5ukgUHtE=; b=iUCWIi38Nnea7VPEZbi9wI5QVQVNKP2VE3VlJooMAafglxMI8/JXfW+Mkadakkejoh6r W35ERuKTMp9s9hHigj4i5dYo4J0aN+FKEAij/EsPyaQ8tnhAuU7OyusjomSgVymrrtDa Xu1BKXQ1cqjnDV6GkqfEGrsvML4hVSAwTdzGl+h1r5uM0TVI68QKxQ0/gQ9JUX0KYphE 5ktlLn7XGMc149tBrnMelrXXuWYsWwKhTE5EAg8R2/aL+LLbsBxJJmq8pJsxKWunT0Xi MR6WOjUOzQ01H+zPdrF6mq9A8gafGiQiug+bHG2EiYs3pupFVIXPA9vvmFizJY/3TZlv tg==
Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2bqak4x1pd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Jul 2017 19:10:56 +0100
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v6IIATwu008401; Tue, 18 Jul 2017 14:10:55 -0400
Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2bqecv1mb0-1; Tue, 18 Jul 2017 14:10:55 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 0188B20064; Tue, 18 Jul 2017 12:10:54 -0600 (MDT)
To: Eric Rescorla <ekr@rtfm.com>
Cc: Sean Turner <sean@sn3rd.com>, "<tls@ietf.org>" <tls@ietf.org>
References: <4783B0DF-445C-4AF0-8EF1-AB396A97B947@sn3rd.com> <e14760fb-c45e-fbf6-270b-cdf173c757bc@akamai.com> <CABcZeBO_2tDVon4e8MU2jcq-2rYcUNfKESkPJe2ZjzWfoE_ESg@mail.gmail.com> <752c2b4e-fb24-6857-ac88-e42504029dd6@akamai.com> <CABcZeBMQ-oPW61my5+7tQSJucV6_zo16j4nmqz=PEztrxG9kxg@mail.gmail.com>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <261d0fe6-764f-81d8-2701-f4031de8eb36@akamai.com>
Date: Tue, 18 Jul 2017 13:10:54 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CABcZeBMQ-oPW61my5+7tQSJucV6_zo16j4nmqz=PEztrxG9kxg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------E79E8759F352DBE6B4E653AC"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-18_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707180283
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-18_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 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-1706020000 definitions=main-1707180283
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/rsLAH58ANiUu2NTrs4ON4gEOXGg>
Subject: Re: [TLS] 2nd WGLC: draft-ietf-tls-tls13
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: Tue, 18 Jul 2017 18:11:00 -0000

On 07/18/2017 08:07 AM, Eric Rescorla wrote:
>
>
> On Wed, Jul 12, 2017 at 3:39 PM, Benjamin Kaduk <bkaduk@akamai.com
> <mailto:bkaduk@akamai.com>> wrote:
>
>
>     That is, in this case, the CH+0RTT data can be replayed by an
>     observer once enough time has elapsed that the
>     expected_arrival_time is within the window, similar to one of the
>     reordering attacks mentioned elsewhere.  We could add the CH to
>     the strike register in this case, which would bloat its storage
>     somewhat and have entries that take longer than the window to
>     expire out.
>
>     I don't have a good sense for how often we expect postdated CHs to
>     occur and whether the ensuing breakage would be manageable, but
>     I'm not sure that we've thought very hard as a group about this
>     question.
>
>
> I think post-dated are going to happen pretty often based on what I
> understand from
> Kyle and others. I wouldn't be comfortable with hard fail, especially
> given that this
> just seems like the dual of the other case. Adding the CH to the list
> seems like
> a problem because it might stay forever.
>

The "stay forever" part is awkward, yes.  It would be great if Kyle/etc.
could say a bit about why post-dated seems likely on the list, but I
guess for the purposes of WGLC we can consider this comment resolved.

-Ben