Subject: [AVTCORE] Kathleen Moriarty's No Objection on draft-ietf-avtcore-aria-srtp-10: (with COMMENT)

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 02 Aug 2017 18:50:50 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-avtcore-aria-srtp-10: No Objection

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:
----------------------------------------------------------------------

Although this is not a discuss, I think updated text would be very helpful on
the following two issues.

I agree with the SecDir reviewer that there should be more text around the
short tag length in the security considerations section.  I don't see a
response to that post though.

For SHA-1, a reference to RFC6194 for the security considerations for
SHA-1message digest algorithms would be helpful. Thank you!

---

From: Ben Campbell <[email-masked]>
Date: Wed, 2 Aug 2017 21:36:31 -0500

> On Aug 2, 2017, at 8:50 PM, Kathleen Moriarty <[email-masked]> wrote:

Hi Kathleen,

I think you are referring to Ben Laurie’s SecDir review of 06, rather than his later review of 09. Is that correct? Version 9 removed the GCM_8 modes. Or were you referring to something else?

> SHA-1message digest algorithms would be helpful. Thank you!

Thanks, that’s helpful. I agree the security considerations needs to say something about the use of SHA1

Ben.

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 2 Aug 2017 22:50:02 -0400

Hi Ben,

Thanks for the quick response, inline.

> I think you are referring to Ben Laurie’s SecDir review of 06, rather than his later review of 09. Is that correct? Version 9 removed the GCM_8 modes. Or were you referring to something else?

I am referring to Ben's review of -06, where he had the following text:

Thirdly, I am not familiar enough with SRTP to understand why short
authentication tags are needed, but in general its a bad idea, so I
feel the Security Considerations should explain more fully than
"Ciphersuites with short tag length may be
   considered for specific application environments stated in 7.5 of
   [RFC3711], but the risk of weak authentication described in
   Section 9.5.1 of [RFC3711] should be taken into account."

I don't see an update to this text to address his question - providing
additional information as to what should be "taken into account".

> Thanks, that’s helpful. I agree the security considerations needs to say something about the use of SHA1

Great, thanks!

-- 

Best regards,
Kathleen

---

From: Ben Campbell <[email-masked]>
Date: Wed, 2 Aug 2017 22:15:45 -0500

> On Aug 2, 2017, at 9:50 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hi Ben,
> 
> additional information as to what should be "taken into account”.

I had assumed his concern was about short tags in GCM mode, namely the following: 

       AEAD_ARIA_128_GCM_8 
       AEAD_ARIA_256_GCM_8
       AEAD_ARIA_128_GCM_12 
       AEAD_ARIA_256_GCM_12 

These have all been removed as of version 09. Ben’s review of 09 made no further mention of short tags.

Are there suites still in version 09 that you think need further discussion in the security considerations?  I think the authors would happily add something if we can tell them what is needed, but I’m certainly not the expert here.

Ben.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 3 Aug 2017 09:26:51 -0400

Hi Ben,

> These have all been removed as of version 09. Ben’s review of 09 made no further mention of short tags.

Thanks, but the text warning about them remains in the security
considerations section.  Is it needed for some reason?

Kathleen

-- 

Best regards,
Kathleen

---

From: Ben Campbell <[email-masked]>
Date: Thu, 3 Aug 2017 08:55:42 -0500

> On Aug 3, 2017, at 8:26 AM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hi Ben,
> 

Ah, I get it—I thought you were asking for _more_ text :-). I think they put that in as a result of the 06 review, but didn’t take it out when they removed those modes. I will verify that the authors don’t think the warning applies to any of the remaining.

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 7 Aug 2017 14:52:00 -0500

> On Aug 3, 2017, at 8:55 AM, Ben Campbell <[email-masked]> wrote:
> 

In further discussion with the authors, I learned that they think the guidance still applies, due to the HMAC_SHA1_32 suites that are still in the document. (There are currently 3, but this will become 2 once they remove the SRTP_ARIA_192 suites due to other comments from Ekr.)

