[TLS] AD review of draft-ietf-tls-rfc4492bis-12.txt
Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 17 February 2017 16:58 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
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 91E2112951D for <tls@ietfa.amsl.com>; Fri, 17 Feb 2017 08:58:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 DCU43w4nxJqW for <tls@ietfa.amsl.com>; Fri, 17 Feb 2017 08:58:35 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D673B1294FB for <tls@ietf.org>; Fri, 17 Feb 2017 08:58:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 588EBBEB5 for <tls@ietf.org>; Fri, 17 Feb 2017 16:58:32 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23xZ1LOSwXhw for <tls@ietf.org>; Fri, 17 Feb 2017 16:58:32 +0000 (GMT)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BD3F8BE77 for <tls@ietf.org>; Fri, 17 Feb 2017 16:58:31 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1487350712; bh=HLjJgWOJ06NRKC8H62PMRdYgbitW3Rwyw2ykyZGrq3w=; h=To:From:Subject:Date:From; b=c0sbZtvf7tmbiMImaHvAtHAreSeTFAC/seiLTvt8kvWgT7ehjJ35cPipf482ewMba S7F58kLrSIUGMPyvIt3rMe/0pB7k9OjLyEspOhrksuuYwuAcEp7sm+okMl0cpYZv/f U5AXo7vgZhmh0+lQURXMtdxMXyNFVV0bbjKam2T0=
To: "tls@ietf.org" <tls@ietf.org>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <f6240519-9835-9568-99ab-9635ad2236fa@cs.tcd.ie>
Date: Fri, 17 Feb 2017 16:58:31 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="VG4EdKDE66wp7Sdi2RP23WCmCAO6rNV7h"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/avM0tMVX25P_MWbHvRCSKfh8qdY>
Subject: [TLS] AD review of draft-ietf-tls-rfc4492bis-12.txt
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: Fri, 17 Feb 2017 16:58:36 -0000
Hiya, I've had a read of this and asked for IETF LC to start. My comments below can be handled with any other IETF LC comments. Thanks, S. - Bits of this are fairly complex reading, given that ECC isn't trivial and nor are the changes nor how they were done to keep some things more or less backwards compatible. It'd help I think if we could say something more about implementation status in the shepherd write-up. - abstract: doesn't this need to say that this obsoletes RFC4492 in the abstract text. (Yes, PITA formalities, I know:-) - 5.1.1: "Note that other specifications have since added other values to this enumeration." Could/should we reference those others? I don't care, but someone will ask and it'd be good to have the answer in the archive if it's "no, and here's why..." - 5.1.1: Is this text still correct: "secp256r1, etc: Indicates support of the corresponding named curve or class of explicitly defined curves." Do we need to say there that we're ditching explicitly defined curves? - 5.2: Is this still right, given the deprecation of compressed points earlier? " Note that the server may include items that were not found in the client's list (e.g., the server may prefer to receive points in compressed format even when a client cannot parse this format: the same client may nevertheless be capable of outputting points in compressed format)." - 5.3: Doesn't this need a change: "...unless the client has indicated support for explicit curves of the appropriate type"? Maybe more change is needed in that para as well? - section 6: Do we still need the *_NULL_* suites? - Just checking, I assume this is down to editing history but what happened to TBD1 and TBD2?
- [TLS] AD review of draft-ietf-tls-rfc4492bis-12.t… Stephen Farrell
- Re: [TLS] AD review of draft-ietf-tls-rfc4492bis-… Yoav Nir
- Re: [TLS] AD review of draft-ietf-tls-rfc4492bis-… Stephen Farrell