Subject: [MMUSIC] Stephen Farrell's Discuss on draft-ietf-mmusic-4572-update-12: (with DISCUSS)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 31 Jan 2017 08:08:45 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-mmusic-4572-update-12: Discuss

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-mmusic-4572-update/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I've two (or 4 depending how you count:-) things
I'd like to check here. Should be pretty easy to
handle.

(1) section 5: I'm wondering if we have the right
set of hash functions here. Deprecating md2 and md5
is great, but I have a bunch of questions about the
others:

(1.1) why not also say that sha-1 MUST NOT be used
for new things (or similar)?

(1.2) do you really need sha-224 and 384? I think
nobody uses those at all.

(1.3) I'm a bit surprised you didn't add sha3 (and
maybe remove sha-512 if that's not needed) Even if
you don't encourage use of sha3, it might be good
to include it in the abnf now in case it gets
popular.

(2) Wouldn't it be a good plan to say that TLS
as-used MUST conform to BCP195? If not, why not?

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 31 Jan 2017 17:23:12 +0000

> On Jan 31, 2017, at 11:08 AM, Stephen Farrell <[email-masked]> wrote:
> 

We say (section 5.1) that SHA-256 MUST be used for one of the fingerprints; implementations MAY send additional fingerprints as well.

There’s concern that there may be existing implementations needing SHA-1 (since 4572 made that the MTI algorithm).  The need for interop makes defining “new things” rather complicated.

Is that sufficient?

> to include it in the abnf now in case it gets

The policy is that the set of hash functions supported corresponds to the hash functions defined for X.509 certificates. Unless I’m missing something, there’s no definition of SHA-3 for X.509 yet, is there?  (If I’ve overlooked something, please let me know.) 

The list is an IANA registry, so once SHA-3 is defined for X.509, it can also be added to the registry without needing an update to this document.

For the same reason, this is why we included SHA-224 and SHA-384.  If no one’s using them, I’d think an update to RFC 4055 would be in order?

> as-used MUST conform to BCP195? If not, why not?

My inclination would be to say yes, but I’ll let people with more of the existing implementations comment further in case there’s some issue.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 1 Feb 2017 09:59:03 +1100

> My inclination would be to say yes, but I’ll let people with more of the existing implementations comment further in case there’s some issue.

If we said MUST, I suspect that we'd end up making a whole lot of
implementations non-compliant.  There's a lot of DTLS 1.0 out there.
That said, the same applies to SHA-1.

I guess it depends on your stance regarding what is as opposed to what
should be.

FWIW, we didn't ask this sort of question because the intent was to
clarify hash usage only, avoiding touching the rest of the document.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 1 Feb 2017 08:18:41 +0100

> https://datatracker.ietf.org/doc/draft-ietf-mmusic-4572-update/

It's certainly not correct that nobody uses SHA-384.

In fact, for TLS 1.3, you can't sign anything with P-384 without using
SHA-384.

-Ekr

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>