But on doing a little more research, I am not sure I understand the concern with the security consideration language (quoted here for convenience):

"Ciphersuites with short tag length may be
considered for specific application environments stated in 7.5 of
[RFC3711], but the risk of weak authentication described in
Section 9.5.1 of [RFC3711] should be taken into account"

I have suggested that the authors clarify which suites they consider to have “short” tags. But otherwise,  It references 3711 section 7.5, which talks about some specific scenarios where short authentication tags may be needed, and section 9.5 which talks about specific risks of null or weak authentication. Implementors need to consider those things and make a choice. It’s not clear to me what additional guidance would be helpful here—do you have suggestions?

Thanks!

Ben.

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 7 Aug 2017 16:44:00 -0400

Hi Ben,

> I have suggested that the authors clarify which suites they consider to have “short” tags. But otherwise,  It references 3711 section 7.5, which talks about some specific scenarios where short auth…

I just looked at 3711 and agree with what you said, section 9.5 mostly
talks about weak or null authentication, with only the following said
about short tags (*coupled with weak authentication):

   Under this condition, the size of the
   authentication tag MUST ensure that only a negligible fraction of the
   packets passed to the RTP application by the SRTP receiver can be
   forgeries.  This fraction is negligible when an adversary, if given
   control of the forged packets, is not able to make a significant
   impact on the output of the RTP application (see the example of
   Section 7.5).

The draft in question says the above should be taken into account, the
original question was how?  Looking back at it, I'm wondering if
instead of saying "taken into account", the use of short tags should
be discouraged to NOT RECOMMENDED.  Can the RTP application detect the
forgeries or the SRTP receiver?  Is this asking that if weak
authentication tags are used, some sort of risk mitigation is
performed to reduce the number of forgeries?  It doesn't say how
though, so I'm asking if it should be discouraged or if there is some
mechanism to do this when short tags are in use.

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: Ben Campbell <[email-masked]>
Date: Mon, 7 Aug 2017 16:01:38 -0500

> On Aug 7, 2017, at 3:44 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hi Ben,
> 

Well, I think the authentication tag _is_ the way SRTP prevents forgeries :-)

A “SHOULD NOT” or “NOT RECOMMENDED” might make sense, but let me probe a little more:

Section 7.5 of 3711 is specifically about short authentication tags. It lists a couple of situations where full length tags can be problematic.

Section 9.5 starts out talking about “null or weak” authentication. But most of the section seems to be more about “null” rather than “weak” authentication. This section is not specifically about short authentication tags, so it’s not clear to me if short tags used with HMAC_SHA1 suites would be considered “weak” for the purposes of that section. They at least provide _some_ forgery protection, just maybe not as much as one might like.

Would it make sense to say something to the effect of the following (with possible additional wordsmithing):

“This document includes ciphersuites with authentication tags of length less than 80 bits. These suites MAY be used for certain application contexts where longer authentication tags may be undesirable, for example, those mentioned in [RFC 3711] section 7.5. Otherwise, Short authentication tags SHOULD NOT be used, since may reduce authentication strength. See [RFC 3711] section 9.5 for a discussion of risks related to weak authentication in SRTP.”

Thanks!

Ben.

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 7 Aug 2017 17:40:26 -0400

Thanks, Ben.

Sent from my iPhone

> On Aug 7, 2017, at 5:01 PM, Ben Campbell <[email-masked]> wrote:
> 
> 

That's much better and provides guidance.  Thank you!
Kathleen

---

From: Ben Campbell <[email-masked]>
Date: Mon, 7 Aug 2017 16:47:27 -0500

Authors, please see below:

> On Aug 7, 2017, at 4:40 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
>>>> 

Authors: Would that proposed text work for you?

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 7 Aug 2017 23:52:34 -0500

(Adding the draft shepherd)

That all looks good. Please submit a new version at your convenience.

Thanks!

Ben.

