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

Eric Rescorla <ekr@rtfm.com> Mon, 14 November 2016 01:45 UTC

Return-Path: <ekr@rtfm.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 5808112969C for <tls@ietfa.amsl.com>; Sun, 13 Nov 2016 17:45:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 GPw88bvosrY5 for <tls@ietfa.amsl.com>; Sun, 13 Nov 2016 17:45:24 -0800 (PST)
Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBCE1129649 for <tls@ietf.org>; Sun, 13 Nov 2016 17:45:22 -0800 (PST)
Received: by mail-yb0-x22b.google.com with SMTP id a184so20123848ybb.0 for <tls@ietf.org>; Sun, 13 Nov 2016 17:45:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; 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; d=1e100.net; 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 10.37.246.9 with SMTP id t9mr13406655ybd.107.1479087921990; Sun, 13 Nov 2016 17:45:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.159.141 with HTTP; Sun, 13 Nov 2016 17:44:41 -0800 (PST)
In-Reply-To: <13C3DBCF-2609-4560-A194-1FA422BE7EEE@akamai.com>
References: <CAOgPGoChDnFf-4Vxm1S021MXHhGGpTjniD6+124B7off2RzO6w@mail.gmail.com> <13C3DBCF-2609-4560-A194-1FA422BE7EEE@akamai.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 14 Nov 2016 10:44:41 +0900
Message-ID: <CABcZeBMB570XtAsZbARk9gztSaX==QCz=Ky2iRH4LRfzmfqpsA@mail.gmail.com>
To: "Kaduk, Ben" <bkaduk@akamai.com>
Content-Type: multipart/alternative; boundary=f403045db0742ebf55054138fe7c
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/5Yj1fKV3T53PNUpcL1fE6MTXINI>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
X-BeenThere: tls@ietf.org
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." <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: Mon, 14 Nov 2016 01:45:30 -0000

On Mon, Nov 14, 2016 at 8:54 AM, Kaduk, Ben <bkaduk@akamai.com>; 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 4.2.5.1 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).

-Ekr

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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>