Subject: [AVTCORE] Ben Campbell's Yes on draft-ietf-avtcore-aria-srtp-10: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Fri, 07 Jul 2017 13:32:39 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-avtcore-aria-srtp-10: 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-avtcore-aria-srtp/

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

I think it would be wise to add a paragraph to the security considerations to
call out the dependency on SHA1. A mention of what would need to happen to
migrate to newer hash functions could also be helpful.

---

From: Woo-Hwan Kim <[email-masked]>
Date: Mon, 10 Jul 2017 18:30:22 +0900

Let me reply to the comment of Ben Campbell.
We would like to add the below to security considerations of the previous draft(-10).

--------------------------------------------------------------------
As a note, at the time of publication of this document, SRTP
recommends HMAC-SHA1 as the default and mandatory-to-implement MAC
algorithm. So all of SRTP crypto suites except GCM based ones use
HMAC-SHA1 as their MAC algorithm to provide message authentication/
integrity. Due to security concerns with SHA-1 [RFC6194], the IETF
is gradually moving away from SHA-1 and towards stronger hash
algorithms such as SHA-2 or SHA-3 families. For SRTP, however, SHA-1
is only used in the calculation of an HMAC, and no security issue is
known in this case. To use a secure hash algorithm such as SHA-256
in SRTP, the values of directly related SRTP parameters
auth_key_length and auth_tag_length should be determined considering
the overall security and efficiency when the crypto suite is applied.

[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
<http://www.rfc-editor.org/info/rfc6194>.
--------------------------------------------------------------------

Sincerely, Woo-Hwan Kim

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Saturday, July 08, 2017 5:33 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Ben Campbell's Yes on draft-ietf-avtcore-aria-srtp-10: (with COMMENT)

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.)

I think it would be wise to add a paragraph to the security considerations to call out the dependency on SHA1. A mention of what would need to happen to migrate to newer hash functions could also be helpful.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Jul 2017 05:40:39 -0700

> We would like to add the below to security considerations of the previous

I don't think this last sentence makes sense. We are moving towards AEAD
algorithms, so I doubt we would ever want to publish <Cipher>-HMAC-SHA256.
I would simply remove the sentence.

-Ekr

> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> I think it would be wise to add a paragraph to the security considerations
> to call out the dependency on SHA1. A mention of what would need to happen
> to migrate to newer hash functions could also be helpful.
>
>
>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Jul 2017 09:45:23 -0500

> On Jul 10, 2017, at 7:40 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> I don't think this last sentence makes sense. We are moving towards AEAD algorithms, so I doubt we would ever want to publish <Cipher>-HMAC-SHA256. I would simply remove the sentence.

I agree. 

When I suggested text to say what would need to be done to move to newer hashes, I was thinking of something more general from a procedural perspective. Maybe something more to the effect of “Changing away from SHA1 for this purpose is out of scope for this document, and would require updates to SRTP [REF]”

On the other hand, I would also be okay with simply removing that sentence.