Return-Path: 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 F22C5120177; Fri, 10 May 2019 00:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 cysCKiYwBd7A; Fri, 10 May 2019 00:37:45 -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 23F2D120125; Fri, 10 May 2019 00:37:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,452,1549926000"; d="scan'208,217";a="382520763" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.0.34]) ([82.236.155.50]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 May 2019 09:37:38 +0200 From: Vincent Roca Message-Id: <1CE6DB48-325C-41C2-A526-3F5FD5FA8388@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_004B1C18-D31F-45CC-9E70-6C739D9926DA" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Fri, 10 May 2019 09:37:38 +0200 In-Reply-To: Cc: Vincent Roca , David Benham , draft-ietf-perc-private-media-framework.all@ietf.org, aamelnikov@fastmail.fm, secdir@ietf.org To: "Paul E. Jones" , The IESG References: <155014077570.26619.9407568904769535504@ietfa.amsl.com> <6882A552-80DF-4322-9683-13D8E655F2DB@inria.fr> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 07:37:49 -0000 --Apple-Mail=_004B1C18-D31F-45CC-9E70-6C739D9926DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear authors, all, I=E2=80=99ve looked at the new -10 version of your I-D. Summary: Ready with nits ** 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 =C2=AB Authentication =C2=BB = 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=E2=80=A6 So = please clarify. NB: there's also a typo in above sentence: "that the would". 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. ** 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 =C2=BB? Cheers, Vincent > Le 1 mai 2019 =C3=A0 07:00, Paul E. Jones a = =C3=A9crit : >=20 > Vincent, >=20 > I was finally able to get back to this and prepare an updated draft. = I make changes as outlined below that should appear in -10 shortly. >=20 > Section 8.1: Will add an introductory sentence. > Section 8.1: Good point. That's confusing, as mutual authentication is = required in DTLS-SRTP. The value goes beyond cascading, too, and is = really a tool to help mitigate against DoS. I'll re-word this paragraph = substantially. > Section 8.2.2: You're right. I'll make a clear requirement statement = on replay protection earlier in the body of the document and update that = text. > Section 8.2.3: Good point. And there is a limited mitigation for this, = which is to re-key the conference periodically. I'll add another = paragraph about that, since it might not be obvious. >=20 > Thanks! > Paul >=20 > ------ Original Message ------ > From: "Vincent Roca" > > To: "David Benham" >; = "Paul E. Jones" > > Cc: "Vincent Roca" >; secdir@ietf.org = ; = draft-ietf-perc-private-media-framework.all@ietf.org = ; "The = IESG" > > Sent: 3/4/2019 9:02:16 AM > Subject: Re: Secdir last call review of = draft-ietf-perc-private-media-framework >=20 >> Hello David, Paul, all, >>=20 >> I gave a look at version -09 of your I-D, here are a few comments. >>=20 >> Summary: Almost ready >>=20 >> ** Section 8.1 >> There is a sentence introducing section 8.2, but none for section = 8.1. For instance it is not explicitely >> explained what is meant by =C2=AB 3rd party attack =C2=BB. I suggest = adding a sentence. >>=20 >> ** Section 8.1 >> You=E2=80=99re saying that "If mutual DTLS authentication is not = employed=E2=80=A6 =C2=BB. Is it really an optional mechanism? >> I must admit I haven=E2=80=99t read the rest of your I-D where this = is probably explained, I=E2=80=99m just a bit surprised here. >>=20 >> ** Section 8.2.2 >> It is suggested but not clearly said that the replay protection of = Section 3.3.2/[RFC3711] MUST be used. >> The sentence can be understood as replay protection is mandatory, = Section 3.3.2 of [RFC3711] is an example >> of such a mechanism. >> I don't think this is what you mean. >>=20 >> ** Section 8.2.3 >> Saying that "The delayed playout attack is a variant of the replay = attack" is IMHO misleading. >> Delaying and re-sending a packet already sent are two different = attacks (and the fact that replay >> protection is of no help against delayed packets is a good sign of = these differences). >> I'd remove this sentence altogether. >>=20 >>=20 >> Otherwise, concerning your previous comment: >>=20 >>=20 >>> Follow up question regarding your general comments on sect 8.1 and = 8.2 which we have not yet addressed in -09 ; >>>=20 >>> > Attacks of section 8.1 seems more realistic to me than attacks of = section 8.2 >>> > because of a weaker attacker model: the attacker is outside of the = systems,=20 >>> > and not necessarily on the path. =20 >>> > Therefore I would have liked to see more details in section 8.1, = that=E2=80=99s all. >>>=20 >>> You're asking for greater detail in sect 8.1 precisely because you = estimate that third-party attacks (aka outsiders to a given conference) = are more likely/common than the attacks we covered in the subsequent 8.2 = section. Is that correct? >>>=20 >>> If so, I think we could restate some of what we have in sect 8.1 to = make it flow better and/or be clearer. But it is not clear to us what = we left out detail-wise, or if we left out other attack examples. >>>=20 >>> With PERC's HBH integrity checks, authentication as well as HBH and = E2E encryption, we can quickly describe in text the = prevention/mitigation of attacks on the confidentiality of the = media/content - PERCs reason to be - to explain some of the brevity.=20 >>>=20 >>> Could you help point us in the right direction with an example or = two of the things we should do to detail/elaborate sect 8.1. >>=20 >> [VR] I was surprised to see for instance 8 lines of text in section = 8.2.2 or 8.2.4 to describe attacks >> that cannot take place because of the PERC design. That being said, I = see that version -09 has a >> more detailed section 8.1 which is fine. >>=20 >> Cheers, >>=20 >> Vincent --Apple-Mail=_004B1C18-D31F-45CC-9E70-6C739D9926DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear authors, all,

