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

Eric Rescorla <> Mon, 14 November 2016 01:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5808112969C for <>; Sun, 13 Nov 2016 17:45:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 GPw88bvosrY5 for <>; Sun, 13 Nov 2016 17:45:24 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BBCE1129649 for <>; Sun, 13 Nov 2016 17:45:22 -0800 (PST)
Received: by with SMTP id a184so20123848ybb.0 for <>; Sun, 13 Nov 2016 17:45:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iEtt9UaP8olN1xH8om9Eu+aWdA7Crp8VLbcMv9ZsyyM=; b=UZAU3vcL1uA1I/Q8hhCtg50sqhyn9m4Vrp3DUh0wDdo2ejviD6dc+ZnmxXcor0dv2Y rYi3dKIdL5DNUoTxtR5NR7eLWrBzvuDaU2JHulUnS1qIED26UFOgC9pKfXnLR80wdaOZ QTaovxBcp7ipCVHlXsdCUUqo7Upg/6VCvDreEgCPQAxbeOSiGervR02K2gjCQ2b3wRTF kMphzqZGRkVnOEihnUy86t6R06nrYsCal1w3TAq6VSnA3aPkTLD5SuTyToBysSMYw/c2 8AFx4Vm2dTYICx+V3Lk8qMp3Z7h113JkbQ7VIKgzQOeCdRJfWwrxR4hNwTxaSp6imxgh Cf8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iEtt9UaP8olN1xH8om9Eu+aWdA7Crp8VLbcMv9ZsyyM=; b=ctcJ5BVoZ/MZn78VrQZ+GOYx+xwGuUsU2p9eYMQf4y5j9i81+0AGb0+uQcwWkwXJyB c5t1fC1Cp7D70Xp2PrYl4GZPvPKK5bLB06oxY1Wi5e+UoMTnTUSo/gnDmCOtW6CRR6BZ TwxIPNgRW3ecHfXzheQXAOK0n9P7FjZUAp6/7m3cmTX/sjju/U3UjcpIGCDlOvacgmDw ZOzHXrGnYO57VH/JnJoRdpJeRsScxYH9Pvk9qw8uA9vTNO2hiTywGrga76inqiqiX5vm i/shAg7SSwSuPMrn3lc9+BOw7A4HWg53F8vt8T20gGnJ56aWzGFog6nveIGLkIKllTm0 30Lw==
X-Gm-Message-State: ABUngvcS5oqvehHSrqsmuXbxCNwGrtoHSQFcaSy2/t8UpGB8ZVVZkZJtwqCsUttFYT86GC1eHW6pJ/+n8EPTDg==
X-Received: by with SMTP id t9mr13406655ybd.107.1479087921990; Sun, 13 Nov 2016 17:45:21 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 13 Nov 2016 17:44:41 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Eric Rescorla <>
Date: Mon, 14 Nov 2016 10:44:41 +0900
Message-ID: <>
To: "Kaduk, Ben" <>
Content-Type: multipart/alternative; boundary="f403045db0742ebf55054138fe7c"
Archived-At: <>
Cc: "" <>
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: Mon, 14 Nov 2016 01:45:30 -0000

On Mon, Nov 14, 2016 at 8:54 AM, Kaduk, Ben <> wrote:

> 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.)

I'd be interested in seeing a PR in this area.

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.

These are the recommendations in 7919, I believe

> 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.

It's not subsequent messages. You determine it from the PreSharedKey and
KeyShare extensions.

> 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?

I think I would rather not.

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.

I'm not following this point. The way to think about this is that the
ciphertext is a specific size. That may be encryption + auth tag or not
(it's possible to design an AEAD algorithm that doesn't have a separate
auth tag).


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.
> -Ben
> _______________________________________________
> TLS mailing list