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 >
- [TLS] Working Group Last Call for draft-ietf-tls-… Joseph Salowey
- Re: [TLS] Working Group Last Call for draft-ietf-… Salz, Rich
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Ilari Liusvaara
- Re: [TLS] Working Group Last Call for draft-ietf-… Eric Rescorla
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Eric Rescorla
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Ilari Liusvaara
- Re: [TLS] Working Group Last Call for draft-ietf-… Sean Turner
- Re: [TLS] Working Group Last Call for draft-ietf-… Yoav Nir
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Salz, Rich
- Re: [TLS] Working Group Last Call for draft-ietf-… Watson Ladd
- Re: [TLS] Working Group Last Call for draft-ietf-… Yoav Nir
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Benjamin Kaduk
- Re: [TLS] Working Group Last Call for draft-ietf-… Yoav Nir
- Re: [TLS] Working Group Last Call for draft-ietf-… Ilari Liusvaara
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Salz, Rich
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Eric Rescorla
- Re: [TLS] Working Group Last Call for draft-ietf-… Daniel Kahn Gillmor
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Watson Ladd
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Adam Langley
- Re: [TLS] Working Group Last Call for draft-ietf-… Watson Ladd
- Re: [TLS] Working Group Last Call for draft-ietf-… Benjamin Kaduk
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Benjamin Kaduk
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Benjamin Kaduk
- Re: [TLS] Working Group Last Call for draft-ietf-… Salz, Rich
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Peter Gutmann
- Re: [TLS] Working Group Last Call for draft-ietf-… Kaduk, Ben
- Re: [TLS] Working Group Last Call for draft-ietf-… Eric Rescorla
- Re: [TLS] Working Group Last Call for draft-ietf-… Kaduk, Ben
- Re: [TLS] Working Group Last Call for draft-ietf-… John Mattsson
- Re: [TLS] Working Group Last Call for draft-ietf-… John Mattsson
- Re: [TLS] Working Group Last Call for draft-ietf-… Yuhong Bao
- Re: [TLS] Working Group Last Call for draft-ietf-… Eric Rescorla
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Thomson