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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Mon, 07 August 2017 20:44 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 47BBE132484; Mon, 7 Aug 2017 13:44:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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] 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 n4_CdKRVjgrB; Mon, 7 Aug 2017 13:44:41 -0700 (PDT)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 4995E132480; Mon, 7 Aug 2017 13:44:41 -0700 (PDT)
Received: by mail-pf0-x22e.google.com with SMTP id t86so5869987pfe.2; Mon, 07 Aug 2017 13:44:41 -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=iFiE5GYv7Yo4aDmyqhP2JHibi25mhbqMlU3jMUDNR5U=; b=JpxCgd5d7zyUne38Lz8a4IM6NHJWOlvMZaw+nzU0cE2WWFFjx2TZ2kTLjxgs33uZjd 1eVj2BtoR5rthMKZxdBt5k++zCl+rZzh97yvIxa7/Du6UO5id0+jJYBcxxH2fYN3dLLn uwG22YIWwVRNjyMzZlG9iezRIwmXs+dO+PVyIITAePWIedV74+e48Aj8zv5rtepDFSar sjqQZViuoemCs1sbAG7/w3wpgTPYKxfDhpYvp9EDwmn7u4p1s7zMyv+RAmA/JHdOYyPF 1/kPZeugOzDdcZjkTKtKAqDnQwmx1YRcz0AO8aXTPtBP94cPf1U/kMfZVqky9zUCavgY 7CUw==
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=iFiE5GYv7Yo4aDmyqhP2JHibi25mhbqMlU3jMUDNR5U=; b=q0ubE7/KPFNWy1B4SN6KnfQM9Na/K52oyVssAecAKGQN0XgxyHsRrktpAjGM7oSIwD oeTYqgGOsM3+miQaZAKl0BjEX3jF5xnk5wrqhNOMVC+H7Fjcu+Rs6dYP5eqXK8WjywjD VkB99PXAX717HZLQzSMQHRh2PqHe7Q2ahBOe/8jdQrAdsj7v9uZFXDPhQGGw7eKabkgG XB9CzWEmUdISO/J7EGfHKw1n3Um87QAlf+zXbxtQdAbeZ4DzLbz/udysR59OChpUkDMv mPgPFh3rsTVi4FdHvSiKr4HQ20cNHLDrXjsSOTrCzA1DhKED3hOlbkNWeyLGc7dbEEmx XV5g==
X-Gm-Message-State: AHYfb5gtoBUqn0jwSy053iMeLj1L1zlVJPTYFwudJFA956eCvo/gknIX AeUsb33YRdZ8oglsukYxrWC26BWPT4xe
X-Received: by 10.84.229.13 with SMTP id b13mr1999224plk.352.1502138680594; Mon, 07 Aug 2017 13:44:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.144.1 with HTTP; Mon, 7 Aug 2017 13:44:00 -0700 (PDT)
In-Reply-To: <3B1A7FF4-22D0-4988-AB8C-0DC64E020C0B@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>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Mon, 7 Aug 2017 16:44:00 -0400
Message-ID: <CAHbuEH5yAoftQ67rT-cahwTPchCncJX89GDVKnv2KTUeewjpQg@mail.gmail.com>
To: Ben Campbell <ben@nostrum.com>
Cc: avtcore-chairs@ietf.org, draft-ietf-avtcore-aria-srtp@ietf.org, The IESG <iesg@ietf.org>, avt@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/Bsm1y-ZoweT-IT-6vypP23YA294>
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: Mon, 07 Aug 2017 20:44:43 -0000

Hi Ben,

On Mon, Aug 7, 2017 at 3:52 PM, Ben Campbell <ben@nostrum.com> wrote:
>
>> On Aug 3, 2017, at 8:55 AM, Ben Campbell <ben@nostrum.com> wrote:
>>
>>>>> 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”.
>>>>
>>>> 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.
>>>
>>> Thanks, but the text warning about them remains in the security
>>> considerations section.  Is it needed for some reason?
>>>
>>
>> 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.
>>
>
> 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.

Thank you,
Kathleen

>
> Thanks!
>
> Ben.



-- 

Best regards,
Kathleen