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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Tue, 08 August 2017 14:26 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F392A13250D; Tue, 8 Aug 2017 07:26:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQkEq5tfAYfw; Tue, 8 Aug 2017 07:26:22 -0700 (PDT)
Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCA1D132543; Tue, 8 Aug 2017 07:26:22 -0700 (PDT)
Received: by mail-pg0-x232.google.com with SMTP id u185so15527776pgb.1; Tue, 08 Aug 2017 07:26:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=genKounIZtMZdwiUfYcvppvbqwu4UWyS3hD4Eh7yeb4=; b=FhWz1agb+4LrnnUm9i5nFSMD9IlvDpTixFwh40mmKofZn0n7KPzngavR1dKIlJRpri wde8Obhsba2XslnTqnL9kxYXx/8HRJFPualGLD8hQpu7A/uFHU4VxjH99rEN0wqJk64n PdXTitbY1AefZM1YK8Wb0vQGWZ9AV922dSAwkzUb4rXQNFYj7N348gYRJi3rDf4dW63K QqhDh7Kqtqxa2RwGcJBHY03U0l57j/2Ym9ODr+YYI8EPNR/0TYgW6f6yFzIQVY2rDSv6 qPS457T5WeVgDMiYYF6NDnZUarsfzvUyq6fYNxSlyrbGG8oNqwMma9We2wdTrMxvosu6 vBhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=genKounIZtMZdwiUfYcvppvbqwu4UWyS3hD4Eh7yeb4=; b=i0Usn0KnYlqKVIDW/9PxKy/fFqljH/ID976DMhR1i77ee+nv59qG/DrHLtBboZVvL5 IznpcCfjk7xo5uUk3h2JpcCU4XcYQTJeC56pxKA3WF29kQytXCxMOrhQy7czU8uq3V3j YgkYtLQ1FZ8wVz7ylFulDnj/2dDNrfRbJQyNBN5j034CEYVmd6ICWO2A/yN0TFioEpSJ d62gDlv9qHc/KhwGTaeWgAyy43YV1AB0gvtbX2gEnk3+WK0FWviT6XOjHnoCK459nVUY 9tPbSA5CbXO7r0zmsPdTGgVSbNdiwaNU/vKDpZOoM/bDdEy/28RIcwX7Bq8QTPlnYLNl p/0A==
X-Gm-Message-State: AHYfb5jP7xZKNMwvgVRAs6jMhxD3dERsxSa3DxOyhQ+/JNhOy82zfXrc 3tAWiWtE4+Jb+Ut3xZ0Sk1NAbGIBaw==
X-Received: by 10.84.129.103 with SMTP id 94mr4829145plb.63.1502202381156; Tue, 08 Aug 2017 07:26:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.144.1 with HTTP; Tue, 8 Aug 2017 07:25:40 -0700 (PDT)
In-Reply-To: <959EFAA1-C1EE-4A0F-AB3A-024CEA5E3180@nostrum.com>
References: <150172505031.5791.14553211399724965332.idtracker@ietfa.amsl.com> <084BEE4A-1241-42C6-BD39-36F11792ABB4@nostrum.com> <CAHbuEH4+R8KguTtLdoGnGdom1YB6Cp0XD5nLTm-YUMHaLsXxuw@mail.gmail.com> <D666082B-4DBF-406E-AC6C-03493A376A53@nostrum.com> <CAHbuEH6JJNq9QmAi9Dbg15-SctUS+c6FArW94KqfRzVP_g4gGw@mail.gmail.com> <D2164284-D756-4193-AF5E-258FF8EFC09B@nostrum.com> <3B1A7FF4-22D0-4988-AB8C-0DC64E020C0B@nostrum.com> <CAHbuEH5yAoftQ67rT-cahwTPchCncJX89GDVKnv2KTUeewjpQg@mail.gmail.com> <5A5203CD-3F8F-4C08-9B3E-B25F97F56B23@nostrum.com> <5C6D5E91-944E-4881-BF25-91988E720857@gmail.com> <D34390F5-6F68-45DC-89FA-D2B215B990E4@nostrum.com> <000401d31001$1d432df0$57c989d0$@nsr.re.kr> <959EFAA1-C1EE-4A0F-AB3A-024CEA5E3180@nostrum.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Tue, 8 Aug 2017 10:25:40 -0400
Message-ID: <CAHbuEH4uDPiHzVg-xGDYohq9mh0_GJk64X1rZbg4OqbRjksDXQ@mail.gmail.com>
To: Ben Campbell <ben@nostrum.com>
Cc: Woo-Hwan Kim <whkim5@nsr.re.kr>, avtcore-chairs@ietf.org, draft-ietf-avtcore-aria-srtp@ietf.org, The IESG <iesg@ietf.org>, IETF AVTCore WG <avt@ietf.org>, Roni Even <roni.even@huawei.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/vPjTf6vjU7A9-dMFLFLlgO-H5fQ>
Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on draft-ietf-avtcore-aria-srtp-10: (with COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Aug 2017 14:26:25 -0000

Thank you, all!

On Tue, Aug 8, 2017 at 12:52 AM, Ben Campbell <ben@nostrum.com> wrote:
> (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 <whkim5@nsr.re.kr> 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:ben@nostrum.com]
>> Sent: Tuesday, August 08, 2017 6:47 AM
>> To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
>> Cc: avtcore-chairs@ietf.org; draft-ietf-avtcore-aria-srtp@ietf.org; The IESG <iesg@ietf.org>rg>; avt@ietf.org
>> Subject: Re: [AVTCORE] Kathleen Moriarty's No Objection on draft-ietf-avtcore-aria-srtp-10: (with COMMENT)
>>
>> Authors, please see below:
>>
>>> On Aug 7, 2017, at 4:40 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> 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?
>>>>>
>>>>> 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.
>>>>
>>>> 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.”
>>> That's much better and provides guidance.  Thank you!
>>> Kathleen
>>>
>>
>> Authors: Would that proposed text work for you?
>>
>> Thanks!
>>
>> Ben.
>>
>>
>



-- 

Best regards,
Kathleen