> On Aug 7, 2017, at 11:45 PM, Woo-Hwan Kim <[email-masked]> wrote:
> 
> Your suggestion seems to be fine.
> We will add and edit some sentence.
> 
> (Add)
> At the time of publication of this document, SRTP recommends HMAC-SHA1 as the default and mandatory-to-implement MAC algorithm. All currently registered SRTP crypto suites except the GCM based ones use HMAC-SHA1 as their HMAC algorithm to provide message authentication. 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 for this usage at the time of this publication.
> 
> (Edit)
> OLD:
> Protection profiles with short tag length may be considered for specific application environments stated in Section 7.5 of [RFC3711], but the risk of weak authentication described in Section 9.5.1 of [RFC3711] should be taken into account.
> 
> NEW:
> This document includes crypto suites with authentication tags of length less than 80 bits. These suites MAY be used for certain application contexts where longer authentication tags may be undesirable, for example, those mentioned in [RFC 3711] section 7.5. Otherwise, Short authentication tags SHOULD NOT be used, since may reduce authentication strength. See [RFC 3711] section 9.5 for a discussion of risks related to weak authentication in SRTP.
> 
> Additionally, we will remove two ARIA-192 crypto suites. This reflects the comments of Eric Rescorla and Ben Campbell that it would be better to match the key sizes of CTR and GCM crypto suites unless the 192-bit key size is already in use or likely to be in use soon.
> 
> Thanks for all of discussions and suggestions.
> 
> Sincerely, Woo-Hwan Kim
> 
> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]] 
> Sent: Tuesday, August 08, 2017 6:47 AM
> To: Kathleen Moriarty <[email-masked]>
> Cc: [email-masked]; [email-masked]; The IESG <[email-masked]>; [email-masked]
> Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on draft-ietf-avtcore-aria-srtp-10: (with COMMENT)
> 
>>>>> In further discussion with the authors, I learned that they think 
>>>>> the guidance still applies, due to the HMAC_SHA1_32 suites that are 
>>>>> still in the document. (There are currently 3, but this will become 
>>>>> 2 once they remove the SRTP_ARIA_192 suites due to other comments 
>>>>> from Ekr.)
>>>>> 
>>>>> "Ciphersuites with short tag length may be considered for specific 
>>>>> application environments stated in 7.5 of [RFC3711], but the risk 
>>>>> of weak authentication described in Section 9.5.1 of [RFC3711] 
>>>>> should be taken into account"
>>>>> 
>>>> I just looked at 3711 and agree with what you said, section 9.5 
>>>> mostly talks about weak or null authentication, with only the 
>>>> following said about short tags (*coupled with weak authentication):
>>>> 
>>>> Under this condition, the size of the authentication tag MUST ensure 
>>>> that only a negligible fraction of the packets passed to the RTP 
>>>> application by the SRTP receiver can be forgeries.  This fraction is 
>>>> negligible when an adversary, if given control of the forged 
>>>> packets, is not able to make a significant impact on the output of 
>>>> the RTP application (see the example of Section 7.5).
>>>> 
>>>> The draft in question says the above should be taken into account, 
>>>> the original question was how?  Looking back at it, I'm wondering if 
>>>> be discouraged to NOT RECOMMENDED.  Can the RTP application detect 
>>>> the forgeries or the SRTP receiver?  Is this asking that if weak 
>>>> though, so I'm asking if it should be discouraged or if there is 
>>>> some mechanism to do this when short tags are in use.
>>>

---

From: Woo-Hwan Kim <[email-masked]>
Date: Tue, 8 Aug 2017 13:45:09 +0900

(Add)

(Edit)
OLD:

NEW:

Sincerely, Woo-Hwan Kim

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Tuesday, August 08, 2017 6:47 AM
To: Kathleen Moriarty <[email-masked]>
Cc: [email-masked]; [email-masked]; The IESG <[email-masked]>; [email-masked]
Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on draft-ietf-avtcore-aria-srtp-10: (with COMMENT)

Thanks!

Ben.

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 8 Aug 2017 10:25:40 -0400

Thank you, all!

-- 

Best regards,
Kathleen