Re: [TLS] WG review of draft-ietf-tls-rfc4492bis

Yoav Nir <ynir.ietf@gmail.com> Thu, 04 May 2017 17:59 UTC

Return-Path: <ynir.ietf@gmail.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 750AB129AFF for <tls@ietfa.amsl.com>; Thu, 4 May 2017 10:59:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 U1BWKLW_Aem1 for <tls@ietfa.amsl.com>; Thu, 4 May 2017 10:59:40 -0700 (PDT)
Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 B0673129B10 for <tls@ietf.org>; Thu, 4 May 2017 10:59:34 -0700 (PDT)
Received: by mail-wm0-x244.google.com with SMTP id y10so4994577wmh.0 for <tls@ietf.org>; Thu, 04 May 2017 10:59:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=l7VduV8yKNCf3M8Ukg6YyMR8KXTsbdkbdw3INilq/C0=; b=DVpuSlk8uRXCZ4j3G0gkkxukzfjwwV6TkR72sfmEoh1sTslNLUs9D+h66iIqFZvwun Tb3apGeMDnszGAkvsC1HAeqtR8mVHEtkvSwf2ZAs1+Zts52eIk6I3IAx/W7WoygcLMkC cfpOoqWaYQEgIkjuED8Oq9c1FBlGkJ0hGMfCnXVl5QauGODaXar9JaQi1Xf0HX58OX7t F2UG8sjixzA8tmR7WCV03sNM+nPwmPJdemnUJgaBWrpRorDWj+rhNziqcWPtHR0QFODU 9KZC8ZajKaf4veBmwTUuK9AHccW9K1HN6m4751eLLGnJMNidSObK2+T5fznIWdjnsXnD V3Og==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=l7VduV8yKNCf3M8Ukg6YyMR8KXTsbdkbdw3INilq/C0=; b=fpy3OSOwWZTbBjZTfvkqZ7yAaWnWPYHxAkjOZ0n1SOBvAIR/0NoBFf/5C/mZHPw/Ki dWjLW7+eP57IEgVfHDvey5wWw51rxXmPAPu+auwZsmB2bZRlbJj5m9DFwKfGCFtRvL59 qwpK77keDbnGSWWiKL/9r86zv9bPgmYw8pfBkRygARj1gV/ikk3v/BbPzZoQ5scZkk82 StEV5YXI+GX9iRN5I36mRcMyxXagrmp7Mp+AqBbQaHLaiXfR0BgacRLuqnmK5qtZvPt3 nsseMjRyOE+QC7oa0r+15cGc6GUezr/J60MBP/Vv48KU3Chx3t+jkh4w0+YL+nMSOIqh kgkg==
X-Gm-Message-State: AN3rC/45X5sOgi/RlHJ9tQ84BGG0Pmlwf+Pqb4RK+D4LtQoJatuaCEPq QG/XBNUhE2UnxQ==
X-Received: by 10.80.174.230 with SMTP id f35mr31035333edd.157.1493920773264; Thu, 04 May 2017 10:59:33 -0700 (PDT)
Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id s42sm781687edb.22.2017.05.04.10.59.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 May 2017 10:59:32 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <73E0FBFC-34E4-4897-BE04-CD51728FE9BF@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_4344694C-3500-4DC7-8CFF-BCC09D7BCB03"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 4 May 2017 20:59:29 +0300
In-Reply-To: <04081892-66A1-4459-875D-0C147A5826F0@gmail.com>
Cc: Hubert Kario <hkario@redhat.com>, tls@ietf.org
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
References: <F7262846-0E93-4780-B051-8DB1253ADCE5@sn3rd.com> <4372384.YAPbqjqF3g@pintsize.usersys.redhat.com> <04081892-66A1-4459-875D-0C147A5826F0@gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/q9K_EvqA5H5WAVrkR6I3a69JDTk>
Subject: Re: [TLS] WG review of draft-ietf-tls-rfc4492bis
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 04 May 2017 17:59:42 -0000

> On 4 May 2017, at 16:09, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
> 
> I haven't approved it yet as I noticed there was no response (that I saw) to Alexey's comment and no change in the draft as a result of his comments.


You mean these comments?
https://mailarchive.ietf.org/arch/msg/tls/MFs8aGEZsr-1P7o4_CB-VjxXRg0 <https://mailarchive.ietf.org/arch/msg/tls/MFs8aGEZsr-1P7o4_CB-VjxXRg0>

I’ll quote them here:

> 0) There is some general awkwardness in text talking about allowed points
> formats, considering that only uncompressed form is now allowed. I don't
> have recommendations about improving text, other than the following:
> 
> If no future formats are expected, it feels almost better to recommend
> against inclusion of the Point formats extension, as lack of it means
> uncompressed format anyway.
So this was addressed in draft -16:

OLD:
      Implementations of this document MUST support the
   uncompressed format for all of their supported curves, and MUST NOT
   support other formats for curves defined in this specification.  For
   backwards compatibility purposes, the point format list extension
   MUST still be included, and contain exactly one value: the
   uncompressed point format (0).

NEW:
      Implementations of this document MUST support the
   uncompressed format for all of their supported curves, and MUST NOT
   support other formats for curves defined in this specification.  For
   backwards compatibility purposes, the point format list extension MAY
   still be included, and contain exactly one value: the uncompressed
   point format (0).  RFC 4492 <https://tools.ietf.org/html/rfc4492> specified that if this extension is
   missing, it means that only the uncompressed point format is
   supported, so interoperability with implementations that support the
   uncompressed format should work with or without the extension.


> 1) In Section 2.3, last paragraph: Does this paragraph apply only to 2.3
> or does it also apply to 2.1 and 2.2? If the latter, then it needs to be
> moved to section 2.

The content of the last paragraph was moved to a new section:
2.4 <https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-16#section-2.4>.  Algorithms in Certificate Chains

   This specification does not impose restrictions on signature schemes
   used anywhere in the certificate chain.  The previous version of this
   document required the signatures to match, but this restriction,
   originating in previous TLS versions is lifted here as it had been in
   RFC 5246 <https://tools.ietf.org/html/rfc5246>.

> 
> 2) In Section 6:
> 
>    Server implementations SHOULD support all of the following cipher
>    suites, and client implementations SHOULD support at least one of
>    them:
> 
>    o  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>    o  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
>    o  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
>    o  TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
> 
> GCM ciphers are not listed in the table earlier in the same section. They
> are defined in RFC 5289. This document doesn't have any reference to RFC
> 5289 and GCM ciphers are not discussed anywhere else in the document.

Seems like I missed this one.

Yoav