Skip to main content

Telechat Review of draft-ietf-perc-private-media-framework-10
review-ietf-perc-private-media-framework-10-secdir-telechat-roca-2019-05-16-00

Request Review of draft-ietf-perc-private-media-framework
Requested revision No specific revision (document currently at 12)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2019-03-05
Requested 2019-02-22
Authors Paul Jones , David Benham , Christian Groves
Draft last updated 2019-05-16
Completed reviews Secdir Last Call review of -08 by Vincent Roca (diff)
Genart Last Call review of -08 by Linda Dunbar (diff)
Tsvart Last Call review of -08 by Gorry Fairhurst (diff)
Secdir Telechat review of -10 by Vincent Roca (diff)
Genart Telechat review of -09 by Linda Dunbar (diff)
Assignment Reviewer Vincent Roca
State Completed
Review review-ietf-perc-private-media-framework-10-secdir-telechat-roca-2019-05-16
Posted at https://mailarchive.ietf.org/arch/msg/secdir/obAGHwP651Rcp3AfcGKeWBCFy8s
Reviewed revision 10 (document currently at 12)
Result Ready
Completed 2019-05-16
review-ietf-perc-private-media-framework-10-secdir-telechat-roca-2019-05-16-00
Hello Paul,

Okay, I now get it. I was not considering an attacker stupid enough to fail
authentication but who would continue sending trafic with the same identifiers.
So I’m okay with your explanations and new version of the paragraph.

Summary: Ready

Thanks,

  Vincent

> Le 14 mai 2019 à 02:21, Paul E. Jones <paulej@packetizer.com> a écrit :
>
> Vincent,
>
> Please see inline below:
>
> ------ Original Message ------
> From: "Vincent Roca" <vincent.roca@inria.fr <mailto:vincent.roca@inria.fr>>
> To: "Paul E. Jones" <paulej@packetizer.com <mailto:paulej@packetizer.com>>
> Cc: "Vincent Roca" <vincent.roca@inria.fr <mailto:vincent.roca@inria.fr>>;
"The IESG" <iesg@ietf.org <mailto:iesg@ietf.org>>; "David Benham"
<dabenham@gmail.com <mailto:dabenham@gmail.com>>;
draft-ietf-perc-private-media-framework.all@ietf.org
<mailto:draft-ietf-perc-private-media-framework.all@ietf.org>;
aamelnikov@fastmail.fm <mailto:aamelnikov@fastmail.fm>; secdir@ietf.org
<mailto: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
<mailto: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
<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 > >