Re: [secdir] Secdir last call review of draft-ietf-perc-private-media-framework

Vincent Roca <vincent.roca@inria.fr> Mon, 13 May 2019 09:47 UTC

Return-Path: <vincent.roca@inria.fr>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320F8120112; Mon, 13 May 2019 02:47:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 b_pVf0nupKe1; Mon, 13 May 2019 02:47:19 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56E512003E; Mon, 13 May 2019 02:47:18 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.60,465,1549926000"; d="scan'208,217";a="382870872"
Received: from moucherotte.inrialpes.fr ([194.199.28.14]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 May 2019 11:47:17 +0200
From: Vincent Roca <vincent.roca@inria.fr>
Message-Id: <3FB301E0-1E6E-47F1-AB7B-C1194680EEF8@inria.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9D06126F-DB77-49C6-B6C4-E48AA0614EDD"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Mon, 13 May 2019 11:47:16 +0200
In-Reply-To: <em9d093e61-1f9f-4cc7-be19-c97343337129@sydney>
Cc: Vincent Roca <vincent.roca@inria.fr>, The IESG <iesg@ietf.org>, David Benham <dabenham@gmail.com>, draft-ietf-perc-private-media-framework.all@ietf.org, aamelnikov@fastmail.fm, secdir@ietf.org
To: "Paul E. Jones" <paulej@packetizer.com>
References: <155014077570.26619.9407568904769535504@ietfa.amsl.com> <emb104d043-b701-4e92-9e08-1e1815c2981f@sydney> <6882A552-80DF-4322-9683-13D8E655F2DB@inria.fr> <em0afb83b5-7014-4039-88b4-5ae3d87a6b0b@sydney> <DB650EB5-5E7E-46B3-A8B7-524B36D2AC26@inria.fr> <CAM5V9Z8Dz=qSB3n+8RGGx0d=1PgLds01asgOGDyhFL81g=TiuQ@mail.gmail.com> <D519986E-441D-4923-A556-6F3793B451BD@inria.fr> <emde7bdf10-574d-4853-bbf0-cd4bdbe6ec86@sydney> <1CE6DB48-325C-41C2-A526-3F5FD5FA8388@inria.fr> <em9d093e61-1f9f-4cc7-be19-c97343337129@sydney>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/2EBl3j1imEwhTC0fL7_8EzCEJyA>
Subject: Re: [secdir] Secdir last call review of draft-ietf-perc-private-media-framework
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 May 2019 09:47:24 -0000

Hello Paul, all,


> Le 12 mai 2019 à 06:34, Paul E. Jones <paulej@packetizer.com> a écrit :
> 
> Vincent,
> 
> Once again, thanks for the feedback.  Please allow me to reply inline and, if you're OK with the text, I can prepare a new revision.
> 
>> ** In section 8.1 it is said:
>> 
>>    "While confidentiality
>>    would not be compromised by failing to implement mutual
>>    authentication, employing it helps mitigate against denial of service
>>    attacks wherein a false entity sends a stream of packets that the
>>    would force a legitimate entity to spend time attempting to decrypt."
>> 
>> This is true only if authenticating a received packet is cheap, which is
>> not necessarily the case. And in section 5 « Authentication » you say that
>> "details of this are outside the scope of specification", so we are not
>> able to answer the above question: is authenticated really so cheap?
>> With certain authenticated encryption technics (e.g. MAC-then-Encrypt),
>> decrypting is required before checking data authenticity… So please
>> clarify.
> 
> Actually, after reading that original text, I think it is even misleading to suggest confidentiality is not compromised.  In terms of encryption, that would be true, but in terms of net effect, it would not: without verifying the certificate, an unwanted party could potentially engage in the conference.  I think this would be better text (replacing the entire paragraph):
> 
> Use of mutual DTLS authentication (as required by DTLS-SRTP) ensures that a
> false endpoint or false Media Distributor cannot interact with a legitimate
> Media Distributor or endpoint.  This helps mitigate against denial of service
> attacks wherein a false entity sends a stream of packets that would force
> a legitimate entity to spend time attempting to decrypt.
> 
> With respect to whether the DoS mitigation is true or not, I think it is.  If mutual authentication fails, then no media packets would flow at all, thus no wasted time decrypting packets; packets would likely get rejected without inspection.  If mutual authentication succeeds, then the cost isn't at issue here, anyway, since the point of the paragraph is to talk about a side benefit of mutual authentication.  While the specifics are outside the scope of the document, the assumption is that some mechanism is employed to enable checking the validity of certificates.

[VR] Yes for the first aspect.

Concerning DoS mitigation, wether DTLS authentication helps reducing decryption overhead at a receiver
really depends on how authentication is achieved. Looking at RFC 5764 (I imagine this is where DTLS-SRTP
is defined), I read in Section 5.1.2. « Reception », item 3., that decryption and authentication are performed
at the same step. This is in line, although no technical detail is provided, with my comment on authenticated
encryption (see also https://en.wikipedia.org/wiki/Authenticated_encryption). In some cases, decrypting is 
required before checking data authenticity, so authentication won’t be of any help if your goal is to avoid
« spend[ing] time attempting to decrypt », what you're saying. 
RFC 5764, Section 7.4. « Decryption Cost », discusses decryption cost but does not presents authentication
as a solution to mitigate it.

What you’re saying in your answer, above (whether or not mutual authentication fails) is something else.
In section 8.1 we are considering 3rd party attacks, from entities that will never be authenticated.


>> NB: there's also a typo in above sentence: "that the would".
> 
> Thanks, I fixed that.
> 
>> 
>> 
>> Finally, shouldn't this paragraph appear after the last one "A third
>> party could cause..." since they are both concerning the same DoS issue.
>> In that case you start with simple protections (rate limitation, heuristics)
>> then continue with (cheap) authentication.
> 
> Agreed, moving it makes more sense.
> 
> 
>> ** Section 8.2.3: the following sentence is unnecessarily obscur IMHO:
>>         "Within the window from last packet forwarded to the receiver and the
>>         latest received by the Media Distributor,..."
>> Why don't you simply say that the MD can choose, at some point of time, to
>> delay some packets by an arbitrary duration? Do we really need this notion
>> of "window »?
> 
> Definitely not essential.  I tried to make whole paragraph a little easier to read.  How about this:
> 
> While the Media Distributor can purposely stop forwarding media flows, it
> can also select an arbitrary starting point to resume forwarding those
> media flow, perhaps forwarding old packets rather than current packets.
> As a consequence, what the media source sent can be substantially delayed
> at the receiver with the receiver believing that newly arriving packets
> are delayed only by transport delay when the packets may actually be
> minutes or hours old.
> 
> The most significant change with this text, I think, (apart from removing "window") is changing "media source said" to "media source sent".  If that's less clear, I can try to put "said" back in, but I felt the current wording of "that it is what was said just now" was really hard to parse.

[VR] okay.

> 
> Thanks!
> Paul

Cheers,

  Vincent