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 21:40 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 667791243F6; Mon, 7 Aug 2017 14:40:31 -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, MIME_QP_LONG_LINE=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 gMXIf0EelVkU; Mon, 7 Aug 2017 14:40:29 -0700 (PDT)
Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 DFB881200F3; Mon, 7 Aug 2017 14:40:28 -0700 (PDT)
Received: by mail-qt0-x22a.google.com with SMTP id s6so10393725qtc.1; Mon, 07 Aug 2017 14:40:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WBeeR8bq6lrba6sauZRv9AKKiSCdwIM2FzKuw/ApYVY=; b=VE2jsMhtyzmtxYkFZ7NNNRwOuiR9LYot74NRC+LZ+X7lGUYDqB0ffEgpfJF9Xq5DGw AkImuKbAoVt3d5Q5d5To+IOAyKsIYTFnZILP8JliA9En8VDfDfQLo+rq+ITQQlbnsMwg 7sRNPweNL9F8M4SIrKBTKUAT/3l8HSFQ8Fw5G+SFUJMa23M1Ti1P0vN1sgRdaklHpqMl BL0J7M30soYIa1h0pS3PCN1maBjqe7lffMTBb5Joczm6oiyzKfNiSI9tGAHQn2vuDyh6 iSlo8jFB/FfAMcnxWJtP4wUhkRNnQWxjUqj7uHAtJT6EPJw4pgGFKlGCOkHUoBRH7l63 +GRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WBeeR8bq6lrba6sauZRv9AKKiSCdwIM2FzKuw/ApYVY=; b=GEOmlzTqKmbnYf1Ezh+1D5IzywSWKLcKSK/KeJulNrHNow7pYnHMKWV07vfY8O0aj8 97cVxQSBGvggy2HRdX5Fyc59MdLNZkBQg5MW/z6eZbD4JDS5cjQf8ZZ2tFMIZqrjOAWq I1YWpqyFM5BVIQ3xQxSKk1o+xkV92b/B9Vuxl1aqfdYIo2F8C7HMNDUalMHPgrljX5Fu tZ+34dLkEMvbIcKWeT5bgE3Iavcscwx9ONme1QMXDum5PP2Sfw39a1CHXfgLec9XxvnX pYklLoCk6Sk/8L3NYwl63tkjZzgxlE95kjLfjLrzjwAjyJT3W9x0MsW575YBf1RPoJTz LgAg==
X-Gm-Message-State: AHYfb5gNgbeAZmTjcZ47EUyHkRGRyi9GHgUDKjYgDFI8N9RLVbgUZ+1h ApXjuneTU6oDcoFpeuU=
X-Received: by 10.237.43.197 with SMTP id e63mr2910151qtd.86.1502142027868; Mon, 07 Aug 2017 14:40:27 -0700 (PDT)
Received: from [192.168.1.13] (209-6-124-204.s3530.c3-0.arl-ubr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id b68sm5682723qkc.88.2017.08.07.14.40.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Aug 2017 14:40:27 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
X-Mailer: iPhone Mail (14F89)
In-Reply-To: <5A5203CD-3F8F-4C08-9B3E-B25F97F56B23@nostrum.com>
Date: Mon, 7 Aug 2017 17:40:26 -0400
Cc: avtcore-chairs@ietf.org, draft-ietf-avtcore-aria-srtp@ietf.org, The IESG <iesg@ietf.org>, avt@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <5C6D5E91-944E-4881-BF25-91988E720857@gmail.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>
To: Ben Campbell <ben@nostrum.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/IqX4jZQr7t-PiTow-7wXfP3ucFs>
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 21:40:31 -0000

Thanks, Ben.

Sent from my iPhone

> On Aug 7, 2017, at 5:01 PM, Ben Campbell <ben@nostrum.com> wrote:
> 
> 
>> On Aug 7, 2017, at 3:44 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
>> 
>> 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.
> 
> 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 
> 
> Thanks!
> 
> Ben.
> 
>> 
>> Thank you,
>> Kathleen
>> 
>>> 
>>> Thanks!
>>> 
>>> Ben.
>> 
>> 
>> 
>> -- 
>> 
>> Best regards,
>> Kathleen
>