Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

"Kaduk, Ben" <> Sun, 13 November 2016 23:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 832B412969D for <>; Sun, 13 Nov 2016 15:54:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pKLsFD89kXGW for <>; Sun, 13 Nov 2016 15:54:22 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CE03212969A for <>; Sun, 13 Nov 2016 15:54:22 -0800 (PST)
Received: from (localhost.localdomain []) by postfix.imss70 (Postfix) with ESMTP id 30EB116CB9D; Sun, 13 Nov 2016 23:54:22 +0000 (GMT)
Received: from ( []) by (Postfix) with ESMTP id 112C616C9E4; Sun, 13 Nov 2016 23:54:22 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=a1; t=1479081262; bh=eT+TkoDaXs0U5nSLfvNrraLTJbh3atQCBQNmhqMAFwo=; l=4078; h=From:To:Date:References:In-Reply-To:From; b=tis7r6KG9yctz4bFmiphNJkbrAxiNahQeetcOACYzHN//XTy5ePLLJcJrraNEBVK1 cPHklkJyKX//iHwNhhz92Sao7gd9h50yzMXpeTC80+9HlWdwE8U/zuUG9USjQWG65j m3ePb/RYLFtXvFZrFRTQCB/Pii5SwJNH8FhueQi8=
Received: from ( []) by (Postfix) with ESMTP id 0E2DE9808E; Sun, 13 Nov 2016 23:54:22 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 13 Nov 2016 17:54:21 -0600
Received: from ([]) by ([]) with mapi id 15.00.1178.000; Sun, 13 Nov 2016 17:54:21 -0600
From: "Kaduk, Ben" <>
To: Joseph Salowey <>, "" <>
Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
Thread-Index: AQHSL/2/xyFB68/ah0yZwHLj0TFHDaDXsoAA
Date: Sun, 13 Nov 2016 23:54:21 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
X-Mailman-Version: 2.1.17
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: Sun, 13 Nov 2016 23:54:24 -0000

I have reviewed this document and have a few minor comments.  I also have many editorial notes that can be addressed out of band.

In the abstract and introduction, we have text about the properties that TLS is expected to provide, like confidentiality, authentication, etc.  Do we want to say anything about avoiding side channels that might leak information about the data being exchanged?  I know that we are not 100% confident at what exactly we currently achieve in this area, but since we have mechanisms that attempt to achieve it, maybe it is worth mentioning.  (In a similar vein, as davidben reminded me recently, an attacker “who has complete control of the network”, as is our stated adversary, can do things like trickle packets in one by one and try to see, e.g., where the end of early data is and query handshake state.  So some things may not be avoidable.)

In section we talk about how for FFDH peers SHOULD validate each other’s public key Y by ensuring that 1 < Y < p-1, which is supposed to ensure that the peer is well-behaved and isn’t forcing the local system into a small subgroup.  Somehow I thought that additional checks were needed to avoid being forced into a small subgroup, but I guess that depends on what group it’s in, and I didn’t pull up the RFC 7919 reference when I was reading this document.

In section 4.2.7, we note that the server MUST NOT send the “psk_key_exchange_modes” extension, with the implication that the client must observer the types of handshake messages that are subsequently received in order to determine what the server selected.  I think that we had talked about this already some time ago, but just wanted to confirm that we are okay with increasing the size of the client state machine in this manner.

In section 4.5.1 we note that when client auth is not used, servers MAY compute the remainder of the client-sent messages for the transcript so as to issue a NewSessionTicket immediately after the server Finished.  Do we want to say anything about why a server might wish to do so?

The coverage of record payload protection (around section 5.2) seems to not always make careful distinction between TLSPlaintext, TLSCiphertext, TLSInnerPlaintext, and the fields therein.  In some sense this is editorial, but there were a lot of places that I flagged, so I wanted to call it out to the broader audience and get more eyes on it.  I also didn’t find a description of where the length of the AEAD authentication tag gets included into a length field for the ciphertext.

At the end of section 6.1 we have this little note that “it is assumed that closing a connection reliably delivers pending data before destroying the transport”, which, if I remember correctly previous discussion on this list, is not actually true for linux.  It is perhaps problematic to have an assumption that we know is not going to be held for a large proportion of implementations.