Subject: [TLS] Kathleen Moriarty's Yes on draft-ietf-tls-rfc4492bis-15: (with COMMENT)

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 14 Mar 2017 13:40:24 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-tls-rfc4492bis-15: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for your work on this draft.  I just have one question:

In section 5.10, I see the following text:
   The default hash function is SHA-1 [FIPS.180-2], and sha_size (see
   Section 5.4 and Section 5.8) is 20.  However, an alternative hash
   function, such as one of the new SHA hash functions specified in
FIPS
   180-2 [FIPS.180-2], SHOULD be used instead.

Why are you setting the default to SHA-1 and then recommending that
something else should be used?  Why not just start with a different SHA
hash function as the default or at least for TLS 1.2?  I do see the prior
text about TLS 1.0 and 1.1 using MD5 and SHA-1, but most have recommended
to go right to TLS 1.2 with the SSLv3 deprecation.  As such, I'm not
clear on why the SHA-1 default.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 14 Mar 2017 23:26:23 +0200

Hi, Kathleen.  See inline.

> On 14 Mar 2017, at 22:40, Kathleen Moriarty <[email-masked]> wrote:
> 

If we add the three lines before the ones you quoted, they say this:
   All ECDSA computations MUST be performed according to ANSI X9.62 or
   its successors.  Data to be signed/verified is hashed, and the result
   run directly through the ECDSA algorithm with no additional hashing.

The default of using SHA-1 is from X9.62: https://www.security-audit.com/files/x9-62-09-20-98.pdf <https://www.security-audit.com/files/x9-62-09-20-98.pdf>
That is the document that was referenced by RFC 4492 and it’s from 1998. It doesn’t mention any hash function other than SHA-1.

RFC 4492 said that other hash functions may be used. We’ve upgraded it to a SHOULD.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 15 Mar 2017 08:29:02 +1100

On 15 March 2017 at 08:26, Yoav Nir <[email-masked]> wrote:
> That is the document that was referenced by RFC 4492 and it’s from 1998. It
> doesn’t mention any hash function other than SHA-1.
>

In light of recent developments, is there any reason we couldn't
further upgrade this advice?

---

From: Yoav Nir <[email-masked]>
Date: Wed, 15 Mar 2017 00:05:26 +0200

> On 14 Mar 2017, at 23:29, Martin Thomson <[email-masked]> wrote:
> 

It might be better to rephrase the whole thing and eliminate the thing about a default. X9.62 has been revised in 2005. This newer version does mention the SHA-2 family in addition to SHA-1, so I don’t know it that is in any sense of the word still “the default”. I’d look it up, but as an ANSI standard, it’s behind a paywall.

We might just say:

OLD
   All ECDSA computations MUST be performed according to ANSI X9.62 or
   its successors.  Data to be signed/verified is hashed, and the result
   run directly through the ECDSA algorithm with no additional hashing.
   The default hash function is SHA-1 [FIPS.180-2 <https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-15#ref-FIPS.180-2>], and sha_size (see
   Section 5.4 <https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-15#section-5.4> and Section 5.8 <https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-15#section-5.8>) is 20.  However, an alternative hash
   function, such as one of the new SHA hash functions specified in FIPS
   180-2 [FIPS.180-2 <https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-15#ref-FIPS.180-2>], SHOULD be used instead.

NEW
   All ECDSA computations MUST be performed according to ANSI X9.62 or
   its successors.  Data to be signed/verified is hashed, and the result
   run directly through the ECDSA algorithm with no additional hashing.
   A secure hash function such as the SHA-256, SHA-384, and SHA-512
   [FIPS.180-4] MUST be used.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 15 Mar 2017 09:57:54 +1100

>    [FIPS.180-4] MUST be used.

SGTM

---

From: [email-masked]
Date: Tue, 14 Mar 2017 20:08:21 -0400

Please excuse typos, sent from handheld device 

> On Mar 14, 2017, at 6:57 PM, Martin Thomson <[email-masked]> wrote:
> 

The new text is much better, thank you!

---

From: Sean Turner <[email-masked]>
Date: Tue, 14 Mar 2017 21:07:37 -0400

> On Mar 14, 2017, at 18:57, Martin Thomson <[email-masked]> wrote:
> 

+1

spt

---

From: Yoav Nir <[email-masked]>
Date: Wed, 15 Mar 2017 08:41:16 +0200

> On 15 Mar 2017, at 3:07, Sean Turner <[email-masked]> wrote:
> 
> 

And now it is in PR form:

https://github.com/tlswg/rfc4492bis/pull/35 <https://github.com/tlswg/rfc4492bis/pull/35>