I=E2=80=99ve looked at the new -10 = version of your I-D.

Summary: Ready with = nits


** 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 =C2=AB Authentication =C2=BB 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=E2=80=A6= So please
clarify.

NB: there's also a typo in above = sentence: "that the would".

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.


** 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 =C2=BB?


Cheers,

  Vincent


Le 1 mai 2019 =C3=A0 07:00, Paul E. Jones = <paulej@packetizer.com> a =C3=A9crit :

Vincent,

I was finally able to get back to this and prepare an = updated draft.  I make changes as outlined below that should appear = in -10 shortly.

Section 8.1: Will add an introductory = sentence.
Section 8.1: Good point. That's = confusing, as mutual authentication is required in DTLS-SRTP. The value = goes beyond cascading, too, and is really a tool to help mitigate = against DoS.  I'll re-word this paragraph substantially.
Section 8.2.2: You're right. I'll make a clear = requirement statement on replay protection earlier in the body of the = document and update that text.
Section 8.2.3: Good point. And there = is a limited mitigation for this, which is to re-key the conference = periodically.  I'll add another paragraph about that, since it = might not be obvious.

Thanks!
Paul

------ Original Message = ------
From: "Vincent Roca" <vincent.roca@inria.fr>
To: = "David Benham" <dabenham@gmail.com>; "Paul E. Jones" <paulej@packetizer.com>
Cc: = "Vincent Roca" <vincent.roca@inria.fr>; secdir@ietf.org; draft-ietf-perc-private-media-framework.all@ietf.org; = "The IESG" <iesg@ietf.org>
Sent: = 3/4/2019 9:02:16 AM
Subject: Re: Secdir last call review = of draft-ietf-perc-private-media-framework

Hello David, Paul, all,

I gave a look at version = -09 of your I-D, here are a few comments.

Summary: Almost = ready

** Section 8.1
 There= is a sentence introducing section 8.2, but none for section 8.1. For = instance it is not explicitely
explained what is = meant by =C2=AB 3rd party attack =C2=BB. I suggest adding a = sentence.

** Section 8.1
You=E2=80=99re saying = that "If mutual DTLS authentication is not employed=E2=80=A6 =C2=BB. = Is it really an optional mechanism?
I must admit I = haven=E2=80=99t read the rest of your I-D where this is probably = explained, I=E2=80=99m just a bit surprised here.
** Section = 8.2.2
It is suggested but not clearly said that the = replay protection of Section 3.3.2/[RFC3711] MUST be used.
The sentence can be understood as replay protection is = mandatory, Section 3.3.2 of [RFC3711] is an example
of such a mechanism.
I don't think this = is what you mean.

** Section 8.2.3
Saying that "The = delayed playout attack is a variant of the replay attack" is IMHO = misleading.
Delaying and re-sending a packet = already sent are two different attacks (and the fact that = replay
protection is of no help against delayed = packets is a good sign of these differences).
I'd = remove this sentence altogether.


Otherwise, concerning your previous comment:


Follow up question regarding your = general comments on sect 8.1 and 8.2 which we have not yet addressed in = -09 ;

> = Attacks of section 8.1 seems more realistic to me than attacks of = section 8.2
> because of a weaker attacker model: the = attacker is outside of the systems, 
> and not = necessarily on the path.  
> Therefore I would have liked to see more details in = section 8.1, that=E2=80=99s all.

You're asking for greater detail in = sect 8.1 precisely because you estimate that third-party attacks (aka = outsiders to a given conference) are more likely/common than the attacks = we covered in the subsequent 8.2 section.   Is = that correct?

If so, I think we could restate some of what we have in sect = 8.1 to make it flow better and/or be clearer.   But it is not = clear to us what we left out detail-wise, or if we left out other attack = examples.

With = PERC's HBH integrity checks, authentication as well as HBH and E2E = encryption, we can quickly describe in text the prevention/mitigation of = attacks on the confidentiality of the media/content - PERCs reason = to be - to explain some of the brevity. 

Could you help point us in the right = direction with an example or two of the things we should do to = detail/elaborate sect = 8.1.

[VR] I was surprised to see for = instance 8 lines of text in section 8.2.2 or 8.2.4 to describe = attacks
that cannot take place because of the PERC = design. That being said, I see that version -09 has a
more detailed section 8.1 which is fine.

Cheers,

  =  Vincent

= --Apple-Mail=_004B1C18-D31F-45CC-9E70-6C739D9926DA--