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

Benjamin Kaduk <> Tue, 11 July 2017 20:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DBE9D1317D6 for <>; Tue, 11 Jul 2017 13:39:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=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 4bO6FSRGDCb5 for <>; Tue, 11 Jul 2017 13:39:26 -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 8722D131795 for <>; Tue, 11 Jul 2017 13:39:26 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id v6BKbfO0015097; Tue, 11 Jul 2017 21:39:25 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=LaumMie2jpsgJJ+5jYMTejixP4Wrgm4eab1neLhe0bQ=; b=pDmb5VfLjBIztG5KKmV9+vvbgPrFaW2C1ev6+cyOOyaz8tSoISEe8u6LZoeGhIFIZ0yS 7GPX1/m76JMoSEieSfN4wNVhUi0fXfpG/mpd0Pty+0bxLrf0b+er1LQ1KrsMwRNksoJU tJ5Ih2PC7ZGnscKqKTzArSz21bRy/smXXD+HJU64Ifu+wumssjkeKedcg2J69yYuvzQg HmwioFu9BxNYxiRLCXs/MonG0Bca8ukDqyEd+itu4BquSkuV0Y/evSuiGiwCDs1eQC2l oDGvkY5oRl1qBEPs8illDTejs7DPH37BEzlEakW9MZo5Rdam2Wv/mMXuagJWO7rd2hAM oQ==
Received: from prod-mail-ppoint4 ([]) by with ESMTP id 2bn0p3he9x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 11 Jul 2017 21:39:25 +0100
Received: from pps.filterd ( []) by ( with SMTP id v6BKZw1j016440; Tue, 11 Jul 2017 16:39:24 -0400
Received: from ([]) by with ESMTP id 2bn0p212a8-1; Tue, 11 Jul 2017 16:39:24 -0400
Received: from [] ( []) by (Postfix) with ESMTP id 0AB2920064; Tue, 11 Jul 2017 14:39:23 -0600 (MDT)
To: Sean Turner <>, "<>" <>
References: <>
From: Benjamin Kaduk <>
Message-ID: <>
Date: Tue, 11 Jul 2017 15:39:23 -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: <>
Content-Type: multipart/alternative; boundary="------------BA90ABB30F3B8FC510F5228B"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-11_10:, , 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-1707110330
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-11_10:, , 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-1707110330
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: Tue, 11 Jul 2017 20:39:29 -0000

On 07/03/2017 10:53 PM, Sean Turner wrote:
> All,
> This is the 2nd working group last call (WGLC) announcement for draft-ietf-tls-tls13 to run through July 18th.  This time the WGLC is for version -21 (  Note that this WGLC ends before the Wednesday TLS WG session @ IETF 99.
> Also note that this WGLC is a targeted WGLC that only address changes introduced since the 1st WGLC on version -18, i.e., changes introduced in versions -19 through -21.  Note that the editor has kindly included a change log in s1.2 and the datatracker can also produce diffs (for some reason it’s not working for me right now).  In general, we are considering all other material to have WG consensus, so only critical issues should be raised about that material at this time.

Duly limiting myself to reviewing just the changes from -18 to -21, I do
still have some comments.

The main issue is one that I have raised previously but does not seem to
have been resolved by the group, namely, that I think we should have a
MUST-level requirement for some stronger anti-replay scheme than the
freshness checks of section 8.3.  I do not think that we need to mandate
specifically the single-use tickets of section 8.1 or the ClientHello
recording scheme of section 8.2, and can leave freedom for
implementations to choose alternate schemes, but do think that we will
be on the wrong side of the "we're building a security protocol"/"we're
building an easy-to-implement protocol" divide with the present
SHOULD-level indication.

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?  Or
perhaps we should just make the time window for 0-RTT acceptance
half-infinite and not bother rejecting things that claim to be in the
future; that probably has some robustness arguments in its favor.

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?

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.

I also found some issues that I believe to be purely editorial, for
which I will submit a pull request.

I will probably try to make another full review pass over the entire
document (mostly looking for editorial things), but I have until the end
of IETF LC for that, right? ;)