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

Benjamin Kaduk <> Wed, 12 July 2017 22:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D481D12F26D for <>; Wed, 12 Jul 2017 15:39:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Status: No, score=-0.011 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, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 44lzc3b2PQOc for <>; Wed, 12 Jul 2017 15:39:23 -0700 (PDT)
Received: from ( [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CC5E112EB8C for <>; Wed, 12 Jul 2017 15:39:14 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id v6CMasVS023941; Wed, 12 Jul 2017 23:39:12 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=PZfr/K1/5+brHp0DfsIAszmG1Y2XYzlt897VlkpO/pk=; b=T18LRzQuJfc/K37GGVOxXaQf2rZWpr325kqsfElubR3aA9t8YMIyBTjDB+0yllnP8fNB APqw4Z/tTdp/CruxyAgHMbi9EwP2EOcx3IN0a3a+hCJWDCX3l/uuokY6kHplGfIsnsMR gtWteWlKagpd3czX1mQJbWvPBa+KuIG8QogUreID6VUcOMzK644pdTWHHcz3AdXByipG wubxS/CKTLF7jdoJ7T941k9HTQy6g7IdCH9piXgqlPpF/rylC2qcMjqwU11/dTZy4T9Z sBleLJpy0K4Z43HJEoBnYsk2PvgnXPZiM3CYw6nta2MszJ7hrXFKg+N6V+PdJHhBgw1T qA==
Received: from prod-mail-ppoint2 ( [] (may be forged)) by with ESMTP id 2bn0p3pu05-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Jul 2017 23:39:12 +0100
Received: from pps.filterd ( []) by ( with SMTP id v6CMaLSu001559; Wed, 12 Jul 2017 18:39:11 -0400
Received: from ([]) by with ESMTP id 2bn0p1v6es-1; Wed, 12 Jul 2017 18:39:11 -0400
Received: from [] ( []) by (Postfix) with ESMTP id 4C3571FC7B; Wed, 12 Jul 2017 22:39:11 +0000 (GMT)
To: Eric Rescorla <>
Cc: Sean Turner <>, "<>" <>
References: <> <> <>
From: Benjamin Kaduk <>
Message-ID: <>
Date: Wed, 12 Jul 2017 17:39:11 -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: <>
Content-Type: multipart/alternative; boundary="------------6C5DBF9EF3D8494EBD2AAAAA"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-12_07:, , 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-1707120360
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-12_07:, , 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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707120359
Archived-At: <>
Subject: Re: [TLS] 2nd WGLC: draft-ietf-tls-tls13
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Jul 2017 22:39:26 -0000

On 07/11/2017 03:50 PM, Eric Rescorla wrote:
> On Tue, Jul 11, 2017 at 1:39 PM, Benjamin Kaduk <
> <>> wrote:
>     Another question I also relates to 0-RTT, specifically with the
>     freshness checks and the case where the computed
>     expected_arrival_time is in outside "the window" by virtue of
>     being in the future. (See the Note: at the end of section 8.2.)
>     (The case where the expected_arrival_time is in the past can
>     clearly be treated as "this is a stale request" and the current
>     text about aborting with "illegal_parameter" or rejecting 0-RTT
>     but accepting the PSK is acceptable, even if it doesn't give
>     guidance as to what might cause someone to pick one behavior or
>     the other.)  I am wondering whether we should consider this to be
>     a potential attack and abort the connection.  I concede that there
>     are likely to be cases where this
>     situation occurs incidentally, for clients with extremely
>     fast-running clocks, and potential timezone/suspend-resume
>     weirdness.  But there is also the potential for a client that
>     deliberately lies about its ticket age and intends to replay the
>     wire messages when the age becomes in window, or an attacker that
>     records the messages and knows that the client's clock is too
>     fast, or other cases.  (A client that deliberately does this could
>     of course just send the same application data later as well.)  If
>     the time is only a few seconds out of the window, then delaying a
>     response until it is in the window and only then entering it into
>     the single-use cache might be reasonable, but if the time is very
>     far in the future, do we really want to try to succeed in that case?
> If the time is very far in the future, the text is supposed to tell
> you to fall back
> to 1-RTT...

I agree that that is what the text currently says.  I'm questioning
whether that's actually the behavior we want.

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.

>     It looks like we no longer do anything to obsolete/reserve/similar
>     the HashAlgorithm and SignatureAlgorithm registries; was that just
>     an editorial mixup or an intended change?
> <>

Oh right, I forgot about that -- thanks.

>     We removed the API guidance for separate APIs for read/writing
>     early data versus regular data, which I believe had consensus. 
>     But I thought we were going to say something carefully worded
>     about having an API to determine whether the handshake has
>     completed (or client Finished has been validated, or ...), and it
>     looks like this is buried at the end of E.5(.0), with the string
>     "API" not appearing.  It might be useful to make this a little
>     more prominent/discoverable, whether by subsection heading or
>     otherwise.
> Suggestions welcome for where this would be better....

I'll see if I have time to think about it some more.