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

"Paul E. Jones" <paulej@packetizer.com> Tue, 14 May 2019 00:22 UTC

Return-Path: <paulej@packetizer.com>
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 092F8120088; Mon, 13 May 2019 17:22:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.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 l_-gfGVPWaop; Mon, 13 May 2019 17:22:11 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (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 C69DA120026; Mon, 13 May 2019 17:22:10 -0700 (PDT)
Received: from authuser (localhost [127.0.0.1])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1557793322; bh=4igxHnetA5dO9x6+P+CWjnVzAF8HmszpbAD0TI4snjA=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=T70reiBd9yQMtH7T4ufxugeu77r4kuKgwEF5a0XD3Cvj6ICAd+5BFV7Lh9PPLZ2oQ 7NjL90iMvpmJ0smyUdTodszxE15aOvgx2RtMS5n7Dt6/Iz86rAchckX+XLFfammGD4 DXXVAMqFCQvnY9MZZnoHddRjU4I4BlyuqXKm98lo=
From: "Paul E. Jones" <paulej@packetizer.com>
To: Vincent Roca <vincent.roca@inria.fr>
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
Date: Tue, 14 May 2019 00:21:56 +0000
Message-Id: <em1fe89456-399a-4e23-83a4-9b6cbfa1b952@sydney>
In-Reply-To: <3FB301E0-1E6E-47F1-AB7B-C1194680EEF8@inria.fr>
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> <3FB301E0-1E6E-47F1-AB7B-C1194680EEF8@inria.fr>
Reply-To: "Paul E. Jones" <paulej@packetizer.com>
User-Agent: eM_Client/7.2.34711.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MBEC0B5FCF-A420-4E7C-BC8D-FB2739583C73"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Q0mccshZq4Cd16IyneQUig5hrHU>
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: Tue, 14 May 2019 00:22:15 -0000

Vincent,

Please see inline below:

------ Original Message ------
From: "Vincent Roca" <vincent.roca@inria.fr>
To: "Paul E. Jones" <paulej@packetizer.com>
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
Sent: 5/13/2019 5:47:16 AM
Subject: Re: Secdir last call review of 
draft-ietf-perc-private-media-framework

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

This paragraph does deal with third parties, so I think it's 
appropriately placed. But clearly the wording still isn't quite right, 
as it's not conveying the intended meaning.  By using mutual 
authentication, a receiving endpoint would know if the sender is or is 
not a valid sender.  There is no need to authenticate the media packets 
received, because the DTLS handshake failed.  Receivers could just 
discard those packets without inspection.  So, the receiver never even 
gets to the point where it's dealing with the authenticated decryption 
of packets.

I revised that paragraph again.  Here is the new text


Use of mutual DTLS authentication (as required by DTLS-SRTP) also helps 
to
prevent a denial-of-service attack by preventing a false endpoint or 
false
Media Distributor from successfully participating as a perceived valid 
media
sender that could otherwise carry out an on-path attack.  When mutual
authentication fails, a receiving endpoint would know that it could 
safely
discard media packets received from the endpoint without inspection.


How is that?

This says nothing about the other forms of attacks, such as a "false" 
endpoint sending bogus media packets to a receiver that carry the IP 
address of a valid sender.  In that case, the receiver would have no way 
of knowing if the packet is valid or not until it goes through the 
authenticated decryption process.  PERC (by its use of HBH 
authentication) would allow the receiver to detect such bogus packets, 
but that is a valid DoS attack vector addressed in prior paragraphs in 
that section.

Paul