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

Yoav Nir <ynir.ietf@gmail.com> Sat, 06 May 2017 06:53 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 DA0FC1292AE for <tls@ietfa.amsl.com>; Fri, 5 May 2017 23:53:53 -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 TVScQcYDf3sT for <tls@ietfa.amsl.com>; Fri, 5 May 2017 23:53:52 -0700 (PDT)
Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 79B85128C84 for <tls@ietf.org>; Fri, 5 May 2017 23:53:51 -0700 (PDT)
Received: by mail-wm0-x232.google.com with SMTP id u65so39622506wmu.1 for <tls@ietf.org>; Fri, 05 May 2017 23:53:51 -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=Q77Qz5ui5VtU1azslIEC4gDYv1fEccomfJirU7Iad1c=; b=sQJSIx8EbYd/v6XmNqc43F2cl/BgUWv+mjds9foX9iXuphNUMDPebQlIlUBVuXorGD B2OwuX7jWrYm1S1RBmguDWSyKxcDHx/tN0eUMXZIGfKJhJd3BhgbqnoEXPjO4KR2XfVG O0aMxq/kBV6/SQkQtR7UZU646yPf4Iwp6KlQjHFCor4tm2i0WX1Gvtn+FXLbPP1qO2V/ 6H9Y0gWrNMeMKedGcuR7PWXfnUXrNLogXUg9cTj0HOLF3xm671fewGRCaGXxjDXeOfHS SkqyZnUhUxMxy6TtmDr4oGG8IaAiw2ouiKqSaggLWV/zxz96D6hUbdcOblj+qbeF49Gk tYGA==
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=Q77Qz5ui5VtU1azslIEC4gDYv1fEccomfJirU7Iad1c=; b=Jp3SoyizfZlPmJ4Z7yAYJ0dDZTcsYGy3ivqydPxetE1oIkX8RJRmX68IO0+BcuejSD 7wyBMmQWxdMl5gVnhAfo6ovWYHbB/UlbGLaS1XNNE4VeH+FBja+86wijz555LjV9isWd GMNwj8U6+36z47sdT1hrsDXlfpbkCMZF7IQMBxMP4E+k++xKAFVNbRvRDgpMrN7IKKIs G13yVlJyrgIsN3qeG5s3KPSSXJc9PRz5QUiMiAouYQdFUlcJkgcdKq/0cyGHbHBxI0lH w6jzUufZedPmJ8OE/tMmA9pMk3ppisPqFS/P20LUoAVq8VL9zNJxr0NIiMmBR7O8e68W R96w==
X-Gm-Message-State: AN3rC/7nlPsRmn+yTVPREYs1VLkh4AR98d8M5TUkEO1US+tEZOIZ4zG6 vDwFiQOtC/LENA==
X-Received: by 10.80.149.81 with SMTP id v17mr35712932eda.76.1494053630046; Fri, 05 May 2017 23:53:50 -0700 (PDT)
Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id t45sm2981296edd.47.2017.05.05.23.53.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 May 2017 23:53:49 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <2B62B8B0-2131-4BD4-9F44-CF9CB97F1C79@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_5639FB7F-6D0F-4D05-A088-6412149C0A3D"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Sat, 6 May 2017 09:53:47 +0300
In-Reply-To: <CAHbuEH5zXt-sNeHrqh7MFev9bjRpNWefuZ18um-SFD7EAxTFUw@mail.gmail.com>
Cc: Hubert Kario <hkario@redhat.com>, "<tls@ietf.org>" <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> <73E0FBFC-34E4-4897-BE04-CD51728FE9BF@gmail.com> <CAHbuEH5zXt-sNeHrqh7MFev9bjRpNWefuZ18um-SFD7EAxTFUw@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/G24ifPjSzxvnnrulkJRcKpZjFlY>
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: Sat, 06 May 2017 06:53:54 -0000

Hi.

Draft-17 submitted.

Yoav

> On 4 May 2017, at 23:09, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>; wrote:
> 
> Yoav,
> 
> On Thu, May 4, 2017 at 1:59 PM, Yoav Nir <ynir.ietf@gmail.com <mailto:ynir.ietf@gmail.com>> wrote:
>> 
>> 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
>> 
>> 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 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.  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.
>> 
>> 
>> 
>> 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.
> 
> Thanks, let me know when the update is ready.
> 
>> 
>> Yoav
>> 
>> 
> 
> 
> 
> --
> 
> Best regards,
> Kathleen