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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Thu, 04 May 2017 20:10 UTC

Return-Path: <kathleen.moriarty.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 C32E7129A8E for <tls@ietfa.amsl.com>; Thu, 4 May 2017 13:10:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 xwQNjxAMbeTZ for <tls@ietfa.amsl.com>; Thu, 4 May 2017 13:10:13 -0700 (PDT)
Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (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 ECCB8129687 for <tls@ietf.org>; Thu, 4 May 2017 13:10:11 -0700 (PDT)
Received: by mail-pg0-x22a.google.com with SMTP id q4so6211007pga.3 for <tls@ietf.org>; Thu, 04 May 2017 13:10:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7pr8r9bHH2z/KBLnyE7T4a0+pvEden0hTeAEY9q1BL4=; b=ipg6xh8JZdmeqGT8dF5lVGtfMrqhr/5iLedQUXwV103CM4dISbjOlJSCE4kkO3ED3K h8Lx156342KJYQUh15kva1HT3G5JxbKhwQrRl4IZc511ndvKLuuSjilkeSQw5RqMVwlD ZYFLFN2sZVg3r3RbrwWIPM9CUl1ZD2zYGWjgiPUzgoVhHa95ddQ6vnwAsAHYoMBVfNy1 E5mRxRJqSu0RNgwBTdUHraFlIUQqvLNydyqEgA9Bav6AdNPDUN5QO5QcCRXuD/SCpY42 3TZhAgP3xvOmPBr3MIb8Px4flyS0lDcs/UtlVn92mkKMk06vE+rQC/OgsoDBp/fIoeLg V/dA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7pr8r9bHH2z/KBLnyE7T4a0+pvEden0hTeAEY9q1BL4=; b=GsuCyKinUEFo/m36ElfH3O3A44nxXS0BjIt4Bw6DfCVfKslq6peaoSLsfcV2ONJh0Y 4sKc1QGK7PSBu98gfXolt9cU9lT2bdvtqaxcKy0EbcgauuCvH2VbgduFdwBc9UaKNyQQ 7iwRdeLg6Tn7gWwdFq/w6AXgVxLlCBF+6PWM+5A6tsR1K+Eem/PUH79ygklH9EKyDltQ jZbcIEXc9Z0Vh0QKHuQ1OUT73CURUXPwVreFzmi8+PB1GI5Eph+VPo1dOQUmIScyTIy6 BigF0EABV27a1gmpn/+jZebexNRXAiugSv2m5lF8VJrcMjnNEgejtCwY/uUwUy25+2zb Yuew==
X-Gm-Message-State: AN3rC/4k9vvhetNKVAvkmd3BmYoAL2o65/2O6nohbhe8R6vpfhcWCkuJ dDwWoRoEt04z3OMl/W5CHV5Mvsckqg==
X-Received: by 10.84.241.133 with SMTP id b5mr4890948pll.107.1493928611400; Thu, 04 May 2017 13:10:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.185.143 with HTTP; Thu, 4 May 2017 13:09:30 -0700 (PDT)
In-Reply-To: <73E0FBFC-34E4-4897-BE04-CD51728FE9BF@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>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Thu, 4 May 2017 16:09:30 -0400
Message-ID: <CAHbuEH5zXt-sNeHrqh7MFev9bjRpNWefuZ18um-SFD7EAxTFUw@mail.gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Cc: Hubert Kario <hkario@redhat.com>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/9KeF4GD46Bo2dE6evS-qmBu52Lw>
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 20:10:15 -0000

Yoav,

On Thu, May 4, 2017 at 1:59 PM, Yoav Nir <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