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

From: Hubert Kario <[email-masked]>
Date: Thu, 04 May 2017 14:41:22 +0200

On Tuesday, 11 April 2017 15:09:04 CEST Sean Turner wrote:
> All,
> 
> draft-ietf-tls-rfc4492bis has been revised since it left the WG and we agree
> with Yoav’s statement at the mic in Chicago that the WG should review the
> changes before we ask Kathleen (our newly appointed AD) to continue
> progressing the draft.  Please review the differences from the -12 version
> that went through WGLC and the latest version [0] and let us know by
> 20170426 whether there is anything that would stop progression of the
> draft.

I know I am late with the review, but I'd like to ask two questions:

 1. In table 2, the "key authorised for use in digital signatures" was 
    removed.
    Does that mean that key usage extension in X.509 certificates should be 
    ignored?
 2. Given that RFC7919 is already accepted, standards track document, 
    shouldn't "NamedCurve" references be renamed to "NamedGroup" (e.g. in 
    Section 5.5.1.)

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 4 May 2017 09:09:09 -0400

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.

I'll wait in responses for these 2 items.

Thank you,
Kathleen 

Sent from my iPhone

> On May 4, 2017, at 8:41 AM, Hubert Kario <[email-masked]> wrote:
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Sean Turner <[email-masked]>
Date: Thu, 4 May 2017 10:53:18 -0400

> On May 4, 2017, at 08:41, Hubert Kario <[email-masked]> wrote:
> 

No it does not. There were changes to the table, but s2.2 is still there and that’s where it says “… MUST contain an RSA public key authorized for signing ..."

>    shouldn't "NamedCurve" references be renamed to "NamedGroup" (e.g. in 

It’s either a replace or note the name change (i.e., in my mind this is a style thing).  The 1st paragraph of s5.1.1 notes them;

   RFC 4492 defined 25 different curves in the NamedCurve registry
  (now renamed the "Supported Groups" registry, although the enumeration
  below is still named NamedCurve) for use in TLS.

spt

---

From: Yoav Nir <[email-masked]>
Date: Thu, 4 May 2017 20:59:29 +0300

> On 4 May 2017, at 16:09, Kathleen Moriarty <[email-masked]> wrote:
> 

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 4 May 2017 16:09:30 -0400

Yoav,

On Thu, May 4, 2017 at 1:59 PM, Yoav Nir <[email-masked]> wrote:
>
> On 4 May 2017, at 16:09, Kathleen Moriarty
> <[email-masked]> 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:
>
>    point format (0).  RFC 4492 specified that if this extension is
> 2.4.  Algorithms in Certificate Chains
>
>    RFC 5246.

Thanks, let me know when the update is ready.

-- 

Best regards,
Kathleen

---

From: Hubert Kario <[email-masked]>
Date: Fri, 05 May 2017 13:31:45 +0200

> >    o  TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256

looks like an "E" is missing here

---

From: Yoav Nir <[email-masked]>
Date: Sat, 6 May 2017 09:51:59 +0300

Thanks!  That would have been an embarrassing erratum.

> On 5 May 2017, at 14:31, Hubert Kario <[email-masked]> wrote:
>

---

From: Yoav Nir <[email-masked]>
Date: Sat, 6 May 2017 09:53:47 +0300

Hi.

Draft-17 submitted.

Yoav

> On 4 May 2017, at 23:09, Kathleen Moriarty <[email-masked]> wrote:
> 
> Yoav,
> 
> On Thu, May 4, 2017 at 1:59 PM, Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
>>