From nobody Wed May 1 12:12:33 2019 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6661200B5 for ; Wed, 1 May 2019 12:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 f8AkT0GAiX9y for ; Wed, 1 May 2019 12:12:24 -0700 (PDT) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (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 B1EB8120156 for ; Wed, 1 May 2019 12:12:22 -0700 (PDT) Received: by mail-oi1-x233.google.com with SMTP id w197so14569781oia.2 for ; Wed, 01 May 2019 12:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ST4IZlWrhOo38+baE4j8U8sMFbZEkXjoS7pk+R0Cz+w=; b=nrEv+dUEy8dQRx+sewhYBRHi+fphgHM71k++eBfftXQ9W62rI3zd61hxc07/JjOGPf /cS36OZ1dUA2Ppf23RS4dfd/YFAEEPJmRvVcs6mxNxNuBCUcPpxAdCr91a4dq3nG+bP4 nUBRI0vLFD84Dv8Smb256FrxhqbcJoPEtqbSIQ4DF14DXqRvmJXuNK5jH1n+SQ9I6C8y /nDbzd4dQ4BwdvxKZCXvwp4I5q++akPXckCy6QQdshJqjL6/SGMLn3iA54gVs/qRlJRh xy4uBGi4I+RrYwcdXBTthQ5JMbcmPbQW89iSD/I/iBQVO+yrBU2UlzQPQbr7Wh7oXtuS 8/hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ST4IZlWrhOo38+baE4j8U8sMFbZEkXjoS7pk+R0Cz+w=; b=cSX4yWZkNTJMc1/KJfyKucD09GZpIYKEdJH/4WD/kw2tsQOkdSqxhp7R1kQFmGVRtk 30fFM3tP6WvWTNVM8XppikVhYlZzVy3tFrymHHamNCbV1SMNzy4NcsyRTOe8RZyt7Tgn XqzJs/GGFKvp+HgiE4ZWGaipvuVuS52HgKDd+W4s9tqTVHfHuz5W9TJ5DKVu/RFslYww t31CDq4TrAvEcmyCk4XqzcnzqbLuPbItqZSTBeWwOuN5iPiVUGqN9aacJKsXhBSjreY8 IdF6eQj301a7EEqyn6UBGgDeB+YalBEE1WgfDCaH5x6LHrCGr+bOy7R0YMcknywhjJdC NZ9w== X-Gm-Message-State: APjAAAVYG3nNFCgx2IT4eyCY8DOj2oxD+ZaeayaRL9I89AELd7I73Te/ RPIApoun1pW2kPRaUKCUwBI/nnuDoQRSpnV/9onmoA== X-Google-Smtp-Source: APXvYqwg9ZVtc6johygqzRmr8RkAkTirrmyCcIYVwJ+6Dk/IXUXYoho6ldFgrydn9v14YAc0FfgBfeIq4aRU26i9YEk= X-Received: by 2002:aca:cf12:: with SMTP id f18mr6973531oig.149.1556737941870; Wed, 01 May 2019 12:12:21 -0700 (PDT) MIME-Version: 1.0 References: <155066913758.31303.1282920476578920472.idtracker@ietfa.amsl.com> In-Reply-To: <155066913758.31303.1282920476578920472.idtracker@ietfa.amsl.com> From: Richard Barnes Date: Wed, 1 May 2019 15:11:53 -0400 Message-ID: To: Alexey Melnikov Cc: The IESG , perc-chairs@ietf.org, Suhas Nandakumar , perc@ietf.org, draft-ietf-perc-srtp-ekt-diet@ietf.org Content-Type: multipart/alternative; boundary="00000000000008b1500587d84c66" Archived-At: Subject: Re: [Perc] Alexey Melnikov's Discuss on draft-ietf-perc-srtp-ekt-diet-09: (with DISCUSS and COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 19:12:31 -0000 --00000000000008b1500587d84c66 Content-Type: text/plain; charset="UTF-8" Hey Alexey, Good catch. I agree that those bits are malformed. Unless folks here object, I will change those portions to say that the receiver MUST discard the packet if it receives an unknown message type. TBH, I don't really see how we can do otherwise, unless we include a length field that is required for all message types (or maybe all message types except type 0). --RLB On Wed, Feb 20, 2019 at 8:25 AM Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-perc-srtp-ekt-diet-09: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > The document is generally quite readable, which is great. But I have a few > small issues I would like to get clarification on before recommending > approval > of this document: > > In 4.1: > > Message Type: The last byte is used to indicate the type of the > EKTField. This MUST be 2 for the FullEKTField format and 0 in > ShortEKTField format. Values less than 64 are mandatory to > understand while other values are optional to understand. > > I thought I knew what this meant when I read it, and then I saw this: > > A receiver > SHOULD discard the whole EKTField if it contains any message type > value that is less than 64 and that is not understood. > > "SHOULD discard ... EKTField" makes this field NOT mandatory. (If you said > "SHOULD discard the whole packet", that would have been different.) Also, > how > "discard" different from the following sentence suggesting "ignore"? I > think > you have some inconsistencies/terminology problem here! > > Message type > values that are 64 or greater but not implemented or understood can > simply be ignored. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I share Benjamin's concern about extensibility. > > General: > > Mixture of normative TLS 1.2 and TLS 1.3 references is confusing in the > document. There is a note later on explaining that either can be used, but > it > would be better for readers to see this note earlier in the document. > > In 4.1: > > EKTMsgLength = 2BYTE; > > and similarly: > > SPI = 2BYTE > > The document doesn't seem to say whether or not this is in network byte > order. > > In 4.2.1: > > 2. The EKTPlaintext field is computed from the SRTP Master Key, > SSRC, and ROC fields, as shown in Section 4.1. The ROC, SRTP > Master Key, and SSRC used in EKT processing SHOULD be the same as > the one used in the SRTP processing. > > When can they be different? I.e. why is this not a MUST? > > The computed value of the FullEKTField is written into the SRTP > packet. > > I think this might be misleading. Do you just mean appended to the end of > the > SRTP packet after encrypted data? If yes, please say so to avoid confusion > with > writing it into encrypted data before encryption. > > In 4.3: > > When receiving a new EKTKey, implementations need to use the ekt_ttl > field (see Section 5.2.2) to create a time after which this key > cannot be used and they also need to create a counter that keeps > track of how many times the key has been used to encrypt data to > ensure it does not exceed the T value for that cipher (see ). > > Missing reference after "see" here. > > In 4.4.1: > > The default EKT Cipher is the Advanced Encryption Standard (AES) Key > Wrap with Padding [RFC5649] algorithm. It requires a plaintext > length M that is at least one octet, and it returns a ciphertext with > a length of N = M + (M mod 8) + 8 octets. > > I started looking at RFC 5649. Maybe I was tired and my math was wrong, > but I > couldn't figure out how you came up with the N value above. In particular, > where is the "+ 8" coming from? > > In 4.7: > > New sender: > A new sender SHOULD send a packet containing the FullEKTField as > soon as possible, always before or coincident with sending its > initial SRTP packet. To accommodate packet loss, it is > RECOMMENDED that three consecutive packets contain the > FullEKTField be transmitted. If the sender does not send a > FullEKTField in its initial packets and receivers have not > otherwise been provisioned with a decryption key, then decryption > will fail and SRTP packets will be dropped until the the receives > > Nit: duplicated "the". > > a FullEKTField from the sender. > > In 6: > > An attacker who tampers with the bits in FullEKTField can prevent the > intended receiver of that packet from being able to decrypt it. This > is a minor denial of service vulnerability. Similarly the attacker > could take an old FullEKTField from the same session and attach it to > the packet. The FullEKTField would correctly decode and pass > integrity checks. However, the key extracted from the FullEKTField , > when used to decrypt the SRTP payload, would be wrong and the SRTP > integrity check would fail. Note that the FullEKTField only changes > the decryption key and does not change the encryption key. None of > these are considered significant attacks as any attacker that can > modify the packets in transit and cause the integrity check to fail. > > The last sentence seems to be incomplete. Did you mean "can" instead of the > last "end"? > > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --00000000000008b1500587d84c66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Alexey,

Good catch.=C2=A0 I agree that those bits are malformed.=C2=A0 Unle= ss folks here object, I will change those portions to say that the receiver= MUST discard the packet if it receives an unknown message type.=C2=A0 TBH,= I don't really see how we can do otherwise, unless we include a length= field that is required for all message types (or maybe all message types e= xcept type 0).

--RLB

On Wed, Feb 20, 2019 at 8:= 25 AM Alexey Melnikov <aamelni= kov@fastmail.fm> wrote:
Alexey Melnikov has entered the following ballot position fo= r
draft-ietf-perc-srtp-ekt-diet-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draf= t-ietf-perc-srtp-ekt-diet/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The document is generally quite readable, which is great. But I have a few<= br> small issues I would like to get clarification on before recommending appro= val
of this document:

In 4.1:

=C2=A0 =C2=A0Message Type: The last byte is used to indicate the type of th= e
=C2=A0 =C2=A0EKTField.=C2=A0 This MUST be 2 for the FullEKTField format and= 0 in
=C2=A0 =C2=A0ShortEKTField format.=C2=A0 Values less than 64 are mandatory = to
=C2=A0 =C2=A0understand while other values are optional to understand.

I thought I knew what this meant when I read it, and then I saw this:

=C2=A0 =C2=A0A receiver
=C2=A0 =C2=A0SHOULD discard the whole EKTField if it contains any message t= ype
=C2=A0 =C2=A0value that is less than 64 and that is not understood.

"SHOULD discard ... EKTField" makes this field NOT mandatory. (If= you said
"SHOULD discard the whole packet", that would have been different= .) Also, how
"discard" different from the following sentence suggesting "= ignore"? I think
you have some inconsistencies/terminology problem here!

=C2=A0 =C2=A0Message type
=C2=A0 =C2=A0values that are 64 or greater but not implemented or understoo= d can
=C2=A0 =C2=A0simply be ignored.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I share Benjamin's concern about extensibility.

General:

Mixture of normative TLS 1.2 and TLS 1.3 references is confusing in the
document. There is a note later on explaining that either can be used, but = it
would be better for readers to see this note earlier in the document.

In 4.1:

=C2=A0 EKTMsgLength =3D 2BYTE;

and similarly:

=C2=A0 =C2=A0SPI =3D 2BYTE

The document doesn't seem to say whether or not this is in network byte= order.

In 4.2.1:

=C2=A0 =C2=A02.=C2=A0 The EKTPlaintext field is computed from the SRTP Mast= er Key,
=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC, and ROC fields, as shown in Section 4.1.= =C2=A0 The ROC, SRTP
=C2=A0 =C2=A0 =C2=A0 =C2=A0Master Key, and SSRC used in EKT processing SHOU= LD be the same as
=C2=A0 =C2=A0 =C2=A0 =C2=A0the one used in the SRTP processing.

When can they be different? I.e. why is this not a MUST?

=C2=A0 =C2=A0The computed value of the FullEKTField is written into the SRT= P
=C2=A0 =C2=A0packet.

I think this might be misleading. Do you just mean appended to the end of t= he
SRTP packet after encrypted data? If yes, please say so to avoid confusion = with
writing it into encrypted data before encryption.

In 4.3:

=C2=A0 =C2=A0When receiving a new EKTKey, implementations need to use the e= kt_ttl
=C2=A0 =C2=A0field (see Section 5.2.2) to create a time after which this ke= y
=C2=A0 =C2=A0cannot be used and they also need to create a counter that kee= ps
=C2=A0 =C2=A0track of how many times the key has been used to encrypt data = to
=C2=A0 =C2=A0ensure it does not exceed the T value for that cipher (see ).<= br>
Missing reference after "see" here.

In 4.4.1:

=C2=A0 =C2=A0The default EKT Cipher is the Advanced Encryption Standard (AE= S) Key
=C2=A0 =C2=A0Wrap with Padding [RFC5649] algorithm.=C2=A0 It requires a pla= intext
=C2=A0 =C2=A0length M that is at least one octet, and it returns a cipherte= xt with
=C2=A0 =C2=A0a length of N =3D M + (M mod 8) + 8 octets.

I started looking at RFC 5649. Maybe I was tired and my math was wrong, but= I
couldn't figure out how you came up with the N value above. In particul= ar,
where is the "+ 8" coming from?

In 4.7:

=C2=A0 =C2=A0New sender:
=C2=A0 =C2=A0 =C2=A0 A new sender SHOULD send a packet containing the FullE= KTField as
=C2=A0 =C2=A0 =C2=A0 soon as possible, always before or coincident with sen= ding its
=C2=A0 =C2=A0 =C2=A0 initial SRTP packet.=C2=A0 To accommodate packet loss,= it is
=C2=A0 =C2=A0 =C2=A0 RECOMMENDED that three consecutive packets contain the=
=C2=A0 =C2=A0 =C2=A0 FullEKTField be transmitted.=C2=A0 If the sender does = not send a
=C2=A0 =C2=A0 =C2=A0 FullEKTField in its initial packets and receivers have= not
=C2=A0 =C2=A0 =C2=A0 otherwise been provisioned with a decryption key, then= decryption
=C2=A0 =C2=A0 =C2=A0 will fail and SRTP packets will be dropped until the t= he receives

Nit: duplicated "the".

=C2=A0 =C2=A0 =C2=A0 a FullEKTField from the sender.

In 6:

=C2=A0 =C2=A0An attacker who tampers with the bits in FullEKTField can prev= ent the
=C2=A0 =C2=A0intended receiver of that packet from being able to decrypt it= .=C2=A0 This
=C2=A0 =C2=A0is a minor denial of service vulnerability.=C2=A0 Similarly th= e attacker
=C2=A0 =C2=A0could take an old FullEKTField from the same session and attac= h it to
=C2=A0 =C2=A0the packet.=C2=A0 The FullEKTField would correctly decode and = pass
=C2=A0 =C2=A0integrity checks.=C2=A0 However, the key extracted from the Fu= llEKTField ,
=C2=A0 =C2=A0when used to decrypt the SRTP payload, would be wrong and the = SRTP
=C2=A0 =C2=A0integrity check would fail.=C2=A0 Note that the FullEKTField o= nly changes
=C2=A0 =C2=A0the decryption key and does not change the encryption key.=C2= =A0 None of
=C2=A0 =C2=A0these are considered significant attacks as any attacker that = can
=C2=A0 =C2=A0modify the packets in transit and cause the integrity check to= fail.

The last sentence seems to be incomplete. Did you mean "can" inst= ead of the
last "end"?


_______________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc
--00000000000008b1500587d84c66-- From nobody Wed May 1 12:53:26 2019 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931E412011E for ; Wed, 1 May 2019 12:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 DUEeEy--hrnh for ; Wed, 1 May 2019 12:53:21 -0700 (PDT) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 26FE61201B8 for ; Wed, 1 May 2019 12:53:21 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id e108so22308ote.10 for ; Wed, 01 May 2019 12:53:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0FKX8p0lr3CdnfYLTuQVPWkb/JV1tdylGn52IrcP6r0=; b=CZDkaGxAAydYflKV9UZMLm3gJwGgo2TViOUl0mRnb5EV1cw56mYNPiVB4UuWP8PWFg BBdN+KKo2qdB0PfurAdZqe0AWd5Meftze6sZFTPlHLVpgMNXd6z64RDkTSKH4qjP/Tdy TKbZ3Imyv2HQF8DtCbg1nM0mjMSXFunhAiQKXjCD5vDRumQFFjRKPpcG+nW7BL0jBTNz tL1ZTnJomIZ2ewyy8ZXwfJAqnHYfHhcj/2JQINA3wdMLLsO79Ppx/owBT6EgLBz+SJeQ zWyw6md46NxWH/8GzHIiJj9acPvpRNYHCvYKGml59dq7V6JtXFn9uHPW3rJTHvye4RNk QPdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0FKX8p0lr3CdnfYLTuQVPWkb/JV1tdylGn52IrcP6r0=; b=PFy6uoeUWGAZ3VX+08u/uY2yv6jWFLrKATtilhfjcLOm/bLkgquj+DxYaqASz6HCsF bJxiikudAK4IM4y04epLAYIPuR8b3eEQxsJ0PKmy+JYx+0qcnEYNJvya3kDYTkH6DKnY Uo12VoubFwcNx0rLpvuM+ZWzyx0Nw70BlunOUQnl1ThlbXJpCCi41xDqrzqmmVeQQSdQ lrJn8cZfsbCqaVbgn0XvHruGEbMbOnq+QCWXDqBuPQ395Pf7i+WfLLqRHvFrJ0sPMRV4 cDygma93GqeVqCTDRQGZOU+060Ph9+2CT/Phcvazm8u+Lw7h9A2Xl0jIrjQna6aImxiN dIkQ== X-Gm-Message-State: APjAAAVZwSXX1JqcZXxU2tVAyVZ0lXf857MsXUCxnpjQaNGh+NcfOPCe B8TtVflEwSOXCF+u1uHBILrPAUij2He6k4FAZyGaMQ== X-Google-Smtp-Source: APXvYqyQ1NPPhynJibKP4LxqenERB/BP38kD+dJ304xKXXSHQu0DT7DlI5WveqzBVQ4qR8kCN4WpOopxbE5PvhvXiMs= X-Received: by 2002:a05:6830:108f:: with SMTP id y15mr2872754oto.23.1556740400242; Wed, 01 May 2019 12:53:20 -0700 (PDT) MIME-Version: 1.0 References: <155066913758.31303.1282920476578920472.idtracker@ietfa.amsl.com> In-Reply-To: From: Richard Barnes Date: Wed, 1 May 2019 15:52:51 -0400 Message-ID: To: Alexey Melnikov Cc: The IESG , perc-chairs@ietf.org, Suhas Nandakumar , perc@ietf.org, draft-ietf-perc-srtp-ekt-diet@ietf.org Content-Type: multipart/alternative; boundary="0000000000009072310587d8de65" Archived-At: Subject: Re: [Perc] Alexey Melnikov's Discuss on draft-ietf-perc-srtp-ekt-diet-09: (with DISCUSS and COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 19:53:25 -0000 --0000000000009072310587d8de65 Content-Type: text/plain; charset="UTF-8" PR here: https://github.com/ietf/perc-wg/pull/169 Some comments inline below... On Wed, May 1, 2019 at 3:11 PM Richard Barnes wrote: > Hey Alexey, > > Good catch. I agree that those bits are malformed. Unless folks here > object, I will change those portions to say that the receiver MUST discard > the packet if it receives an unknown message type. TBH, I don't really see > how we can do otherwise, unless we include a length field that is required > for all message types (or maybe all message types except type 0). > > --RLB > > On Wed, Feb 20, 2019 at 8:25 AM Alexey Melnikov > wrote: > >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-perc-srtp-ekt-diet-09: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> The document is generally quite readable, which is great. But I have a few >> small issues I would like to get clarification on before recommending >> approval >> of this document: >> >> In 4.1: >> >> Message Type: The last byte is used to indicate the type of the >> EKTField. This MUST be 2 for the FullEKTField format and 0 in >> ShortEKTField format. Values less than 64 are mandatory to >> understand while other values are optional to understand. >> >> I thought I knew what this meant when I read it, and then I saw this: >> >> A receiver >> SHOULD discard the whole EKTField if it contains any message type >> value that is less than 64 and that is not understood. >> >> "SHOULD discard ... EKTField" makes this field NOT mandatory. (If you said >> "SHOULD discard the whole packet", that would have been different.) Also, >> how >> "discard" different from the following sentence suggesting "ignore"? I >> think >> you have some inconsistencies/terminology problem here! >> >> Message type >> values that are 64 or greater but not implemented or understood can >> simply be ignored. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I share Benjamin's concern about extensibility. >> >> General: >> >> Mixture of normative TLS 1.2 and TLS 1.3 references is confusing in the >> document. There is a note later on explaining that either can be used, >> but it >> would be better for readers to see this note earlier in the document. >> > Removed the normative reference to 1.2, moved the note forward. > In 4.1: >> >> EKTMsgLength = 2BYTE; >> >> and similarly: >> >> SPI = 2BYTE >> >> The document doesn't seem to say whether or not this is in network byte >> order. >> > Clarified for the message length. It actually doesn't matter for the SPI, as long as an implementation is internally consistent, since this isn't an integer, it's an opaque ID. > In 4.2.1: >> >> 2. The EKTPlaintext field is computed from the SRTP Master Key, >> SSRC, and ROC fields, as shown in Section 4.1. The ROC, SRTP >> Master Key, and SSRC used in EKT processing SHOULD be the same as >> the one used in the SRTP processing. >> >> When can they be different? I.e. why is this not a MUST? >> > Changed to MUST. > The computed value of the FullEKTField is written into the SRTP >> packet. >> >> I think this might be misleading. Do you just mean appended to the end of >> the >> SRTP packet after encrypted data? If yes, please say so to avoid >> confusion with >> writing it into encrypted data before encryption. >> > Changed to "appended to". > >> In 4.3: >> >> When receiving a new EKTKey, implementations need to use the ekt_ttl >> field (see Section 5.2.2) to create a time after which this key >> cannot be used and they also need to create a counter that keeps >> track of how many times the key has been used to encrypt data to >> ensure it does not exceed the T value for that cipher (see ). >> >> Missing reference after "see" here. >> > Fixed. > In 4.4.1: >> >> The default EKT Cipher is the Advanced Encryption Standard (AES) Key >> Wrap with Padding [RFC5649] algorithm. It requires a plaintext >> length M that is at least one octet, and it returns a ciphertext with >> a length of N = M + (M mod 8) + 8 octets. >> >> I started looking at RFC 5649. Maybe I was tired and my math was wrong, >> but I >> couldn't figure out how you came up with the N value above. In particular, >> where is the "+ 8" coming from? >> > It's the auth tag. Basically, key wrap encrypts in 64-bit blocks and adds a 64-bit auth tag. https://tools.ietf.org/html/rfc5649#section-4.1 > In 4.7: >> >> New sender: >> A new sender SHOULD send a packet containing the FullEKTField as >> soon as possible, always before or coincident with sending its >> initial SRTP packet. To accommodate packet loss, it is >> RECOMMENDED that three consecutive packets contain the >> FullEKTField be transmitted. If the sender does not send a >> FullEKTField in its initial packets and receivers have not >> otherwise been provisioned with a decryption key, then decryption >> will fail and SRTP packets will be dropped until the the receives >> >> Nit: duplicated "the". >> > Also no noun after the article! > a FullEKTField from the sender. >> >> In 6: >> >> An attacker who tampers with the bits in FullEKTField can prevent the >> intended receiver of that packet from being able to decrypt it. This >> is a minor denial of service vulnerability. Similarly the attacker >> could take an old FullEKTField from the same session and attach it to >> the packet. The FullEKTField would correctly decode and pass >> integrity checks. However, the key extracted from the FullEKTField , >> when used to decrypt the SRTP payload, would be wrong and the SRTP >> integrity check would fail. Note that the FullEKTField only changes >> the decryption key and does not change the encryption key. None of >> these are considered significant attacks as any attacker that can >> modify the packets in transit and cause the integrity check to fail. >> >> The last sentence seems to be incomplete. Did you mean "can" instead of >> the >> last "end"? >> > Yes, "can cause". > >> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >> > --0000000000009072310587d8de65 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
PR here:
=

Some comment= s inline below...

On Wed, May 1, 2019 at 3:11 PM Richard Barnes &l= t;rlb@ipv.sx> wrote:
Hey Alexey,

Good catch.=C2=A0 I agree that those bits are malformed.=C2= =A0 Unless folks here object, I will change those portions to say that the = receiver MUST discard the packet if it receives an unknown message type.=C2= =A0 TBH, I don't really see how we can do otherwise, unless we include = a length field that is required for all message types (or maybe all message= types except type 0).

--RLB

On Wed, Feb 20, 20= 19 at 8:25 AM Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
Alexey Melnikov has entered the fo= llowing ballot position for
draft-ietf-perc-srtp-ekt-diet-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draf= t-ietf-perc-srtp-ekt-diet/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The document is generally quite readable, which is great. But I have a few<= br> small issues I would like to get clarification on before recommending appro= val
of this document:

In 4.1:

=C2=A0 =C2=A0Message Type: The last byte is used to indicate the type of th= e
=C2=A0 =C2=A0EKTField.=C2=A0 This MUST be 2 for the FullEKTField format and= 0 in
=C2=A0 =C2=A0ShortEKTField format.=C2=A0 Values less than 64 are mandatory = to
=C2=A0 =C2=A0understand while other values are optional to understand.

I thought I knew what this meant when I read it, and then I saw this:

=C2=A0 =C2=A0A receiver
=C2=A0 =C2=A0SHOULD discard the whole EKTField if it contains any message t= ype
=C2=A0 =C2=A0value that is less than 64 and that is not understood.

"SHOULD discard ... EKTField" makes this field NOT mandatory. (If= you said
"SHOULD discard the whole packet", that would have been different= .) Also, how
"discard" different from the following sentence suggesting "= ignore"? I think
you have some inconsistencies/terminology problem here!

=C2=A0 =C2=A0Message type
=C2=A0 =C2=A0values that are 64 or greater but not implemented or understoo= d can
=C2=A0 =C2=A0simply be ignored.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I share Benjamin's concern about extensibility.

General:

Mixture of normative TLS 1.2 and TLS 1.3 references is confusing in the
document. There is a note later on explaining that either can be used, but = it
would be better for readers to see this note earlier in the document.

Removed the normative reference to 1.2, move= d the note forward.

=C2=A0
In 4.1:

=C2=A0 EKTMsgLength =3D 2BYTE;

and similarly:

=C2=A0 =C2=A0SPI =3D 2BYTE

The document doesn't seem to say whether or not this is in network byte= order.

Clarif= ied for the message length.=C2=A0 It actually doesn't matter for the SP= I, as long as an implementation is internally consistent, since this isn= 9;t an integer, it's an opaque ID.

=C2=A0<= /div>
In 4.2.1:

=C2=A0 =C2=A02.=C2=A0 The EKTPlaintext field is computed from the SRTP Mast= er Key,
=C2=A0 =C2=A0 =C2=A0 =C2=A0SSRC, and ROC fields, as shown in Section 4.1.= =C2=A0 The ROC, SRTP
=C2=A0 =C2=A0 =C2=A0 =C2=A0Master Key, and SSRC used in EKT processing SHOU= LD be the same as
=C2=A0 =C2=A0 =C2=A0 =C2=A0the one used in the SRTP processing.

When can they be different? I.e. why is this not a MUST?

Changed to MUST.

<= /div>
=C2=A0
=C2=A0 =C2=A0The computed value of the FullEKTField is written into the SRT= P
=C2=A0 =C2=A0packet.

I think this might be misleading. Do you just mean appended to the end of t= he
SRTP packet after encrypted data? If yes, please say so to avoid confusion = with
writing it into encrypted data before encryption.

Changed to "appended to".

=C2=A0

In 4.3:

=C2=A0 =C2=A0When receiving a new EKTKey, implementations need to use the e= kt_ttl
=C2=A0 =C2=A0field (see Section 5.2.2) to create a time after which this ke= y
=C2=A0 =C2=A0cannot be used and they also need to create a counter that kee= ps
=C2=A0 =C2=A0track of how many times the key has been used to encrypt data = to
=C2=A0 =C2=A0ensure it does not exceed the T value for that cipher (see ).<= br>
Missing reference after "see" here.
<= /blockquote>

Fixed.

=C2=A0
In 4.4.1:

=C2=A0 =C2=A0The default EKT Cipher is the Advanced Encryption Standard (AE= S) Key
=C2=A0 =C2=A0Wrap with Padding [RFC5649] algorithm.=C2=A0 It requires a pla= intext
=C2=A0 =C2=A0length M that is at least one octet, and it returns a cipherte= xt with
=C2=A0 =C2=A0a length of N =3D M + (M mod 8) + 8 octets.

I started looking at RFC 5649. Maybe I was tired and my math was wrong, but= I
couldn't figure out how you came up with the N value above. In particul= ar,
where is the "+ 8" coming from?

It's the auth tag.=C2=A0 Basically, key wra= p encrypts in 64-bit blocks and adds a 64-bit auth tag.

<= /div>

=C2= =A0
In 4.7:

=C2=A0 =C2=A0New sender:
=C2=A0 =C2=A0 =C2=A0 A new sender SHOULD send a packet containing the FullE= KTField as
=C2=A0 =C2=A0 =C2=A0 soon as possible, always before or coincident with sen= ding its
=C2=A0 =C2=A0 =C2=A0 initial SRTP packet.=C2=A0 To accommodate packet loss,= it is
=C2=A0 =C2=A0 =C2=A0 RECOMMENDED that three consecutive packets contain the=
=C2=A0 =C2=A0 =C2=A0 FullEKTField be transmitted.=C2=A0 If the sender does = not send a
=C2=A0 =C2=A0 =C2=A0 FullEKTField in its initial packets and receivers have= not
=C2=A0 =C2=A0 =C2=A0 otherwise been provisioned with a decryption key, then= decryption
=C2=A0 =C2=A0 =C2=A0 will fail and SRTP packets will be dropped until the t= he receives

Nit: duplicated "the".
<= div>
Also no noun after the article!

=C2=A0
=C2=A0 =C2=A0 =C2=A0 a FullEKTField from the sender.

In 6:

=C2=A0 =C2=A0An attacker who tampers with the bits in FullEKTField can prev= ent the
=C2=A0 =C2=A0intended receiver of that packet from being able to decrypt it= .=C2=A0 This
=C2=A0 =C2=A0is a minor denial of service vulnerability.=C2=A0 Similarly th= e attacker
=C2=A0 =C2=A0could take an old FullEKTField from the same session and attac= h it to
=C2=A0 =C2=A0the packet.=C2=A0 The FullEKTField would correctly decode and = pass
=C2=A0 =C2=A0integrity checks.=C2=A0 However, the key extracted from the Fu= llEKTField ,
=C2=A0 =C2=A0when used to decrypt the SRTP payload, would be wrong and the = SRTP
=C2=A0 =C2=A0integrity check would fail.=C2=A0 Note that the FullEKTField o= nly changes
=C2=A0 =C2=A0the decryption key and does not change the encryption key.=C2= =A0 None of
=C2=A0 =C2=A0these are considered significant attacks as any attacker that = can
=C2=A0 =C2=A0modify the packets in transit and cause the integrity check to= fail.

The last sentence seems to be incomplete. Did you mean "can" inst= ead of the
last "end"?

Yes, "can cause".

=C2=A0


_______________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc
--0000000000009072310587d8de65-- From nobody Sun May 12 23:21:53 2019 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF76B12006B; Sun, 12 May 2019 23:21:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-perc-double@ietf.org, Suhas Nandakumar , perc-chairs@ietf.org, perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <155772850584.31825.1502158017227231320.idtracker@ietfa.amsl.com> Date: Sun, 12 May 2019 23:21:45 -0700 Archived-At: Subject: [Perc] Barry Leiba's No Objection on draft-ietf-perc-double-10: (with COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2019 06:21:46 -0000 Barry Leiba has entered the following ballot position for draft-ietf-perc-double-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-perc-double/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- — Section 2 — In the definition of “hop-by-hop”: The definition of “end-to-end” says there can be more than one distributor. So, can’t a hop also be distributor to distributor (not involving an endpoint)? Also, the definition is really of “hop”, rather than of “hop-by-hop”, isn’t it? — Section 3 — The RECOMMENDED cipher for the hop-by-hop and end-to-end algorithm is AES-GCM. Other combinations of SRTP ciphers that support the procedures in this document can be added to the IANA registry. Is there an implication that the cipher used MUST be one that is in the registry? If so, it should say that. o the SSRC is the same for both the inner and out outer algorithms Extra word “out”. If the Media Distributor is to be able to modify header fields but not decrypt the payload, then it must have cryptographic key for the outer algorithm, but not the inner (end-to-end) algorithm. Missing article, “the cryptographic key”. — Section 4 — to verify the E2E integrity of the packet. Because you explicitly define “end-to-end” and generally use that term (24 times), I suggest being consistent and not using “E2E” (5 times) also. Alternatively, you could add “or E2E” to the definition in Section 2. (Similarly for “HBH”.) — Section 5.2 — Doesn’t bullet 4 contradict 3? If I’m allowed to change something back to its original value and drop it from the OHB, then I’m clearly changing information in the OHB. Maybe a little rewording would be useful. — Section 8 — These algorithm provide for authenticated encryption and will consume additional processing Should be “These algorithms”. — Section 10.1 — The SRTP transform parameters for each of these protection are: The word “protection” isn’t right. Do you want “protection profiles” here? From nobody Mon May 13 15:33:29 2019 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E15120086; Mon, 13 May 2019 15:33:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-perc-private-media-framework@ietf.org, Nils Ohlmeier , perc-chairs@ietf.org, nohlmeier@mozilla.com, perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <155778680114.23612.8118531689244716936.idtracker@ietfa.amsl.com> Date: Mon, 13 May 2019 15:33:21 -0700 Archived-At: Subject: [Perc] Adam Roach's Yes on draft-ietf-perc-private-media-framework-10: (with COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2019 22:33:22 -0000 Adam Roach has entered the following ballot position for draft-ietf-perc-private-media-framework-10: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm glad to see this work finally ready for publication. As I've already given several rounds of input on this document, I have only minor editorial comments. --------------------------------------------------------------------------- §2: > This may > include embedded user conferencing equipment or browsers on > computers, media gateways, MCUs, media recording device and more that > are in the trusted domain for a given deployment. Nit: "...media recording devices, and more..." pluralize _/ \_ add comma --------------------------------------------------------------------------- §2: > In the context of > WebRTC... Please add an informative citation to https://www.w3.org/TR/webrtc/ --------------------------------------------------------------------------- §2: > It operates according to the Selective > Forwarding Middlebox RTP topologies [RFC7667] per the constraints > defined by the PERC system, which includes, but not limited to, Nit: "...but is not limited to..." --------------------------------------------------------------------------- §6.1: Nit: The keys are described in the sections that follow in the order they are typically acquired, but listed in a different order in Figure 4. This confused me for several moments. Consider reordering Figure 4 to match the order in which the keys are described. --------------------------------------------------------------------------- From nobody Mon May 13 18:19:25 2019 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF441200FF; Mon, 13 May 2019 18:19:16 -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, 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 tsvfPRWQ6k6N; Mon, 13 May 2019 18:19:15 -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 CA5C912008C; Mon, 13 May 2019 18:19:11 -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=1557796749; bh=jXaLOcEv/LQq0wY26UfGhhbWCT8bIPwC82J0f77Ew8g=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=gcSLWdq/0CK7ORQbOF9X3iIL7WOKqQ+lerPPrivg5nSEXOEfzLMXVWJjVwBhHFa0b bURr/yyB7P95X0gTGHCJ259c2GVhKdznqq6mg0RcfSIjPVWcKuUUwL+GDV1mZQIT+J w63Gnqnnlv1xqaDILiqMXhyLxsFP0iuZDUJBSATA= From: "Paul E. Jones" To: "Adam Roach" , "The IESG" Cc: draft-ietf-perc-private-media-framework@ietf.org, "Nils Ohlmeier" , perc-chairs@ietf.org, nohlmeier@mozilla.com, perc@ietf.org Date: Tue, 14 May 2019 01:19:03 +0000 Message-Id: In-Reply-To: <155778680114.23612.8118531689244716936.idtracker@ietfa.amsl.com> References: <155778680114.23612.8118531689244716936.idtracker@ietfa.amsl.com> Reply-To: "Paul E. Jones" User-Agent: eM_Client/7.2.34711.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Perc] Adam Roach's Yes on draft-ietf-perc-private-media-framework-10: (with COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2019 01:19:17 -0000 Thanks, Adam. All good comments that I've made locally. The changes=20 will appear in the next revision. Note that section 6.5 also has keys in a different order. Since that=20 deals with multiple HBH keys, I'm not sure that it makes sense to=20 re-order the table, since I can't get a 1:1 mapping. However, I'm happy=20 to move anything around if you thinks it lends to readability. Paul ------ Original Message ------ From: "Adam Roach via Datatracker" To: "The IESG" Cc: draft-ietf-perc-private-media-framework@ietf.org; "Nils Ohlmeier"=20 ; perc-chairs@ietf.org; nohlmeier@mozilla.com;=20 perc@ietf.org Sent: 5/13/2019 6:33:21 PM Subject: Adam Roach's Yes on draft-ietf-perc-private-media-framework-10:=20 (with COMMENT) >Adam Roach has entered the following ballot position for >draft-ietf-perc-private-media-framework-10: Yes > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >I'm glad to see this work finally ready for publication. As I've already >given several rounds of input on this document, I have only minor >editorial comments. >--------------------------------------------------------------------------= - > >=C2=A72: > >> This may >> include embedded user conferencing equipment or browsers on >> computers, media gateways, MCUs, media recording device and more that >> are in the trusted domain for a given deployment. > >Nit: "...media recording devices, and more..." > pluralize _/ \_ add comma > > >--------------------------------------------------------------------------= - > >=C2=A72: > >> In the context of >> WebRTC... > >Please add an informative citation to https://www.w3.org/TR/webrtc/ > >--------------------------------------------------------------------------= - > > >=C2=A72: > >> It operates according to the Selective >> Forwarding Middlebox RTP topologies [RFC7667] per the constraints >> defined by the PERC system, which includes, but not limited to, > >Nit: "...but is not limited to..." > >--------------------------------------------------------------------------= - > >=C2=A76.1: > >Nit: The keys are described in the sections that follow in the order >they are typically acquired, but listed in a different order in Figure 4. >This confused me for several moments. Consider reordering Figure 4 to matc= h >the order in which the keys are described. > >--------------------------------------------------------------------------= - > > From nobody Mon May 13 21:57:17 2019 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B35A12009C; Mon, 13 May 2019 21:57:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-perc-private-media-framework@ietf.org, Nils Ohlmeier , perc-chairs@ietf.org, perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <155780983023.23741.290642209182221824.idtracker@ietfa.amsl.com> Date: Mon, 13 May 2019 21:57:10 -0700 Archived-At: Subject: [Perc] Barry Leiba's No Objection on draft-ietf-perc-private-media-framework-10: (with COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2019 04:57:10 -0000 Barry Leiba has entered the following ballot position for draft-ietf-perc-private-media-framework-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for a clear document. Just a bunch of editorial comments here: In the Abstract, it’s probably past the time to talk about what the solution *aims* to do, so, “The solution builds upon existing security mechanisms....” Similarly in the Introduction, “This document defines improved security so as to lower the barrier....” (Or just strike the sentence, as the first sentence of the next paragraph has it covered.) And the last sentence of the Introduction, “This document defines a framework for enhanced privacy....” In Section 2 you define “Trusted Endpoint”, but then also use “Endpoint” and “endpoint” through the document. Are these all meant to be the same thing (that is, all things called “endpoints” here are Trusted Endpoints)? If so, please capitalize “Endpoint” consistently, and say “Trusted Endpoint (or simply Endpoint)” in the definition. — Section 3.1.1 — The key exchange mechanisms specified in this framework prevents the Media Distributor Make it “prevent” to agree with “mechanisms”. or better than traditional conferencing (i.e. non-PERC) deployments. You need a comma after “i.e.”. Or better still, here and elsewhere in the document, just eliminate the Latin abbreviation and just say, “traditional conferencing (non-PERC) deployments.” — Section 4.1 — It’s not clear from the diagram or explanation, so please clarify for me: there one e2e key per endpoint, and every endpoint knows the key for all the other endpoints, yes? I think it would be worth saying this clearly and explicitly, either here (my preference, to set it up early) or in Section 4.5. — Section 4.5.2 — Endpoints MUST generate a new E2E encryption key whenever it receives a new EKT Key. Make it “An Endpoint MUST....” — Section 5 — I suggest avoiding the phrase “key requirements” to avoid confusion about the word “key”. Maybe say “critical requirements” or “important requirements” instead. — Section 5.2 — Similarly, the Key Distributor's certificate fingerprint can be conveyed to endpoint in a manner that can be authenticated This needs to be one of “an endpoint”, “the endpoint”, or “endpoints”. — Section 5.3 — The title should either be “Conference Identification” or “Conference’s Identification”. — Section 6.5 — Each endpoint generates its own E2E Key (SRTP master key), thus distinct per endpoint. Make it “thus there is a distinct E2E Key per endpoint.” Endpoints that receive media from a given transmitting endpoint gains knowledge Make it “gain knowledge”. — Section 8.2.1 — the Media Distributor can attempt to consume the receiving endpoints resources. Make it either “endpoint’s resources” (for one endpoint) or “endpoints’ resources” (for multiple endpoints). — Section 8.2.3 — However, due to fact that the Media Distributor is allowed Make it “due to the fact that”, or, better, “because”. From nobody Tue May 14 04:12:15 2019 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41239120074; Tue, 14 May 2019 04:12:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-perc-private-media-framework@ietf.org, Nils Ohlmeier , perc-chairs@ietf.org, nohlmeier@mozilla.com, perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <155783232725.24983.15618364117059610299.idtracker@ietfa.amsl.com> Date: Tue, 14 May 2019 04:12:07 -0700 Archived-At: Subject: [Perc] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-perc-private-media-framework-10=3A_=28with_COMMENT=29?= X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2019 11:12:07 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-perc-private-media-framework-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this well-written document. Regarding the security considerations, I would think that the Key Distributor is actually sometime like a central attack point, however, I don't think that is really discussed in the security considerations section. Would it make sense to add some more words there? From nobody Tue May 14 14:15:38 2019 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC63120128; Tue, 14 May 2019 14:15:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: draft-ietf-perc-private-media-framework@ietf.org, Nils Ohlmeier , perc-chairs@ietf.org, nohlmeier@mozilla.com, perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <155786852996.30194.6992264311523885594.idtracker@ietfa.amsl.com> Date: Tue, 14 May 2019 14:15:29 -0700 Archived-At: Subject: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2019 21:15:30 -0000 Magnus Westerlund has entered the following ballot position for draft-ietf-perc-private-media-framework-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Its is good to see that this document has continued to improve since I read the early versions. However, there are some one issues we do need to discuss if they should be better handled before this document is ready for publication. A significant security vunerability in PERC that should be made more explicit and is totally missing is the risks with compromised endpoints. Beyond the very evident thing that this endpoint can decrypt all media it receives there are far more sinister risk here. Namely the potential for injection of media that attempts to impersonate another endpoints media stream. Most of SRTP's cipher suits only use symmetric crypto functions, thus enabling anyone with the key to send a packet with any SSRC, and have that being accepted as that source. Where it is has no practical usage in point to point communication, in conferencing it becomes an issue. It allows the usage of media level replay or deep fakes to be used to create media streams that are injected into the media distributors using an SSRC of another endpoint. The mitiagations that are missing from this document. The fact that a media distributor that is not compromised or collaborating with the compromised endpoint could actually prevent such media injection by applying source filtering of SSRCs and drop all that aren't associated with the endpoint. The other potential mitigation is to introduce another cipher suit that uses a non symmetric integrity protection mechanism, such as TESLA to prevent this type of injection. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In addition I would appreciate if you really consider these issues, especially A and B. A. I think the relationship between the media distributors and the key distributor needs to be clarified either already in section 3 or in 4. The fact that the key distributor needs to know the full set or their group identity of the media distributors to prevent impostering media distributors. That need is not made clear early enough, only by the end of the security consideration section is is made clear that this is the fact. I think it should be stated explicitly early on. B. Similar the endpoints relation to the key distributor also needs to be clarified. Also, here diving into potential solutions in Section 5 without making clear why this very fundamental requirement is needed is far from optimal. Also here I think discussion in Section 3 or 4 would be good of their relationship. Especially as this is really relying on mechanism outside of the PERC framework. Thus, such requirements should be very explicit stated and motivated. C. Section 4.3: If there is a need to encrypt one or more RTP header extensions end- to-end, the endpoint derives an encryption key from the E2E SRTP master key to encrypt header extensions as per [RFC6904]. The Media Distributor is unable use the information contained in those header extensions encrypted with an E2E key. As RFC 6904 works on type of header extensions, all header extensions of that type need to be encrypted independent of sender, that could be made clearer. D. Section 4.5: o The E2E key that an endpoint uses to send SRTP media can either be set from DTLS or chosen by the endpoint. I think "set from DTLS" should be changed to make it clear that the DTLS is with the Key Distributor. E. Section 4.5.1: Wouldn't this sentence be clearer: Endpoints establish a DTLS-SRTP [RFC5764] association over the RTP session's media ports for the purposes of key information exchange with the Key Distributor. is worded like this: Endpoints establish a DTLS-SRTP [RFC5764] association over the RTP session with the media distributor and it's media ports for the purposes of key information exchange with the Key Distributor. From nobody Tue May 14 15:43:37 2019 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26D21201D8; Tue, 14 May 2019 15:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 EC74pd4LlQWr; Tue, 14 May 2019 15:43:26 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 6DEA11201AF; Tue, 14 May 2019 15:43:26 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x4EMhNhR077897 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 14 May 2019 17:43:24 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1557873806; bh=/7UQyhSKeQGnUBYc2bNvMjd5zstEOq8Tli+LCc9LdUQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=aYPOZ30w3l4PepKDeWIws+AsLWB4+ITaMbGAXpF+HWdzc6Qid3UiGqqygfTTcKk70 qDHrVBfHJG5Bi5gRFMXBmlMWS0vcev/8ag9sZvSm08kVxfawT55HeNQQLaUeib1Xv1 zPlAbgw4+Ty2+ccj0nfLC9AslG4dBJG4BIzN+8o0= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: "Paul E. Jones" , The IESG Cc: nohlmeier@mozilla.com, perc-chairs@ietf.org, perc@ietf.org, draft-ietf-perc-private-media-framework@ietf.org References: <155778680114.23612.8118531689244716936.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <92f37be3-f48c-dbf5-bb3c-75a4c6660664@nostrum.com> Date: Tue, 14 May 2019 17:43:17 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D49FCB0D0CE11D27879E70FF" Content-Language: en-US Archived-At: Subject: Re: [Perc] Adam Roach's Yes on draft-ietf-perc-private-media-framework-10: (with COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2019 22:43:28 -0000 This is a multi-part message in MIME format. --------------D49FCB0D0CE11D27879E70FF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/13/19 8:19 PM, Paul E. Jones wrote: > Thanks, Adam.  All good comments that I've made locally.  The changes > will appear in the next revision. Thanks! > > Note that section 6.5 also has keys in a different order.  Since that > deals with multiple HBH keys, I'm not sure that it makes sense to > re-order the table, since I can't get a 1:1 mapping. However, I'm > happy to move anything around if you thinks it lends to readability. Sure. The problem here is that the document looks like this: > The keysare described in the order in which they would typically be acquired. > > The various keys used in PERC are shown in Figure 4 below. > > +-----------+----------------------------------------------------+ > | Key |Description | > +-----------+----------------------------------------------------+ > | KEK | Key shared by all endpoints and used to encrypt | > | (EKT Key) | each endpoint's E2E SRTP master key so receiving | > | | endpoints can decrypt media. | > +-----------+----------------------------------------------------+ > | HBH Key | SRTP master key used to encrypt media hop-by-hop. | > +-----------+----------------------------------------------------+ > | E2E Key | SRTP master key used to encrypt media end-to-end. | > +-----------+----------------------------------------------------+ So you have the statement "...are described in the order..." *immediately* followed by a table with a header labeled "Description" -- and that table is *not* in the order specified. So it's not as much a matter of making all of the keys always appearing in the same order, as much as not having this confusing juxtaposition. /a --------------D49FCB0D0CE11D27879E70FF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/13/19 8:19 PM, Paul E. Jones wrote:
Thanks, Adam.  All good comments that I've made locally.  The changes will appear in the next revision.


Thanks!



Note that section 6.5 also has keys in a different order.  Since that deals with multiple HBH keys, I'm not sure that it makes sense to re-order the table, since I can't get a 1:1 mapping.  However, I'm happy to move anything around if you thinks it lends to readability.


Sure. The problem here is that the document looks like this:

   The keys are described in the order in which they would typically be
   acquired.

   The various keys used in PERC are shown in Figure 4 below.

    +-----------+----------------------------------------------------+
    | Key       | Description                                        |
    +-----------+----------------------------------------------------+
    | KEK       | Key shared by all endpoints and used to encrypt    |
    | (EKT Key) | each endpoint's E2E SRTP master key so receiving   |
    |           | endpoints can decrypt media.                       |
    +-----------+----------------------------------------------------+
    | HBH Key   | SRTP master key used to encrypt media hop-by-hop.  |
    +-----------+----------------------------------------------------+
    | E2E Key   | SRTP master key used to encrypt media end-to-end.  |
    +-----------+----------------------------------------------------+


So you have the statement "...are described in the order..." *immediately* followed by a table with a header labeled "Description" -- and that table is *not* in the order specified.

So it's not as much a matter of making all of the keys always appearing in the same order, as much as not having this confusing juxtaposition.

/a

--------------D49FCB0D0CE11D27879E70FF-- From nobody Tue May 14 16:53:23 2019 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F0D1200B9; Tue, 14 May 2019 16:53:14 -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 JkcSt0Yg8Amb; Tue, 14 May 2019 16:53:10 -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 68992120099; Tue, 14 May 2019 16:53: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=1557877987; bh=Ith+RrWSWgm/iwUjIeqEgiieucPX0O7LbmvpdxaUptg=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=jY0ott+vYhhzbn7z8vwOxYjEF+ljCbc/LDz9r/SiX06VCPpiLeG+Sphuc0UVIYZBQ C0uO4lPXASUUYUjP46+HN0qlj6NMPU6IXd1MjNrpFzfnLrGBZSZUXpOsJuRdIy5lyI RmzYOpWdt/0yDr4E8tE7rATBa7Vs3P+ke6Mbxdrs= From: "Paul E. Jones" To: =?utf-8?q?Mirja=20K=c3=bchlewind?= , "The IESG" , "Vincent Roca" Cc: nohlmeier@mozilla.com, perc-chairs@ietf.org, perc@ietf.org, draft-ietf-perc-private-media-framework@ietf.org Date: Tue, 14 May 2019 23:53:01 +0000 Message-Id: In-Reply-To: <155783232725.24983.15618364117059610299.idtracker@ietfa.amsl.com> References: <155783232725.24983.15618364117059610299.idtracker@ietfa.amsl.com> Reply-To: "Paul E. Jones" User-Agent: eM_Client/7.2.34711.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB658C011C-613E-4824-9638-C2AB7BEB34D8" Archived-At: Subject: Re: [Perc] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-perc-private-media-framework-10=3A_=28with_COMMENT=29?= X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2019 23:53:14 -0000 --------=_MB658C011C-613E-4824-9638-C2AB7BEB34D8 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mirja, Yeah, that is valid point. We mentioned a time or two in the document=20 how important it is to secure the Key Distributor, but explicit text=20 that discusses that further might be appropriate here. I've copied=20 Vincent for his input, too, since he did have comments on other parts of=20 the Security Considerations section. I made a first draft of a new section. I pasted it below. Please let=20 me know what you think. Thanks, Paul 8.3. Key Distributor Attacks As stated in Section 3.2.2, the Key Distributor needs to be secured since exploiting the Key Server can allow an adversary to gain access to the keying material for one or more conferences. Having access to that keying material would then allow the adversary to decrypt media sent from any endpoint in the conference. As a first line of defense, the Key Distributor authenticates every security association, both associations with endpoints and Media Distributors. The Key Distributor knows which entities are authorized to have access to which keys and inspection of certificates will substantially reduce the risk of providing keys to an adversary. Both physical and network access to the Key Distributor should be severely restricted. This may be more difficult to achieve when the Key Distributor is embedded within and endpoint, for example. Nonetheless, consideration should be given to shielding the Key Distributor from unauthorized access or any access that is not strictly necessary for the support of an ongoing conference. Consideration should be given to whether access to the keying material will be needed beyond the conclusion of a conference. If not needed, the Key Distributor's policy should be to destroy the keying material once the conference concludes or when keying material changes during the course of the conference. If keying material is needed beyond the lifetime of the conference, further consideration should be given to protecting keying material from future exposure. While it might be obvious, it is worth stating to avoid any doubt that if an adversary were to record the media packets transmitted during a conference and then gain unauthorized access to the keying material left unsecured on the Key Distributor even years later, the adversary could decrypt the content every packet transmitted during the conference. ------ Original Message ------ From: "Mirja K=C3=BChlewind via Datatracker" To: "The IESG" Cc: nohlmeier@mozilla.com; perc-chairs@ietf.org; perc@ietf.org;=20 draft-ietf-perc-private-media-framework@ietf.org Sent: 5/14/2019 7:12:07 AM Subject: [Perc] Mirja K=C3=BChlewind's No Objection on=20 draft-ietf-perc-private-media-framework-10: (with COMMENT) >Mirja K=C3=BChlewind has entered the following ballot position for >draft-ietf-perc-private-media-framework-10: No Objection > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >Thanks for this well-written document. > >Regarding the security considerations, I would think that the Key Distribu= tor >is actually sometime like a central attack point, however, I don't think t= hat >is really discussed in the security considerations section. Would it make= sense >to add some more words there? > > >_______________________________________________ >Perc mailing list >Perc@ietf.org >https://www.ietf.org/mailman/listinfo/perc --------=_MB658C011C-613E-4824-9638-C2AB7BEB34D8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Mirja,

Yeah, that is valid point= . =C2=A0We mentioned a time or two in the document how important it is to s= ecure the Key Distributor, but explicit text that discusses that further mi= ght be appropriate here. =C2=A0I've copied Vincent for his input, too, sinc= e he did have comments on other parts of the Security Considerations sectio= n.

I made a first draft of a new section. =C2=A0= I pasted it below. =C2=A0Please let me know what you think.

Thanks,
Paul

8.3. Key Distributor Attacks

=C2=A0 =C2=A0As stated in Section 3.2.2, the Key Dist= ributor needs to be secured
=C2=A0 =C2=A0since exploiting the Key Server can allow an adversary = to gain access
=C2= =A0 =C2=A0to the keying material for one or more conferences. Having acces= s to
=C2=A0 =C2=A0th= at keying material would then allow the adversary to decrypt media
=C2=A0 =C2=A0sent from any e= ndpoint in the conference.

=C2=A0 = =C2=A0As a first line of defense, the Key Distributor authenticates every<= /font>
=C2=A0 =C2=A0securit= y association, both associations with endpoints and Media
= =C2=A0 =C2=A0Distributors. The Key D= istributor knows which entities are
=C2=A0 =C2=A0authorized to have access to which keys and in= spection of
=C2=A0 = =C2=A0certificates will substantially reduce the risk of providing keys to=
=C2=A0 =C2=A0an adv= ersary.

=C2=A0 =C2=A0Both physica= l and network access to the Key Distributor should be
=C2=A0 =C2=A0severely restricted. This m= ay be more difficult to achieve when the
=C2=A0 =C2=A0Key Distributor is embedded within and en= dpoint, for example.
=C2=A0 =C2=A0Nonetheless, consideration should be given to shielding the K= ey
=C2=A0 =C2=A0Dist= ributor from unauthorized access or any access that is not
=C2=A0 =C2=A0strictly necessary for= the support of an ongoing conference.

=C2=A0 =C2=A0Consideration should be given to whether access to the= keying
=C2=A0 =C2=A0= material will be needed beyond the conclusion of a conference. If
=C2=A0 =C2=A0not needed, the = Key Distributor's policy should be to destroy the
=C2=A0 =C2=A0keying material once the confer= ence concludes or when keying material
=C2=A0 =C2=A0changes during the course of the conference= . If keying material is
=C2=A0 =C2=A0needed beyond the lifetime of the conference, further c= onsideration
=C2=A0 = =C2=A0should be given to protecting keying material from future exposure.<= /font>
=C2=A0 =C2=A0While i= t might be obvious, it is worth stating to avoid any doubt
=C2=A0 =C2=A0that if an adversary we= re to record the media packets transmitted
=C2=A0 =C2=A0during a conference and then gain unaut= horized access to the keying
=C2=A0 =C2=A0material left unsecured on the Key Distributor even y= ears later, the
=C2= =A0 =C2=A0adversary could decrypt the content every packet transmitted duri= ng
=C2=A0 =C2=A0the= conference.


------ Original Message ------
From: "Mirja K=C3=BChlewind via Datatracker" <noreply@ietf.org><= /div>
To: "The IESG" <iesg@ietf.org>
Cc: nohlmeier@mozilla.com; perc-chairs@ietf.org; perc@ietf.org; draft-= ietf-perc-private-media-framework@ietf.org
Sent: 5/14/2019 7:12:07 AM
Subject: [Perc] Mirja K=C3=BChlewind's No Objection on draft-ietf-perc= -private-media-framework-10: (with COMMENT)

Mirja K=C3=BChlewind has entered the following ba= llot position for
draft-ietf-perc-private-media-framework-10: No Ob= jection
=C2=A0
When responding, please keep the subject line int= act and reply to all
email addresses included in the To and CC lines.= (Feel free to cut this
introductory paragraph, however.)
=C2=A0
=C2=A0
Please refer to https://www.ietf.org/iesg/stateme= nt/discuss-criteria.html
for more information about IESG DISCUSS and COMME= NT positions.
=C2=A0
=C2=A0
The document, along with other ballot positions,= can be found here:
https://datatracker.ietf.org/doc/draft-ietf-perc-= private-media-framework/
=C2=A0
=C2=A0
=C2=A0
-------------------------------------------------= ---------------------
COMMENT:
-------------------------------------------------= ---------------------
=C2=A0
Thanks for this well-written document.
=C2=A0
Regarding the security considerations, I would th= ink that the Key Distributor
is actually sometime like a central attack point, = however, I don't think that
is really discussed in the security consideration= s section. Would it make sense
to add some more words there?
=C2=A0
=C2=A0
_______________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc
--------=_MB658C011C-613E-4824-9638-C2AB7BEB34D8-- From nobody Tue May 14 19:45:12 2019 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11BB1201D0; Tue, 14 May 2019 19:45:06 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 nbPh5AXBOXaH; Tue, 14 May 2019 19:45:05 -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 C53C912003E; Tue, 14 May 2019 19:45:04 -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=1557888300; bh=S2lZlG6ASiYnjpQbiwWXyCLrGlVwk9PapIOrKcLzYbo=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=t/lQ6t8eOMhuDv5nMjKMtcOB/o8l0x4EBxsA2SjjAfI9w+CvpppXMcbany2+Ea7ep S1ic/QlR8mCZ0vIEf6Gke4rZSrBxKDMtky+iU4ZXVMIr8uwxXCHefyMlP3W9vkk4We R+kl7TXoRUyQtfcjoPu2jTxMO53aW2e1tZVY5o2E= From: "Paul E. Jones" To: "Barry Leiba" , "The IESG" Cc: "Nils Ohlmeier" , perc-chairs@ietf.org, perc@ietf.org, draft-ietf-perc-private-media-framework@ietf.org Date: Wed, 15 May 2019 02:44:56 +0000 Message-Id: In-Reply-To: <155780983023.23741.290642209182221824.idtracker@ietfa.amsl.com> References: <155780983023.23741.290642209182221824.idtracker@ietfa.amsl.com> Reply-To: "Paul E. Jones" User-Agent: eM_Client/7.2.34711.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBD1DECFC2-9E12-4D7A-BFA7-9D58AC359074" Archived-At: Subject: Re: [Perc] Barry Leiba's No Objection on draft-ietf-perc-private-media-framework-10: (with COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2019 02:45:07 -0000 --------=_MBD1DECFC2-9E12-4D7A-BFA7-9D58AC359074 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Barry, Thanks for the comments. I accepted all of the suggestions and answered=20 the one question below (while also making changes to the text to make=20 this clear ... or attempt to do so). >=E2=80=94 Section 4.1 =E2=80=94 >It=E2=80=99s not clear from the diagram or explanation, so please clarify= for me: there >one e2e key per endpoint, and every endpoint knows the key for all the oth= er >endpoints, yes? I think it would be worth saying this clearly and explicit= ly, >either here (my preference, to set it up early) or in Section 4.5. There is one or more unique E2E keys per Endpoint, generally one per=20 media flow (though the same E2E key could be used for all flows given=20 the SSRCs are different for each). For each flow, these keys are=20 conveyed by the sender in the full EKT Field as per the EKT Diet=20 document. I've added some text and hopefully that will appear in the next=20 revision. I also felt like we needed to augment 4.5 with stating (just=20 for completeness) that normal DTLS-SRTP is used to obtain HBH keys=20 between Media Distributors. So I added that, too. Paul --------=_MBD1DECFC2-9E12-4D7A-BFA7-9D58AC359074 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Barry,

Thanks for the comments. = =C2=A0I accepted all of the suggestions and answered the one question belo= w (while also making changes to the text to make this clear ... or attempt= to do so).


=E2= =80=94 Section 4.1 =E2=80=94
It=E2=80=99s not clear from the diagram or explan= ation, so please clarify for me: there
one e2e key per endpoint, and every endpoint know= s the key for all the other
endpoints, yes? I think it would be worth saying= this clearly and explicitly,
either here (my preference, to set it up early) o= r in Section 4.5.

There is one or more unique E2E keys per End= point, generally one per media flow (though the same E2E key could be used= for all flows given the SSRCs are different for each). For each flow, thes= e keys are conveyed by the sender in the full EKT Field as per the EKT Diet = document.

I've added some text and hopefully that will appear in the next= revision. I also felt like we needed to augment 4.5 with stating (just for = completeness) that normal DTLS-SRTP is used to obtain HBH keys between Med= ia Distributors. So I added that, too.
<= br />
Paul

--------=_MBD1DECFC2-9E12-4D7A-BFA7-9D58AC359074-- From nobody Wed May 15 06:12:11 2019 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F471200FD; Wed, 15 May 2019 06:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 aK1B18Ji2JnS; Wed, 15 May 2019 06:12:08 -0700 (PDT) Received: from mail-it1-f170.google.com (mail-it1-f170.google.com [209.85.166.170]) (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 CC7511200F7; Wed, 15 May 2019 06:12:07 -0700 (PDT) Received: by mail-it1-f170.google.com with SMTP id s3so4720878itk.1; Wed, 15 May 2019 06:12:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=8kxFRZMrtIOUpxb8bEIxoOT+kE3piP/NwY0Wffs8/B4=; b=MLVHgVJekD3Xp2gMq5mU1gKIzQMDQSR/FxZU5mL2SHuL3bRHSmMlPXXprFGWeG/1K9 6tVCk+tROvyu/+kxmD6xS5GdIbflQkjm/HMetNYrr3lev20aKOnCsHpYDVO5ggsp/U0w dEI2lcu+HIjyy8X1S77h8sMd3Mr5o3kDhSo8ktijgGwOMRORyR9V26yLQI5J0YxOmKN3 /fA60Yvam8PvqRkKHB+TfmmbxpgnppiPuWLM1k1ES0jNpEez1GtvjUzlKv6/1hGBqvwM HQg1IJK8ATk4/lwGRQswaHlW8OO54eLJHIbcTEcafu8sRbKl30qYuKVpGr6HYzlJoFrr h0zw== X-Gm-Message-State: APjAAAUG1kmaCEsoGZTd94fAXMYuIdolZ2jlCCIvfvkDWEH7HsaTqP25 w4zjjqwroLVBAAjgNuRpaxLVur2EoEJJsfU6J5Y= X-Google-Smtp-Source: APXvYqwcvCfmpqqtv4kDHfBYEjRn6emQCSJlFG7lZiZuHrmexf5Ws9ojYpQkE8/BMekZ1vNMkJ16D5y/9SqEh8CG764= X-Received: by 2002:a24:56d1:: with SMTP id o200mr8731082itb.93.1557925926756; Wed, 15 May 2019 06:12:06 -0700 (PDT) MIME-Version: 1.0 References: <155780983023.23741.290642209182221824.idtracker@ietfa.amsl.com> In-Reply-To: From: Barry Leiba Date: Wed, 15 May 2019 09:11:55 -0400 Message-ID: To: "Paul E. Jones" Cc: The IESG , Nils Ohlmeier , perc-chairs@ietf.org, perc@ietf.org, draft-ietf-perc-private-media-framework@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Perc] Barry Leiba's No Objection on draft-ietf-perc-private-media-framework-10: (with COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2019 13:12:09 -0000 Thanks, Paul! Barry On Tue, May 14, 2019 at 10:45 PM Paul E. Jones wrot= e: > > Barry, > > Thanks for the comments. I accepted all of the suggestions and answered = the one question below (while also making changes to the text to make this = clear ... or attempt to do so). > > > =E2=80=94 Section 4.1 =E2=80=94 > It=E2=80=99s not clear from the diagram or explanation, so please clarify= for me: there > one e2e key per endpoint, and every endpoint knows the key for all the ot= her > endpoints, yes? I think it would be worth saying this clearly and explici= tly, > either here (my preference, to set it up early) or in Section 4.5. > > > There is one or more unique E2E keys per Endpoint, generally one per medi= a flow (though the same E2E key could be used for all flows given the SSRCs= are different for each). For each flow, these keys are conveyed by the sen= der in the full EKT Field as per the EKT Diet document. > > I've added some text and hopefully that will appear in the next revision.= I also felt like we needed to augment 4.5 with stating (just for completen= ess) that normal DTLS-SRTP is used to obtain HBH keys between Media Distrib= utors. So I added that, too. > > Paul > From nobody Wed May 15 10:14:38 2019 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1370120345; Wed, 15 May 2019 10:14:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-perc-double@ietf.org, Suhas Nandakumar , perc-chairs@ietf.org, suhasietf@gmail.com, perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <155794047384.17521.14432623434370971455.idtracker@ietfa.amsl.com> Date: Wed, 15 May 2019 10:14:33 -0700 Archived-At: Subject: [Perc] Alissa Cooper's Yes on draft-ietf-perc-double-10: (with COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2019 17:14:34 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-perc-double-10: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-perc-double/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Glad to see this work progressing. Section 2: Why not use or reference the definitions of terms in draft-ietf-perc-private-media-framework rather than defining them differently here? From nobody Wed May 15 10:15:16 2019 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEE612035B; Wed, 15 May 2019 10:15:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-perc-private-media-framework@ietf.org, Nils Ohlmeier , perc-chairs@ietf.org, nohlmeier@mozilla.com, perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <155794051417.17533.9519473589612644706.idtracker@ietfa.amsl.com> Date: Wed, 15 May 2019 10:15:14 -0700 Archived-At: Subject: [Perc] Alissa Cooper's Yes on draft-ietf-perc-private-media-framework-10: (with COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2019 17:15:14 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-perc-private-media-framework-10: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Glad to see this work progressing. Section 2: Please use the RFC 8174 boilerplate. From nobody Wed May 15 10:17:15 2019 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0981B1203A0; Wed, 15 May 2019 10:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=HQtpogfe; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pPfNLJTh 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 23EL--E4djrx; Wed, 15 May 2019 10:16:48 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39D3A120384; Wed, 15 May 2019 10:16:45 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id CDFCD390; Wed, 15 May 2019 13:16:43 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 15 May 2019 13:16:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm3; bh=Y6+pGdIk8TJi6AQi9hnms4+ YkxIMA+oes8rBRTJIkN0=; b=HQtpogfeMR1ZQB2QwkF2sn0ifViVQkU1MYvYXvA HHLF6Vzs8eglLeE023Cpkl8MPtZJ5C796P0ya+xZiuAWiCkXVBDmY63PsX8JHNsa MjTYp2bqsz+SQ7LB9ecKTA3BpMY7zBL8T5XDiBcd2fU0lcxJvOCqsrRluU0PuGhb jL9SFBM0wflCbxXcvK3iT4Hb2QEA0SZYayHnV5G8rYxfG2hZ9oY3s6O0r0YkMd0Q 35Qbdum8YaWRXwsZlsIt4qVZvrZEL6LfFblfFD5NclySDpXJ/EonPayFX26oIItO TIGtUbvCPK+a/3lgnuVYvDGYwChydBUfFr1KgVmRzCAJV9Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Y6+pGd Ik8TJi6AQi9hnms4+YkxIMA+oes8rBRTJIkN0=; b=pPfNLJThwGzGBTHljGoGai ozpK9pAvBfV4FwCQFe1zBU2m/8USRGRtqQ9/zxb9O39eFYMko9WMETF68jJQzCSl S/uCTZxEaf5qaURVE15p70u0h0Sg9Gv9308muJAd80cYJo9kwlXRUeaktuXan/yW /mFs8hY51mJrx7hZdTc/2ZlvxBUbcYMFOe6oIzZEOOW40xNTyL/BqF9bY9XHeNId pOkEtH5s9qJm1cwIhM+8+MahtCnoAvK0InP+D0FVn/1LWd7nA9qG8BdKXbGyAyU0 K1attLoYy/E0SPD8kds5F+ehGVesrTuE+UiN0iEnzBmYotj3je9OlFhRuOii0/PQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrleekgddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffktgggufffjgfvfhfosegrtdhmrehhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehgihhthhhusgdrtghomhdpihgvthhfrdhorhhgpdhirghnrgdrohhrghenucfkphep udejfedrfeekrdduudejrdekleenucfrrghrrghmpehmrghilhhfrhhomheprghlihhssh grsegtohhophgvrhifrdhinhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.89]) by mail.messagingengine.com (Postfix) with ESMTPA id 3D9C78005B; Wed, 15 May 2019 13:16:42 -0400 (EDT) From: Alissa Cooper Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A54CC247-1386-421D-B04E-673F5A4EB95E" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 15 May 2019 13:16:40 -0400 In-Reply-To: Cc: IETF Gen-ART , draft-ietf-perc-double.all@ietf.org, perc@ietf.org, IETF discussion list To: Richard Barnes , Russ Housley References: <154002385712.13693.18098361756799542976@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Perc] Genart last call review of draft-ietf-perc-double-10 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2019 17:16:52 -0000 --Apple-Mail=_A54CC247-1386-421D-B04E-673F5A4EB95E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Russ, thanks for your review. Richard, thanks for your response. I = entered a Yes ballot. The IANA registration looks fine to me =E2=80=94 = we did the early registration with just the same fields as specified in = the document. Alissa > On Dec 19, 2018, at 11:46 AM, Richard Barnes wrote: >=20 > Thanks for the review, Russ. Comments below (nothing major); pull = request here for your review: >=20 > https://github.com/ietf/perc-wg/pull/163 = >=20 > On Sat, Oct 20, 2018 at 4:24 AM Russ Housley > wrote: > Reviewer: Russ Housley > Review result: Almost Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at > >. >=20 > Document: draft-ietf-perc-double-10 > Reviewer: Russ Housley > Review Date: 2018-10-20 > IETF LC End Date: 2018-11-01=20 > IESG Telechat date: unknown >=20 > Summary: Almost Ready >=20 >=20 > Major Concerns: >=20 > Section 10: Doesn't the IANA registry needs to specify the PRF to be > used with the ciphersuite as well? >=20 > I don't think so. I don't see a slot in the relevant registry for = that, and the tabular summary in the IANA considerations section is = really just a courtesy. >=20 > = https://www.iana.org/assignments/srtp-protection/srtp-protection.xhtml#srt= p-protection-1 = > =20 >=20 > Minor Concerns: >=20 > Section 3: It would be useful to explain the Master Key before the > reader gets to Section 3.1. >=20 > Note that the "master key" concept comes from SRTP. I've added a bit = of text to clarify. >=20 > =20 > Section 3.1: It is unclear what assistance is provided by the > additional level of indirection: >=20 > PRF_double_n(k_master,x) =3D PRF_inner_(n/2)(k_master,x) || > PRF_outer_(n/2)(k_master,x) >=20 > PRF_inner_n(k_master,x) =3D PRF_n(inner(k_master),x) > PRF_outer_n(k_master,x) =3D PRF_n(outer(k_master),x) >=20 > It could just say: >=20 > PRF_double_n(k_master,x) =3D PRF_(n/2)(inner(k_master),x) || > PRF_(n/2)(outer(k_master),x) >=20 > =F0=9F=91=8D =20 >=20 > Not sure what I was thinking. >=20 > =20 > Section 4: I suggest: >=20 > If the marker bit is not present, then B MUST be set to zero. >=20 > =F0=9F=91=8D > =20 > Section 5, 1st paragraph: and endpoint cannot verify confidentiality. >=20 > Well, it can verify that the packet was encrypted with a key known = only to the endpoints. But OK. > =20 >=20 > Nits: >=20 > The document uses "encryption" and "confidentiality" interchanagably. > Encryption is a mechanism or algorithm. Confidentiality is a security > service. While I do not think that the reader will be confused by the > current wording, it would be better to use the terms properly. In > addition, it is misleading to say: >=20 > ... the receiving endpoint that can encrypt and authenticate .... >=20 > because the sending endpoint encrypts, and the recieving endpoints > decrypts. Also, the receiving endpoints check the authentication tag. >=20 > That's actually just some bad grammar. Reworded. >=20 > =20 > Abstract: s/authenticated encryption with associated data/ > /authenticated encryption with associated data (AEAD)/ >=20 > Abstract: s/scheme/algorithm/ >=20 > Section 5.2: s/GCM/AES-GCM/ >=20 > Section 7: s/HBH/hop-by-hop/ >=20 > Section 7: s/E2E/end-to-end/ >=20 > Section 7.1: s/HBH/hop-by-hop/ >=20 > Section 7.2: The text is redundant. I suggest "etc" be dropped from > "such as SSRC, SEQ, CSRC, etc" >=20 > Section 7.2: s/non primary/non-primary/ >=20 > Section 7.3: s/HBH/hop-by-hop/ >=20 > Implemented all of the above... > =20 > Appendix A: s/HBH/hop-by-hop/ >=20 > Appendix A: s/E2E/end-to-end/ >=20 > ... but I'm going to leave these last two as-is, for brevity.=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc --Apple-Mail=_A54CC247-1386-421D-B04E-673F5A4EB95E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Russ,= thanks for your review. Richard, thanks for your response. I entered a = Yes ballot. The IANA registration looks fine to me =E2=80=94 we did the = early registration with just the same fields as specified in the = document.

Alissa

On Dec 19, 2018, at 11:46 AM, Richard Barnes <rlb@ipv.sx> wrote:

Thanks for the review, Russ.  Comments below (nothing = major); pull request here for your review:

https://github.com/ietf/perc-wg/pull/163

On Sat, Oct 20, 2018 at 4:24 AM Russ Housley = <housley@vigilsec.com> wrote:
Reviewer: Russ Housley
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments = just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>= .

Document: draft-ietf-perc-double-10
Reviewer: Russ Housley
Review Date: 2018-10-20
IETF LC End Date: 2018-11-01
IESG Telechat date: unknown

Summary: Almost Ready


Major Concerns:

Section 10: Doesn't the IANA registry needs to specify the PRF to be
used with the ciphersuite as well?

I don't think so.  = I don't see a slot in the relevant registry for that, and the tabular = summary in the IANA considerations section is really just a courtesy.

https://www.iana.org/assignments/srtp-protection/srtp-protectio= n.xhtml#srtp-protection-1
 

Minor Concerns:

Section 3: It would be useful to explain the Master Key before the
reader gets to Section 3.1.
Note that the "master key" concept = comes from SRTP.  I've added a bit of text to clarify.

 
Section 3.1: It is unclear what assistance is provided by the
additional level of indirection:

         PRF_double_n(k_master,x) =3D = PRF_inner_(n/2)(k_master,x) ||
                    =                 = PRF_outer_(n/2)(k_master,x)

         PRF_inner_n(k_master,x)  =3D = PRF_n(inner(k_master),x)
         PRF_outer_n(k_master,x)  =3D = PRF_n(outer(k_master),x)

It could just say:

         PRF_double_n(k_master,x) =3D = PRF_(n/2)(inner(k_master),x) ||
                    =                 = PRF_(n/2)(outer(k_master),x)

=F0=9F=91=8D 

Not = sure what I was thinking.

 
Section 4: I suggest:

        If the marker bit is not present, then B = MUST be set to zero.

=F0=9F=91=8D
 
Section 5, 1st paragraph: and endpoint cannot verify confidentiality.

Well, it can verify that the packet was encrypted with a key = known only to the endpoints.  But OK.
 

Nits:

The document uses "encryption" and "confidentiality" interchanagably.
Encryption is a mechanism or algorithm.  Confidentiality is a = security
service.  While I do not think that the reader will be confused by = the
current wording, it would be better to use the terms properly.  = In
addition, it is misleading to say:

   ... the receiving endpoint that can encrypt and = authenticate ....

because the sending endpoint encrypts, and the recieving endpoints
decrypts.  Also, the receiving endpoints check the authentication = tag.

That's actually just some bad grammar.  Reworded.

 
Abstract: s/authenticated encryption with associated data/
           /authenticated encryption with = associated data (AEAD)/

Abstract: s/scheme/algorithm/

Section 5.2: s/GCM/AES-GCM/

Section 7: s/HBH/hop-by-hop/

Section 7: s/E2E/end-to-end/

Section 7.1: s/HBH/hop-by-hop/

Section 7.2: The text is redundant.  I suggest "etc" be dropped = from
"such as SSRC, SEQ, CSRC, etc"

Section 7.2: s/non primary/non-primary/

Section 7.3: s/HBH/hop-by-hop/

Implemented all of the = above...
 
Appendix A: s/HBH/hop-by-hop/

Appendix A: s/E2E/end-to-end/

... but I'm going to = leave these last two as-is, for brevity.
_______________________________________________
Perc = mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc

= --Apple-Mail=_A54CC247-1386-421D-B04E-673F5A4EB95E-- From nobody Wed May 15 10:17:35 2019 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A0D1203D9; Wed, 15 May 2019 10:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=nVpI9Vak; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=2lFdI4oS 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 hn7w77HXmBrU; Wed, 15 May 2019 10:17:26 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F1F11203F3; Wed, 15 May 2019 10:17:25 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 9EF142E0; Wed, 15 May 2019 13:17:23 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 15 May 2019 13:17:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=K CRzhd9SBbN+05BkzGfUQfenTEH7nUHt56tIRoOUXcE=; b=nVpI9VakAWTvuMmcY WhiHzPNxInfX9nMSUuBzL2aKGF7IiSUZZE4LthS6WLIn819ADakBZR9trkgdP0UJ fwmgqt96rOM3f9nL+yx6LXb3L4wxthL7kVfK3neRDFKvRQdSKNmTuyzCVLThfgi1 UNz5OeYh8pCVESB1cHSUJPue8rFmqqzxymLTp5kRoR4pbnLJcKn6lSU6iPK+f5Jg c/F28Bmerk3WkXxlXmeK6Hc2JvU2GuPtKzKUC9AZmJPsirxS9kWjKb6NLUJGp0e/ yAyOOXwlgjVmtLnfdpFlDVRZxdxZRFFIvZlPN5kS+0ovmERgEP1BRuK/rPLVGvFX CksZA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=KCRzhd9SBbN+05BkzGfUQfenTEH7nUHt56tIRoOUX cE=; b=2lFdI4oS9nnWA5GspW0BgmlwybaT8CbINJt7bp9/W4R4b9DEB2EVtmuMN aDboLjoZleuqR2bXvlLLfc93oRuFpKgzE7OxBP3HMtSLVdk1w3cMlz67yIUb5CUU ZXVVfXI5X60NAoa0V2Q2sZxWJ/i/strSMSr6Jc6m9s87jzJij27pw6WLJFWULaAv JQvPg0jkX/DxeDrEsDO8V0n/1Y61O9lmhpstny0Nt4O40FGuL012XD4tmByLWF4s 3oQWWykz3Fiqm9NsMwer59FzUVI2+wMNYByLI+Apnv8MkEECnSfl6RuemUf3ucVd 1MuFzN0c+0stxLxwRIJsuTsGorynQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrleekgddutdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrkeelnecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsth gvrhfuihiivgeptd X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.89]) by mail.messagingengine.com (Postfix) with ESMTPA id 97C4180059; Wed, 15 May 2019 13:17:22 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <155173521133.5237.13570820791941689806@ietfa.amsl.com> Date: Wed, 15 May 2019 13:17:21 -0400 Cc: gen-art@ietf.org, ietf@ietf.org, draft-ietf-perc-private-media-framework.all@ietf.org, perc@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <155173521133.5237.13570820791941689806@ietfa.amsl.com> To: Linda Dunbar X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Perc] [Gen-art] Genart telechat review of draft-ietf-perc-private-media-framework-09 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2019 17:17:33 -0000 Linda, thank you for your reviews of this document. I entered a Yes = ballot. Alissa > On Mar 4, 2019, at 4:33 PM, Linda Dunbar = wrote: >=20 > Reviewer: Linda Dunbar > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-perc-private-media-framework-?? > Reviewer: Linda Dunbar > Review Date: 2019-03-04 > IETF LC End Date: 2019-02-13 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: >=20 > This is my second time reviewing this draft. The authors have = addressed all my > comments from the last review cycle. >=20 > Major issues: None >=20 > Minor issues: None >=20 > Nits/editorial comments: None >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed May 15 12:19:40 2019 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F401207DE; Wed, 15 May 2019 12:19:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-perc-double@ietf.org, Suhas Nandakumar , perc-chairs@ietf.org, suhasietf@gmail.com, perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <155794795922.30479.4871063178431245935.idtracker@ietfa.amsl.com> Date: Wed, 15 May 2019 12:19:19 -0700 Archived-At: Subject: [Perc] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-perc-double-10=3A_=28with_COMMENT=29?= X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2019 19:19:23 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-perc-double-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-perc-double/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the work everyone has put into this document. I have one comment. I like the fact that this document allows for multiple 'media distributors' on the path, each modifying the 'original header'. Comment / question: - section 5.2, point 4 implies that the OHB can be dropped while I understand the efficiency effect to it (or even topology hiding), isn't also removing useful traces / audit trails? From nobody Wed May 15 18:46:48 2019 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 949C6120183; Wed, 15 May 2019 18:46:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-perc-double@ietf.org, Suhas Nandakumar , perc-chairs@ietf.org, suhasietf@gmail.com, perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <155797119959.30479.12029043973091130444.idtracker@ietfa.amsl.com> Date: Wed, 15 May 2019 18:46:39 -0700 Archived-At: Subject: [Perc] Roman Danyliw's No Objection on draft-ietf-perc-double-10: (with COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 01:46:40 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-perc-double-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-perc-double/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this draft. A few comments: (1) Section 5.1. Step 5. Is the “protected RTP packet” the same as the “synthetic” RTP packet? If so, I recommend using consistent language. (2) Section 5.1. Step 5. Recommend making this text, “append an empty OHB (0x00) to the encrypted payload (with the authentication tag)”, more explicit in stating that concatenation of bytes is encrypted payload + authentication tag + OHB. (3) Editorial: ** Section 5.2. Typo. s/the the/the/ ** Please review the editorial comments in the SECDIR review https://datatracker.ietf.org/doc/review-ietf-perc-double-10-secdir-lc-perlman-2018-10-31/ From nobody Wed May 15 18:52:44 2019 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A2D1200A1; Wed, 15 May 2019 18:52:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-perc-private-media-framework@ietf.org, Nils Ohlmeier , perc-chairs@ietf.org, nohlmeier@mozilla.com, perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <155797155680.30599.3634623355394252682.idtracker@ietfa.amsl.com> Date: Wed, 15 May 2019 18:52:36 -0700 Archived-At: Subject: [Perc] Roman Danyliw's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 01:52:37 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-perc-private-media-framework-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I support Magnus’s DISCUSS about the need to further discuss the impact of a compromised/rogue end-point. In addition to the impersonation of others in the conference, I am wondering about the impact (perhaps a DoS?) of rogue client flooding the conference with EKT Key updates. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) Section 1. Per “Virtualized public cloud environments have been viewed as less secure since resources are not always physically controlled by those who use them and since there are usually several ports open to the public. This document aims to improve security so as to lower the barrier to taking advantage of those environments”, I stumbled over these sentences. Improve security relative to what – self hosted environments? Is the security target have fewer open ports and secure in the face of an adversary with physical access to the system? The latter seems like a very high bar and the corresponding Security Considerations doesn’t seem to rise to that. (2) Section 6.1. “Endpoints have to retain old keys for a period of time to ensure they can properly decrypt late-arriving or out-of-order packets” seems to restate what is stated in 4.5.2 using RFC2119 language. Here “endpoints have to retain”. In Section 4.5.2, “endpoints SHOULD retain”. Which one is correct? (3) Section 8.1. Per “Off-path attackers could try connecting to different PERC entities and send specifically crafted packets”, could you be more specific on the threat. Is this something different than any service being exposed on the Internet? (4) Editorial Nits: ** Section 3. Typo. s/the the/the/ From nobody Wed May 15 23:21:20 2019 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FC51202C5; Wed, 15 May 2019 23:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 4GkR-SbucTCA; Wed, 15 May 2019 23:21:11 -0700 (PDT) Received: from smtp93.iad3a.emailsrvr.com (smtp93.iad3a.emailsrvr.com [173.203.187.93]) (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 C23EC12026B; Wed, 15 May 2019 23:21:10 -0700 (PDT) Received: from smtp20.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp20.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 7522A248E4; Thu, 16 May 2019 02:21:09 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp20.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id B043F22FC4; Thu, 16 May 2019 02:21:08 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Thu, 16 May 2019 02:21:09 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Cullen Jennings In-Reply-To: <155786852996.30194.6992264311523885594.idtracker@ietfa.amsl.com> Date: Thu, 16 May 2019 00:21:07 -0600 Cc: perc@ietf.org, draft-ietf-perc-private-media-framework@ietf.org, IETF Crazy Content-Transfer-Encoding: quoted-printable Message-Id: References: <155786852996.30194.6992264311523885594.idtracker@ietfa.amsl.com> To: Magnus Westerlund , The IESG X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 06:21:17 -0000 > On May 14, 2019, at 3:15 PM, Magnus Westerlund via Datatracker = wrote: >=20 >=20 > A significant security vunerability in PERC that should be made more = explicit > and is totally missing is the risks with compromised endpoints. Beyond = the very > evident thing that this endpoint can decrypt all media it receives = there are > far more sinister risk here. Namely the potential for injection of = media that > attempts to impersonate another endpoints media stream. Most of SRTP's = cipher > suits only use symmetric crypto functions, thus enabling anyone with = the key to > send a packet with any SSRC, and have that being accepted as that = source. Where > it is has no practical usage in point to point communication, in = conferencing > it becomes an issue. It allows the usage of media level replay or deep = fakes to > be used to create media streams that are injected into the media = distributors > using an SSRC of another endpoint. >=20 > The mitiagations that are missing from this document. The fact that a = media > distributor that is not compromised or collaborating with the = compromised > endpoint could actually prevent such media injection by applying = source > filtering of SSRCs and drop all that aren't associated with the = endpoint. The > other potential mitigation is to introduce another cipher suit that = uses a non > symmetric integrity protection mechanism, such as TESLA to prevent = this type of > injection. And the related issue that the main way this can happen is attacker = manipulation of the fingerprint so the providing ways to protect that = along with SSRC based signalling or TELSA is the obvious solution space = to this. And just to frame the discussion, let me point out the issue = you raise is not so much about an SSRC but binding the identity of a = member of the group to the audio received.=20 As other have pointed out, which member inside the conference the media = is from is not something PERC provides any information about. Many = existing conference systems have existing approaches to solve this = problem and they can add PERC as a tool with out breaking theses so it = to be specified here. Something that used TESLA could work fine with = PERC as well. I do think future work can look at what we need for = rosters and active speakers and how to use things like STIR and = fingerprints and SDP to tie identity to the media. However, I think that = problem is fairly separable from the issue of making sure the operator = of the media switch does not have access to the media content.=20 But just to explore what solutions could be build on top of PERC to = solve this, let me cary on.=20 Early on the WG did consider one an Ericssons proposal that used SSRC = based signalling for many things but the WG moved away from that at = least partially over concerns of Ericsson IPR in this space. In trying = to refresh some of the state on possible solutions to this I came = across.=20 = https://patentimages.storage.googleapis.com/07/b2/6a/f34fd49f38a5a4/US2018= 0205720A1.pdf which has the following claim=20 39) A method for a server for enabling setting up a secure peer - to - = peer connection between a first peer and a second peer , wherein at = least one of the first peer and the second peer is a web browser , the = method comprising : receiving a request for a web application from the = first peer ; sending a directive to the first peer requesting a = fingerprint of a certificate of the first peer ; receiving a first = fingerprint from the first peer ; and sending the first fingerprint to = the second peer . So just to make sure I understand this, if we have a case where a webapp = sends an SDP offer that goes to the first peer, this requests the = certificate and of the first peer and sends it in the SDP answer to the = webapp that then sends that answer on to the second peer. It seems this = claim surely covers a bunch stuff we are doing in WebRTC as well as PERC = and needs to be disclosed. You agree ? One thing that would work well is an approach like the CSP protection in = the above patent mixed with the ability for the KD to bind the client to = the web conference application as described in=20 = https://patentimages.storage.googleapis.com/d0/de/1a/5cbafd9903417b/WO2018= 063041A1.pdf Actually claim 1 seems like that is pretty much perfect for solving = this. Claim 1 reads=20 1. A method for a server to bind a device application to a web service, = wherein Web Real Time Control, WebRTC, functionality is provided to the = server, the method comprises: -receiving a request for the web service from the device application, = wherein communication between the server and the device application is = done via https and WebRTC and the device application has generated = WebRTC credentials comprising a private key, certificate of the private = key and a fingerprint of the certificate, -receiving the fingerprint and fingerprint generation algorithm of the = certificate, -storing the fingerprint and fingerprint generation algorithm and = associating the fingerprint with the device application, and -using Datagram Transport Layer Security, DTLS, providing the = certificate of the device application, in combination with the stored = fingerprint to identify the device application to bind the device = application to the web service. So to walk thorough the parts of this claim. When a user joins the web = conference that uses PERC, the request and responses for the = fingerprints are send via the SDP offer and answers over HTTPS, the = website learns the fingerprint for the user and then when the DTLS = connection to the KD is formed, the way the KD correlates to the user to = make sure they are the right one to authorize into the conference is by = using that same fingerprint. Let me know if I am misunderstanding this = or if a disclosure is needed.=20 I think you should propose this stuff to dispatch as way to solve the = problem of knowing who in a conference the media is coming from. Please = let me know if I am misunderstanding theses claims and if disclosures = need to be made.=20 From nobody Wed May 15 23:41:31 2019 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0039E1200E6; Wed, 15 May 2019 23:41:22 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 1k97PD5x-cj9; Wed, 15 May 2019 23:41:18 -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 69EA4120091; Wed, 15 May 2019 23:41:18 -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=1557988873; bh=mCQKJgcSHrk7msOvNQgRICAxX5NHvzDFhHaNg/tNxH4=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=uSrpz53+19mLrc6+t0OpXkXWDnenBiBOTzPgVZr9DsJzuFmMed2V8mk6wnBSuIvYo uj9OoeKG2kS2EepnjUy1sxZ4CB+rJnaDf2Qe0dINtBDM38V7QJCd3MK1JmfG1z/Mor J/MdTf4mE7iRdtpnSx3emvC5UdRb/gwE8ZXLo81k= From: "Paul E. Jones" To: "Magnus Westerlund" , "The IESG" Cc: nohlmeier@mozilla.com, perc-chairs@ietf.org, perc@ietf.org, draft-ietf-perc-private-media-framework@ietf.org Date: Thu, 16 May 2019 06:41:10 +0000 Message-Id: In-Reply-To: <155786852996.30194.6992264311523885594.idtracker@ietfa.amsl.com> References: <155786852996.30194.6992264311523885594.idtracker@ietfa.amsl.com> Reply-To: "Paul E. Jones" User-Agent: eM_Client/7.2.34711.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB79A66162-7EA9-434F-8A57-327B70FCB031" Archived-At: Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 06:41:22 -0000 --------=_MB79A66162-7EA9-434F-8A57-327B70FCB031 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Magnus, Thanks for your feedback. Please see my replies below: >---------------------------------------------------------------------- >DISCUSS: >---------------------------------------------------------------------- > >Its is good to see that this document has continued to improve since I rea= d the >early versions. However, there are some one issues we do need to discuss i= f >they should be better handled before this document is ready for publicatio= n. > >A significant security vunerability in PERC that should be made more expli= cit >and is totally missing is the risks with compromised endpoints. Beyond the = very >evident thing that this endpoint can decrypt all media it receives there a= re >far more sinister risk here. Namely the potential for injection of media t= hat >attempts to impersonate another endpoints media stream. Most of SRTP's cip= her >suits only use symmetric crypto functions, thus enabling anyone with the k= ey to >send a packet with any SSRC, and have that being accepted as that source.= Where >it is has no practical usage in point to point communication, in conferenc= ing >it becomes an issue. It allows the usage of media level replay or deep fak= es to >be used to create media streams that are injected into the media distribut= ors >using an SSRC of another endpoint. > >The mitiagations that are missing from this document. The fact that a medi= a >distributor that is not compromised or collaborating with the compromised >endpoint could actually prevent such media injection by applying source >filtering of SSRCs and drop all that aren't associated with the endpoint.= The >other potential mitigation is to introduce another cipher suit that uses a = non >symmetric integrity protection mechanism, such as TESLA to prevent this ty= pe of >injection. Indeed, Trusted Endpoints need to be secure. There are places in the=20 endpoint where an adversary could initiate an attack and it wouldn't=20 require the sophistication of manipulating SSRCs, even. However, that is=20 a valid attack vector. A challenge with employing a filter is that this=20 could interfere with the normal SSRC collision detection logic in RTP=20 stacks. How about this as a new section? ## Endpoint Attacks A Trusted Endpoint is so named because conference confidentiality relies heavily on the security and integrity of the Endpoint. If an adversary successfully exploits a vulnerability in an Endpoint, it might be=20 possible for the adversary to obtain all of the keying material used in the conference. With that keying material, an adversary could decrypt any of the media flows received from any other Endpoint, either in real-time or at a later point in time (assuming the adversary makes a copy of the media packets). Additionally, if an adversary successfully exploits an Endpoint, the adversary could inject media into the conference. One way an adversary could do that is by manipulating the RTP or SRTP software to transmit to whatever media the adversary wishes to send. This could involve re-use of the Endpoint's SSRC, a new SSRC, or the SSRC value of an=20 existing endpoint. However, attacks on the endpoint are not limited to the PERC-specific software within the Endpoint. An attacker could inject media or record media by manipulating the software that sits between the PERC-enabled application and the hardware microphone of video camera, for example. Likewise, an attacker could potentially access confidential media by accessing memory, cache, disk storage, etc. if the endpoint is no=20 secured. >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >In addition I would appreciate if you really consider these issues, especi= ally >A and B. > >A. I think the relationship between the media distributors and the key >distributor needs to be clarified either already in section 3 or in 4. The = fact >that the key distributor needs to know the full set or their group identit= y of >the media distributors to prevent impostering media distributors. That nee= d is >not made clear early enough, only by the end of the security consideration >section is is made clear that this is the fact. I think it should be state= d >explicitly early on. I would suggest a new paragraph at the end of 3.2.2 as follows: They Key Distributor needs to know which Endpoints and which Media Distributors are authorized to participate in the conference. How the Key Distributor obtains this information is outside the scope of this document. However, Key Distributors **MUST** reject DTLS associations with any unauthorized Endpoint of Media Distributor. The relationship between these entities in terms of roster,=20 certificates, identity, etc. are outside the scope of the framework. >B. Similar the endpoints relation to the key distributor also needs to be >clarified. Also, here diving into potential solutions in Section 5 without >making clear why this very fundamental requirement is needed is far from >optimal. Also here I think discussion in Section 3 or 4 would be good of t= heir >relationship. Especially as this is really relying on mechanism outside of = the >PERC framework. Thus, such requirements should be very explicit stated and >motivated. I think the above additional text should address this concern, too.=20 However, it is probably important to keep in mind that PERC can work=20 with many different types of conferences architectures and these=20 associations is deliberately out scope as the PERC framework for this=20 reason. >C. Section 4.3: > >If there is a need to encrypt one or more RTP header extensions end- > to-end, the endpoint derives an encryption key from the E2E SRTP > master key to encrypt header extensions as per [RFC6904]. The Media > Distributor is unable use the information contained in those header > extensions encrypted with an E2E key. > >As RFC 6904 works on type of header extensions, all header extensions of >that type need to be encrypted independent of sender, that could be made >clearer. I do not understand what you're saying here. The sender will create an=20 encrypted stream and then AND that with the mask created over the header=20 extensions. The mask will be over whatever extensions the sender wants=20 to encrypt. There's nothing different in PERC from what is in RFC 6904. Can you clarify what you are looking for here? >D. Section 4.5: > > o The E2E key that an endpoint uses to send SRTP media can either be > set from DTLS or chosen by the endpoint. > > I think "set from DTLS" should be changed to make it clear that = the > DTLS is with the Key Distributor. I changed my local text to say that. >E. Section 4.5.1: > >Wouldn't this sentence be clearer: > > Endpoints establish a DTLS-SRTP [RFC5764] association over the RTP > session's media ports for the purposes of key information exchange > with the Key Distributor. > >is worded like this: > > Endpoints establish a DTLS-SRTP [RFC5764] association over the RTP > session with the media distributor and it's media ports for the > purposes of key information exchange with the Key Distributor. > Yep, sounds good. I changed "it's" to "its", but otherwise accepted your=20 text as proposed. Paul --------=_MB79A66162-7EA9-434F-8A57-327B70FCB031 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Magnus,

Thanks for your feedback= . =C2=A0Please see my replies below:


-----------------------------------------------------= -----------------
DISCUSS:
-------------------------------------------------= ---------------------
=C2=A0
Its is good to see that this document has continu= ed to improve since I read the
early versions. However, there are some one issue= s we do need to discuss if
they should be better handled before this documen= t is ready for publication.
=C2=A0
A significant security vunerability in PERC that= should be made more explicit
and is totally missing is the risks with compromi= sed endpoints. Beyond the very
evident thing that this endpoint can decrypt all= media it receives there are
far more sinister risk here. Namely the potential = for injection of media that
attempts to impersonate another endpoints media s= tream. Most of SRTP's cipher
suits only use symmetric crypto functions, thus e= nabling anyone with the key to
send a packet with any SSRC, and have that being= accepted as that source. Where
it is has no practical usage in point to point co= mmunication, in conferencing
it becomes an issue. It allows the usage of media = level replay or deep fakes to
be used to create media streams that are injected = into the media distributors
using an SSRC of another endpoint.
=C2=A0
The mitiagations that are missing from this docum= ent. The fact that a media
distributor that is not compromised or collaborat= ing with the compromised
endpoint could actually prevent such media inject= ion by applying source
filtering of SSRCs and drop all that aren't assoc= iated with the endpoint. The
other potential mitigation is to introduce anothe= r cipher suit that uses a non
symmetric integrity protection mechanism, such as = TESLA to prevent this type of
injection.

Indeed, Trusted Endpoints = need to be secure. There are places in the endpoint where an adversary co= uld initiate an attack and it wouldn't require the sophistication of manipu= lating SSRCs, even. However, that is a valid attack vector. A challenge w= ith employing a filter is that this could interfere with the normal SSRC co= llision detection logic in RTP stacks.
How about this as a new section?


## Endpoint Attacks

A Trusted Endpoint is so named becau= se conference confidentiality relies
heavily on the security and integr= ity of the Endpoint. If an adversary
successfully exploits a vulnerabi= lity in an Endpoint, it might be possible
for the adversary to obtain a= ll of the keying material used in the
conference. With that keying mat= erial, an adversary could decrypt any
of the media flows received from= any other Endpoint, either in real-time
or at a later point in time (as= suming the adversary makes a copy of the
media packets).

Additionally, if an adversary successfully exploits an Endpoint, the
a= dversary could inject media into the conference. One way an adversary
= could do that is by manipulating the RTP or SRTP software to transmit to
whatever media the adversary wishes to send. This could involve
re-u= se of the Endpoint's SSRC, a new SSRC, or the SSRC value of an existing
endpoint.

However, attacks on the endpoint are not limite= d to the PERC-specific
software within the Endpoint. An attacker coul= d inject media or record
media by manipulating the software that sits b= etween the PERC-enabled
application and the hardware microphone of vide= o camera, for example.
Likewise, an attacker could potentially access= confidential media by
accessing memory, cache, disk storage, etc. if= the endpoint is no secured.

=
-= ---------------------------------------------------------------------
COMMENT:
-------------------------------------------------= ---------------------
=C2=A0
In addition I would appreciate if you really cons= ider these issues, especially
A and B.
=C2=A0
A. I think the relationship between the media dis= tributors and the key
distributor needs to be clarified either already= in section 3 or in 4. The fact
that the key distributor needs to know the full s= et or their group identity of
the media distributors to prevent impostering med= ia distributors. That need is
not made clear early enough, only by the end of t= he security consideration
section is is made clear that this is the fact. I = think it should be stated
explicitly early on.

I would suggest = a new paragraph at the end of 3.2.2 as follows:

They Key Distributor needs to know which = Endpoints and which Media
Distributors are= authorized to participate in the conference.=C2=A0 How the
Key Distrib= utor obtains this information is outside the scope of this
document.= =C2=A0 However, Key Distributors **MUST** reject DTLS associations
wit= h any unauthorized Endpoint of Media Distributor.

The relationship b= etween these entities in terms of roster, certificates, identity, etc. are= outside the scope of the framework.

= B. Similar the endpoints relation to the key distributor also needs to be
clarified. Also, here diving into potential solut= ions in Section 5 without
making clear why this very fundamental requiremen= t is needed is far from
optimal. Also here I think discussion in Section= 3 or 4 would be good of their
relationship. Especially as this is really relyin= g on mechanism outside of the
PERC framework. Thus, such requirements should be = very explicit stated and
motivated.

I think the above additio= nal text should address this concern, too. However, it is probably importa= nt to keep in mind that PERC can work with many different types of conferen= ces architectures and these associations is deliberately out scope as the P= ERC framework for this reason.


C. Section 4.3:
=C2=A0
If there is a need to encrypt one or more RTP hea= der extensions end-
to-end, the endpoint derives an encryption key = from the E2E SRTP
master key to encrypt header extensions as per = [RFC6904]. The Media
Distributor is unable use the information cont= ained in those header
extensions encrypted with an E2E key.
=C2=A0
As RFC 6904 works on type of header extensions, a= ll header extensions of
that type need to be encrypted independent of sen= der, that could be made
clearer.

I do not understand what yo= u're saying here. The sender will create an encrypted stream and then AND= that with the mask created over the header extensions. The mask will be ov= er whatever extensions the sender wants to encrypt. There's nothing differ= ent in PERC from what is in RFC 6904.

Can you clarify what you are looking= for here?

D. Section 4.5:
=C2=A0
o The E2E key that an endpoint uses to send S= RTP media can either be
set from DTLS or chosen by the endpoint.
=C2=A0
I think "set from DTLS" should be chang= ed to make it clear that the
DTLS is with the Key Distributor.=C2=A0=

I changed my local text to say that.


E. Section 4.5.1:
=C2=A0
Wouldn't this sentence be clearer:
=C2=A0
Endpoints establish a DTLS-SRTP [RFC5764] asso= ciation over the RTP
session's media ports for the purposes of key= information exchange
with the Key Distributor.
=C2=A0
is worded like this:
=C2=A0
Endpoints establish a DTLS-SRTP [RFC5764] asso= ciation over the RTP
session with the media distributor and it's me= dia ports for the
purposes of key information exchange with the= Key Distributor.


Yep, sounds good. I changed= "it's" to "its", but otherwise accepted your text as proposed.

Paul


<= /div>
--------=_MB79A66162-7EA9-434F-8A57-327B70FCB031-- From nobody Thu May 16 03:00:36 2019 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB2D12006F; Thu, 16 May 2019 03:00:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: draft-ietf-perc-double@ietf.org, Suhas Nandakumar , perc-chairs@ietf.org, suhasietf@gmail.com, perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <155800082724.19580.16483563575859435866.idtracker@ietfa.amsl.com> Date: Thu, 16 May 2019 03:00:27 -0700 Archived-At: Subject: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-double-10: (with DISCUSS and COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 10:00:27 -0000 Magnus Westerlund has entered the following ballot position for draft-ietf-perc-double-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-perc-double/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 1. Section 5.1: To me it appears that one fundamental security flaw exists in the definition of the inner encryption. That is the fact that RTP padding is not included into the inner encrypted part. This prevents the application of RTP padding to prevent the potential privacy leakage that "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP" (RFC 6562) documents. To prevent this type of information leakage and other privacy preserving operations based on applying RTP padding it would be necessary to include the RTP padding into the inner encrypted envelope. Appendix A figure indicates that is the case, but the process description in 5.1 is not matching that. 2. Section 5.1: 1. Form an RTP packet. If there are any header extensions, they MUST use [RFC8285]. I got the impression from the framework that it was possible to have some header extension being encrypted using the inner key as (Section 4:3) says: If there is a need to encrypt one or more RTP header extensions end- to-end, the endpoint derives an encryption key from the E2E SRTP master key to encrypt header extensions as per [RFC6904]. That is missing from this step as it can't be applied in step 4. And shouldn't the headers protected in this fashion with the inner keys be part of the authenticated synthetic packet? 3. Section 5.2: This is minor but still a significant inconsistency: 3. A Media Distributor can add information to the OHB, but MUST NOT change existing information in the OHB. If RTP value is changed and not already in the OHB, then add it with its original value to the OHB. 4. If the Media Distributor resets a parameter to its original value, it MAY drop it from the OHB. Note that this might result in a decrease in the size of the OHB. So reseting back to original value, is according to 3 not allowed. I think the MUST NOT is wrongly formulated. I assume that the point is that any field value carrying an original value MUST NOT be changed, however, if the field is changed back to its original value, the value SHALL/SHOULD be removed from the OHB? 4. Section 5.2: ... SHOULD use an independent salt for each recipient, Is that possible on any other legs than MD to MD? What has been statated is that all end-point are required to use the same sal for a session as that is not included in the EKT. Putting a SHOULD requirement on something that is not possbile appears counter productive. 5. Section 7.1: This section fails to make it clear why RTX packets are retransmitting the double encrypted packets. In normal application of SRTP the buffered packet and what is used for constructing the RTX packet is the unencrypted one. Thus the equivalent for an MD would be to handle the Inner protected only in its cache. Is the reason that an endpoint that recovers a packet anyway have to pass it through the double decryption process and thus it is to avoid a exception case for the endpoint? If that is the case, please note it in the text. 6. Section 7.2: I fail to see how one can follow this procedure and generate anything that is workable. The reasons is that that the primary encoding and each of multiple redundancy encoding all share the same SSRC and have no independent sequence number space or timestamp space. Thus, I don't see how it is possible to create inner encrypted payloads for each of the primary and redundnacy encoding without two time pads. Why wasn't the simple choice applied here. That is to treat RED as a single endpoint to endpoint format. Thus making it robust if packets are lost on the path, but the MD's can't recreate a packet based on a redundancy paylaod and inject that instead. I don't see how that this is a correct statement. As RED does not have different SSRCs for the different media encodings what it does can't be represented in FlexFEC. "Note that Flex FEC [I-D.ietf-payload-flexible-fec-scheme] is a superset of the capabilities of RED. For most applications, FlexFEC is a better choice than RED." 7. Section 9: When this is done, the cryptographic contexts used for decryption and re-encryption MUST use different, independent master keys and master salts. Related to discuss item 4 and here at different RFC 2119 levels. 8. Section 9. The use of AES-GCM as symmetric algorithms results in that the source authication level for the inner part has a limited scope, in that any endpoint can create a double protected packet, not only the one that which SSRC it is as there are no cryptographic protection on that level. I think that point is significant for something that is primarily targeting group communication scenarios. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A. Section 3.1: Here "PRF_n(k, x)" represents the AES_CM PRF KDF [RFC3711] for DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM algorithm and AES_256_CM_PRF KDF [RFC6188] for DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM algorithm. I would recommend that you are a bit more specific about your references. So for the AES_CM PRF I think that should actually point to section 4.3.3 or at least 4.3 of RFC 3711. B. Section 1 and 4: Section 1 says: In that case, the original value of any RTP header field that is changed is included in a new RTP header extension called the Original Header Block. Section 4 says: In the encryption process, the OHB is appended to the RTP payload. I assume it is 1 that should be changed and this is a missed case of moving the OHB from header extensions to encryption payload. C. Section 4: In the encryption process, the OHB is appended to the RTP payload. I think that is a bit imprecise. Considering the diagram in Appendix A. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<++ |V=2|P|X| CC |M| PT | sequence number | IO +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO | timestamp | IO +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO | synchronization source (SSRC) identifier | IO +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ IO | contributing source (CSRC) identifiers | IO | .... | IO +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O | RTP extension (OPTIONAL) ... | |O +>+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O O I | payload ... | IO O I | +-------------------------------+ IO O I | | RTP padding | RTP pad count | IO O +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O O | | E2E authentication tag | |O O | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O O | | OHB ... | |O +>| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |+ | | | HBH authentication tag | || | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || | | || | +- E2E Encrypted Portion E2E Authenticated Portion ---+| | | +--- HBH Encrypted Portion HBH Authenticated Portion ----+ If we follow the figure, but I am uncertain as seen by Discuss 1. The OHB is added after the inner protected part (RTP paylaod, RTP padding and E2E authentication tag). D. Section 5.1: 5. Replace the header of the protected RTP packet with the header of the original packet, and append an empty OHB (0x00) to the encrypted payload (with the authentication tag) obtained from the step 4. I assume that this should say 5. Replace the header of the protected synthetic RTP packet with the header of the original packet (to restore any header extensions), and append an empty OHB (0x00) to the end of the encrypted payload (with the authentication tag) obtained from the step 4. E. Section 5.2: In order to modify a packet, the Media Distributor decrypts the received packet, modifies the packet, updates the OHB with any modifications not already present in the OHB, and re-encrypts the packet using the the outer (hop-by-hop) cryptographic key before transmitting. I think this text should be clear that the applied key for the encryption is not the same as the one used for the decryption as it is depending on who is the next hop receiver, if that is MD or another endpoint. The text after the bullet list could be more specific to point. This comment applies to bullet 1 and 5 that should be clarified on that. F. Section 5.2: Bullet 2: Should mentions that some header extensions may be changed. G. Section 8: If no other header extensions are present in the packet and the OHB is introduced, that will consume an additional 8 octets. If other extensions are already present, the OHB will consume up to 4 additional octets. Packets in repair mode will carry additional repair data, further increasing their size. More leftovers from change from header extension to payload for OHB. From nobody Thu May 16 07:11:44 2019 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EA71200BA; Thu, 16 May 2019 07:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Lc18sNlFikYm; Thu, 16 May 2019 07:11:26 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60041.outbound.protection.outlook.com [40.107.6.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D960120098; Thu, 16 May 2019 07:11:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=47g9ISpF0o/k9Oi+j5X9O+p4sMw7qCZlkDt1A1Q3fAU=; b=NIDNH9VvkoAfsn4RypVktC7ouDmeuUWxRv7gbghrG/1HqIMqepDUCj8uQ1Kr3bu6FpVdLSSTsdt5QfIq+Q0ZYmhW86JZTEw4C7rsGOrDrGkR6YlBHJv4NthqbsmXi61ckCffRb9hI4g2J+dIxFlCk5RyGqTVOcg4+yM8o1Re64A= Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2251.eurprd07.prod.outlook.com (10.168.29.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.11; Thu, 16 May 2019 14:11:23 +0000 Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::896a:7ada:8bc9:d99d]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::896a:7ada:8bc9:d99d%6]) with mapi id 15.20.1900.010; Thu, 16 May 2019 14:11:23 +0000 From: Magnus Westerlund To: Cullen Jennings , The IESG CC: "perc@ietf.org" , "draft-ietf-perc-private-media-framework@ietf.org" , IETF Crazy Thread-Topic: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT) Thread-Index: AQHVCpou6R9yAhphm0qqCd+nrV/WHQ== Date: Thu, 16 May 2019 14:11:23 +0000 Message-ID: References: <155786852996.30194.6992264311523885594.idtracker@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c370a123-ffe1-4bdd-89dd-08d6da0860c7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2251; x-ms-traffictypediagnostic: HE1PR0701MB2251: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0039C6E5C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(396003)(366004)(136003)(39860400002)(51444003)(189003)(199004)(305945005)(7736002)(86362001)(8936002)(316002)(53546011)(6506007)(7696005)(99286004)(52536014)(81166006)(6116002)(102836004)(3846002)(2906002)(81156014)(25786009)(76176011)(8676002)(66574012)(5660300002)(71190400001)(486006)(71200400001)(256004)(74316002)(476003)(508600001)(33656002)(6436002)(53936002)(68736007)(6246003)(66556008)(91956017)(54906003)(110136005)(966005)(76116006)(26005)(4326008)(44832011)(561944003)(66476007)(64756008)(66946007)(9686003)(66066001)(66446008)(14454004)(446003)(73956011)(14444005)(186003)(55016002)(6306002)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2251; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: VnB6l+XgE0zV8ORRHzFbvQwjaqa0dXc0AaTxkiDP14FrQoz2RuCSinZnRQcgxZmTwTRlhETFHTiobTHJVr5g0xZD3LNIWNIo54KPQG6tqwXrCf49gPnwTBu4IoobJ0eCx+RyChFiZ112fQDScCIZfqwnJd0r3U+iXbbfKyVS74Ot3eNSdmYJYFbQGLZrFSkQ/jdKCpETdeHF7U23gBI3BqCz0HAiYg9Rbv84JC4r7Gam5Z7hOcWW9VbZkSZh+LRwQ5sgLJyPyRvSTHM7oKcJKIkm+yRthRWofDouQppSttycuxiSC8AKFxI+t5y3IU/oMqZj/0yOs9MTgmiHBfNwLH70OwP1VvQ88ShCe411S3qT+wh8LgYdNgdvmzADS/8yKgBe2I+Pbnn88iDR85vrthEMSBpwLmakN+wYjR5G1CI= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: c370a123-ffe1-4bdd-89dd-08d6da0860c7 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2019 14:11:23.5435 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2251 Archived-At: Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 14:11:30 -0000 Hi Cullen,=0A= =0A= On 2019-05-16 08:21, Cullen Jennings wrote:=0A= >=0A= >> On May 14, 2019, at 3:15 PM, Magnus Westerlund via Datatracker wrote:=0A= >>=0A= >>=0A= >> A significant security vunerability in PERC that should be made more exp= licit=0A= >> and is totally missing is the risks with compromised endpoints. Beyond t= he very=0A= >> evident thing that this endpoint can decrypt all media it receives there= are=0A= >> far more sinister risk here. Namely the potential for injection of media= that=0A= >> attempts to impersonate another endpoints media stream. Most of SRTP's c= ipher=0A= >> suits only use symmetric crypto functions, thus enabling anyone with the= key to=0A= >> send a packet with any SSRC, and have that being accepted as that source= . Where=0A= >> it is has no practical usage in point to point communication, in confere= ncing=0A= >> it becomes an issue. It allows the usage of media level replay or deep f= akes to=0A= >> be used to create media streams that are injected into the media distrib= utors=0A= >> using an SSRC of another endpoint.=0A= >>=0A= >> The mitiagations that are missing from this document. The fact that a me= dia=0A= >> distributor that is not compromised or collaborating with the compromise= d=0A= >> endpoint could actually prevent such media injection by applying source= =0A= >> filtering of SSRCs and drop all that aren't associated with the endpoint= . The=0A= >> other potential mitigation is to introduce another cipher suit that uses= a non=0A= >> symmetric integrity protection mechanism, such as TESLA to prevent this = type of=0A= >> injection.=0A= > And the related issue that the main way this can happen is attacker manip= ulation of the fingerprint so the providing ways to protect that along with= SSRC based signalling or TELSA is the obvious solution space to this. And= just to frame the discussion, let me point out the issue you raise is not = so much about an SSRC but binding the identity of a member of the group to = the audio received. =0A= =0A= Yes, agree that the fundamental is to know which identity that create a=0A= particular packet. How that is accomplished there are many solutions.=0A= =0A= =0A= >=0A= > As other have pointed out, which member inside the conference the media i= s from is not something PERC provides any information about. Many existing = conference systems have existing approaches to solve this problem and they = can add PERC as a tool with out breaking theses so it to be specified here.= Something that used TESLA could work fine with PERC as well. I do think fu= ture work can look at what we need for rosters and active speakers and how = to use things like STIR and fingerprints and SDP to tie identity to the med= ia. However, I think that problem is fairly separable from the issue of mak= ing sure the operator of the media switch does not have access to the media= content. =0A= =0A= Yes, and to be clear I don't expect that base PERC solution should solve=0A= the issue. I only requested that the security properties that exist are=0A= made clear. =0A= =0A= Regarding your below questions I will reply to that separately and it=0A= may take me a couple of days.=0A= =0A= Cheers=0A= =0A= Magnus=0A= =0A= =0A= >=0A= > But just to explore what solutions could be build on top of PERC to solve= this, let me cary on. =0A= >=0A= > Early on the WG did consider one an Ericssons proposal that used SSRC bas= ed signalling for many things but the WG moved away from that at least part= ially over concerns of Ericsson IPR in this space. In trying to refresh som= e of the state on possible solutions to this I came across. =0A= >=0A= > https://patentimages.storage.googleapis.com/07/b2/6a/f34fd49f38a5a4/US201= 80205720A1.pdf=0A= >=0A= > which has the following claim =0A= >=0A= > 39) A method for a server for enabling setting up a secure peer - to - pe= er connection between a first peer and a second peer , wherein at least one= of the first peer and the second peer is a web browser , the method compri= sing : receiving a request for a web application from the first peer ; send= ing a directive to the first peer requesting a fingerprint of a certificate= of the first peer ; receiving a first fingerprint from the first peer ; an= d sending the first fingerprint to the second peer .=0A= >=0A= > So just to make sure I understand this, if we have a case where a webapp = sends an SDP offer that goes to the first peer, this requests the certifica= te and of the first peer and sends it in the SDP answer to the webapp that = then sends that answer on to the second peer. It seems this claim surely co= vers a bunch stuff we are doing in WebRTC as well as PERC and needs to be d= isclosed. You agree ?=0A= >=0A= > One thing that would work well is an approach like the CSP protection in = the above patent mixed with the ability for the KD to bind the client to th= e web conference application as described in =0A= >=0A= > https://patentimages.storage.googleapis.com/d0/de/1a/5cbafd9903417b/WO201= 8063041A1.pdf=0A= >=0A= > Actually claim 1 seems like that is pretty much perfect for solving this.= Claim 1 reads =0A= >=0A= > 1. A method for a server to bind a device application to a web service, w= herein Web Real Time Control, WebRTC, functionality is provided to the serv= er, the method comprises:=0A= > -receiving a request for the web service from the device application, whe= rein communication between the server and the device application is done vi= a https and WebRTC and the device application has generated WebRTC credenti= als comprising a private key, certificate of the private key and a fingerpr= int of the certificate,=0A= > -receiving the fingerprint and fingerprint generation algorithm of the c= ertificate,=0A= > -storing the fingerprint and fingerprint generation algorithm and associ= ating the fingerprint with the device application, and=0A= > -using Datagram Transport Layer Security, DTLS, providing the certificate= of the device application, in combination with the stored fingerprint to i= dentify the device application to bind the device application to the web se= rvice.=0A= >=0A= > So to walk thorough the parts of this claim. When a user joins the web co= nference that uses PERC, the request and responses for the fingerprints are= send via the SDP offer and answers over HTTPS, the website learns the fing= erprint for the user and then when the DTLS connection to the KD is formed,= the way the KD correlates to the user to make sure they are the right one = to authorize into the conference is by using that same fingerprint. Let me = know if I am misunderstanding this or if a disclosure is needed. =0A= >=0A= > I think you should propose this stuff to dispatch as way to solve the pro= blem of knowing who in a conference the media is coming from. Please let me= know if I am misunderstanding theses claims and if disclosures need to be = made. =0A= >=0A= >=0A= >=0A= >=0A= >=0A= >=0A= =0A= -- =0A= =0A= Magnus Westerlund =0A= =0A= ----------------------------------------------------------------------=0A= Network Architecture & Protocols, Ericsson Research=0A= ----------------------------------------------------------------------=0A= Ericsson AB | Phone +46 10 7148287=0A= Torshamnsgatan 23 | Mobile +46 73 0949079=0A= SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A= ----------------------------------------------------------------------=0A= =0A= From nobody Thu May 16 07:54:47 2019 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17FFE1200EC; Thu, 16 May 2019 07:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 TzSleZT9yC7O; Thu, 16 May 2019 07:54:32 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30057.outbound.protection.outlook.com [40.107.3.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B2BB120094; Thu, 16 May 2019 07:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pe7oCzWbB9HFYdiGO8kio3kIyAcshQFI0CaakinDm+4=; b=nu3UOEh4PLMUkd77Ehqk/Re9MOxxKLYSHD3ulXZAkLomjkv/keToLihxEpZH2YDGXbq82Wax21GfuVkl1tO4WEl+j4vEM+Bo/CznwN6EtgP43O7DW/m+8nq6odI6zMmJTjohOFa3Rpl+nMw5Gmc38YrUKODjiSwa8AK9KJSi5S8= Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2844.eurprd07.prod.outlook.com (10.168.97.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.7; Thu, 16 May 2019 14:54:28 +0000 Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::896a:7ada:8bc9:d99d]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::896a:7ada:8bc9:d99d%6]) with mapi id 15.20.1900.010; Thu, 16 May 2019 14:54:28 +0000 From: Magnus Westerlund To: "Paul E. Jones" , The IESG CC: "nohlmeier@mozilla.com" , "perc-chairs@ietf.org" , "perc@ietf.org" , "draft-ietf-perc-private-media-framework@ietf.org" Thread-Topic: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT) Thread-Index: AQHVCpou6R9yAhphm0qqCd+nrV/WHQ== Date: Thu, 16 May 2019 14:54:28 +0000 Message-ID: References: <155786852996.30194.6992264311523885594.idtracker@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a7fdbfff-2477-4fdf-42a0-08d6da0e657a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2844; x-ms-traffictypediagnostic: HE1PR0701MB2844: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0039C6E5C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(376002)(346002)(396003)(366004)(51914003)(189003)(199004)(6506007)(102836004)(508600001)(66066001)(110136005)(236005)(5660300002)(316002)(14454004)(9686003)(54906003)(54896002)(53936002)(3846002)(26005)(81156014)(81166006)(99286004)(2906002)(76176011)(186003)(53546011)(6116002)(7696005)(86362001)(6246003)(71200400001)(14444005)(256004)(446003)(476003)(71190400001)(7736002)(52536014)(68736007)(55016002)(74316002)(486006)(229853002)(76116006)(91956017)(73956011)(8936002)(66946007)(66476007)(66556008)(64756008)(66446008)(8676002)(4326008)(25786009)(6436002)(44832011)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2844; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: eY1ZNPtRTtIWNhjtWsXAXB8hvh6sUVipMy0lyqDEe/4oNIrSgwB8pbvIXkb+jJ7Ku5uxohyB2eDNIgPBL5o49iEdsC1NFMtgUp+sg5I20lNnkIPUPsLBF8CDbnO1EaFgCxyD705sRQkDhu/KZHYzN31ITlCFWIJgOYGbKECmbbuvWCLdb2bLwATAewa5KoigHGyQW7hctRYQWQCcYvK/bC0K4vbtv48IwuIj4Kz3I2FzPXrI06TjONZOgA8em9btqKyx8OKVgBprjaxaTrEUG1QGfiLwXNWW8RhfIqptpM0QtFJp6YbqmdfMIppQZ8iYXZ3jJRgtooT451r82hDOD4lIZfq9Wlr3QnpK1mBGPpz6g+A6IbNIO8dpolqhq3fucpRicsTuaEE2MtuDReesbZ/YKInCQoUkefgIoa0ukQQ= Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB2522CD96FDCB0F920CE2740F950A0HE1PR0701MB2522_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: a7fdbfff-2477-4fdf-42a0-08d6da0e657a X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2019 14:54:28.5021 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2844 Archived-At: Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 14:54:37 -0000 --_000_HE1PR0701MB2522CD96FDCB0F920CE2740F950A0HE1PR0701MB2522_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul, Thanks for the rapid response. See my comments inline. On 2019-05-16 08:41, Paul E. Jones wrote: Magnus, Thanks for your feedback. Please see my replies below: ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Its is good to see that this document has continued to improve since I read= the early versions. However, there are some one issues we do need to discuss if they should be better handled before this document is ready for publication= . A significant security vunerability in PERC that should be made more explic= it and is totally missing is the risks with compromised endpoints. Beyond the = very evident thing that this endpoint can decrypt all media it receives there ar= e far more sinister risk here. Namely the potential for injection of media th= at attempts to impersonate another endpoints media stream. Most of SRTP's ciph= er suits only use symmetric crypto functions, thus enabling anyone with the ke= y to send a packet with any SSRC, and have that being accepted as that source. W= here it is has no practical usage in point to point communication, in conferenci= ng it becomes an issue. It allows the usage of media level replay or deep fake= s to be used to create media streams that are injected into the media distributo= rs using an SSRC of another endpoint. The mitiagations that are missing from this document. The fact that a media distributor that is not compromised or collaborating with the compromised endpoint could actually prevent such media injection by applying source filtering of SSRCs and drop all that aren't associated with the endpoint. T= he other potential mitigation is to introduce another cipher suit that uses a = non symmetric integrity protection mechanism, such as TESLA to prevent this typ= e of injection. Indeed, Trusted Endpoints need to be secure. There are places in the endpoi= nt where an adversary could initiate an attack and it wouldn't require the = sophistication of manipulating SSRCs, even. However, that is a valid attack= vector. A challenge with employing a filter is that this could interfere w= ith the normal SSRC collision detection logic in RTP stacks. How about this as a new section? ## Endpoint Attacks A Trusted Endpoint is so named because conference confidentiality relies heavily on the security and integrity of the Endpoint. If an adversary successfully exploits a vulnerability in an Endpoint, it might be possible for the adversary to obtain all of the keying material used in the conference. With that keying material, an adversary could decrypt any of the media flows received from any other Endpoint, either in real-time or at a later point in time (assuming the adversary makes a copy of the media packets). Additionally, if an adversary successfully exploits an Endpoint, the adversary could inject media into the conference. One way an adversary could do that is by manipulating the RTP or SRTP software to transmit to whatever media the adversary wishes to send. This could involve re-use of the Endpoint's SSRC, a new SSRC, or the SSRC value of an existing endpoint. However, attacks on the endpoint are not limited to the PERC-specific software within the Endpoint. An attacker could inject media or record media by manipulating the software that sits between the PERC-enabled application and the hardware microphone of video camera, for example. Likewise, an attacker could potentially access confidential media by accessing memory, cache, disk storage, etc. if the endpoint is no secured. I think this is mostly good, however not particular specific on the securit= y properties of the system that the framework creates, that is dependent on= the realization of the authentication tag added to the packet. So, the imp= ersonation issue that are alluded is only possible given that there a no so= lution that allows specific identity assertions on a per packet basis. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In addition I would appreciate if you really consider these issues, especia= lly A and B. A. I think the relationship between the media distributors and the key distributor needs to be clarified either already in section 3 or in 4. The = fact that the key distributor needs to know the full set or their group identity= of the media distributors to prevent impostering media distributors. That need= is not made clear early enough, only by the end of the security consideration section is is made clear that this is the fact. I think it should be stated explicitly early on. I would suggest a new paragraph at the end of 3.2.2 as follows: They Key Distributor needs to know which Endpoints and which Media Distributors are authorized to participate in the conference. How the Key Distributor obtains this information is outside the scope of this document. However, Key Distributors **MUST** reject DTLS associations with any unauthorized Endpoint of Media Distributor. Looks okay, I assume of/or. The relationship between these entities in terms of roster, certificates, i= dentity, etc. are outside the scope of the framework. B. Similar the endpoints relation to the key distributor also needs to be clarified. Also, here diving into potential solutions in Section 5 without making clear why this very fundamental requirement is needed is far from optimal. Also here I think discussion in Section 3 or 4 would be good of th= eir relationship. Especially as this is really relying on mechanism outside of = the PERC framework. Thus, such requirements should be very explicit stated and motivated. I think the above additional text should address this concern, too. However= , it is probably important to keep in mind that PERC can work with many dif= ferent types of conferences architectures and these associations is deliber= ately out scope as the PERC framework for this reason. Yes, the above text do address the comment. C. Section 4.3: If there is a need to encrypt one or more RTP header extensions end- to-end, the endpoint derives an encryption key from the E2E SRTP master key to encrypt header extensions as per [RFC6904]. The Media Distributor is unable use the information contained in those header extensions encrypted with an E2E key. As RFC 6904 works on type of header extensions, all header extensions of that type need to be encrypted independent of sender, that could be made clearer. I do not understand what you're saying here. The sender will create an encr= ypted stream and then AND that with the mask created over the header extens= ions. The mask will be over whatever extensions the sender wants to encrypt= . There's nothing different in PERC from what is in RFC 6904. Yes, you are correct that this is an inherent property of RFC 6904 in that = one defines on header extension ID level if it is to be encrypted or not. I= n the PERC situation it is not clear how one determines which should be end= -to-end encrypted and which are only hop-by-hop. I think the later should n= ormally be all header extensions. After having read double that fails to de= fine how one performs the end-to-end encryption of header extensions I thin= k there are more to dig into here. So, one issue is clearly signalling that a particular type of header extens= ions are to be end-to-end encrypted. Can you clarify what you are looking for here? D. Section 4.5: o The E2E key that an endpoint uses to send SRTP media can either be set from DTLS or chosen by the endpoint. I think "set from DTLS" should be changed to make it clear that the DTLS is with the Key Distributor. I changed my local text to say that. Great! E. Section 4.5.1: Wouldn't this sentence be clearer: Endpoints establish a DTLS-SRTP [RFC5764] association over the RTP session's media ports for the purposes of key information exchange with the Key Distributor. is worded like this: Endpoints establish a DTLS-SRTP [RFC5764] association over the RTP session with the media distributor and it's media ports for the purposes of key information exchange with the Key Distributor. Yep, sounds good. I changed "it's" to "its", but otherwise accepted your te= xt as proposed. Thanks Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --_000_HE1PR0701MB2522CD96FDCB0F920CE2740F950A0HE1PR0701MB2522_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Paul,

Thanks for the rapid response. See my commen= ts inline.

On 2019-05-16 08:41, Paul E. Jones wrote:
Magnus,

Thanks for your feedback.  Please see my replies below:


-------------------------------------------------= ---------------------
DISCUSS:
-------------------------------------------------= ---------------------
 
Its is good to see that this document has continu= ed to improve since I read the
early versions. However, there are some one issue= s we do need to discuss if
they should be better handled before this documen= t is ready for publication.
 
A significant security vunerability in PERC that = should be made more explicit
and is totally missing is the risks with compromi= sed endpoints. Beyond the very
evident thing that this endpoint can decrypt all = media it receives there are
far more sinister risk here. Namely the potential= for injection of media that
attempts to impersonate another endpoints media s= tream. Most of SRTP's cipher
suits only use symmetric crypto functions, thus e= nabling anyone with the key to
send a packet with any SSRC, and have that being = accepted as that source. Where
it is has no practical usage in point to point co= mmunication, in conferencing
it becomes an issue. It allows the usage of media= level replay or deep fakes to
be used to create media streams that are injected= into the media distributors
using an SSRC of another endpoint.
 
The mitiagations that are missing from this docum= ent. The fact that a media
distributor that is not compromised or collaborat= ing with the compromised
endpoint could actually prevent such media inject= ion by applying source
filtering of SSRCs and drop all that aren't assoc= iated with the endpoint. The
other potential mitigation is to introduce anothe= r cipher suit that uses a non
symmetric integrity protection mechanism, such as= TESLA to prevent this type of
injection.

Indeed, Trusted Endpoints need to be secure. T= here are places in the endpoint where an adversary could initiate an attack= and it wouldn't require the sophistication of manipulating SSRCs, even. Ho= wever, that is a valid attack vector. A challenge with employing a filter is that this could interfere with the = normal SSRC collision detection logic in RTP stacks.

How about this as a new section?


## Endpo= int Attacks

A Truste= d Endpoint is so named because conference confidentiality relies
heavily = on the security and integrity of the Endpoint. If an adversary
successf= ully exploits a vulnerability in an Endpoint, it might be possible
for the = adversary to obtain all of the keying material used in the
conferen= ce. With that keying material, an adversary could decrypt any
of the m= edia flows received from any other Endpoint, either in real-time
or at a = later point in time (assuming the adversary makes a copy of the
media pa= ckets).

Addition= ally, if an adversary successfully exploits an Endpoint, the
adversar= y could inject media into the conference. One way an adversary
could do= that is by manipulating the RTP or SRTP software to transmit to
whatever= media the adversary wishes to send. This could involve
re-use o= f the Endpoint's SSRC, a new SSRC, or the SSRC value of an existing<= /div>
endpoint= .

However,= attacks on the endpoint are not limited to the PERC-specific
software= within the Endpoint. An attacker could inject media or record
media by= manipulating the software that sits between the PERC-enabled
applicat= ion and the hardware microphone of video camera, for example.
Likewise= , an attacker could potentially access confidential media by
accessin= g memory, cache, disk storage, etc. if the endpoint is no secured.

I think this is mostly good, however not particular specific on the secu= rity properties of the system that the framework creates, that is dependent= on the realization of the authentication tag added to the packet. So, the = impersonation issue that are alluded is only possible given that there a no solution that allows specific ident= ity assertions on a per packet basis.



-------------------------------------------------= ---------------------
COMMENT:
-------------------------------------------------= ---------------------
 
In addition I would appreciate if you really cons= ider these issues, especially
A and B.
 
A. I think the relationship between the media dis= tributors and the key
distributor needs to be clarified either already = in section 3 or in 4. The fact
that the key distributor needs to know the full s= et or their group identity of
the media distributors to prevent impostering med= ia distributors. That need is
not made clear early enough, only by the end of t= he security consideration
section is is made clear that this is the fact. I= think it should be stated
explicitly early on.

I would suggest a new paragraph at the end of = 3.2.2 as follows:

They Key Distributor needs to know= which Endpoints and which Media
Distributors are authorized to participate in the confer= ence.  How the
Key Distributor obtains this information is outside the scope of this
document.  However, Key Distributors **MUST** reject DTLS associations=
with any unauthorized Endpoint of Media Distributor.

Looks okay, I assume of/or. =



The relationship between these entities in ter= ms of roster, certificates, identity, etc. are outside the scope of the fra= mework.

B. Similar the endpoints relation to the key dist= ributor also needs to be
clarified. Also, here diving into potential solut= ions in Section 5 without
making clear why this very fundamental requiremen= t is needed is far from
optimal. Also here I think discussion in Section = 3 or 4 would be good of their
relationship. Especially as this is really relyin= g on mechanism outside of the
PERC framework. Thus, such requirements should be= very explicit stated and
motivated.

I think the above additional text should addre= ss this concern, too. However, it is probably important to keep in mind tha= t PERC can work with many different types of conferences architectures and = these associations is deliberately out scope as the PERC framework for this reason.

Yes, the above text do address the comment.



C. Section 4.3:
 
If there is a need to encrypt one or more RTP hea= der extensions end-
to-end, the endpoint derives an encryption key fr= om the E2E SRTP
master key to encrypt header extensions as per [R= FC6904]. The Media
Distributor is unable use the information contain= ed in those header
extensions encrypted with an E2E key.
 
As RFC 6904 works on type of header extensions, a= ll header extensions of
that type need to be encrypted independent of sen= der, that could be made
clearer.

I do not understand what you're saying here. T= he sender will create an encrypted stream and then AND that with the mask c= reated over the header extensions. The mask will be over whatever extension= s the sender wants to encrypt. There's nothing different in PERC from what is in RFC 6904.

Yes, you are correct that this is an inherent property of RFC 6904 in th= at one defines on header extension ID level if it is to be encrypted or not= . In the PERC situation it is not clear how one determines which should be = end-to-end encrypted and which are only hop-by-hop. I think the later should normally be all header extension= s. After having read double that fails to define how one performs the end-t= o-end encryption of header extensions I think there are more to dig into he= re.

So, one issue is clearly signalling that a particular type of header ext= ensions are to be end-to-end encrypted.




Can you clarify what you are looking for here?=

D. Section 4.5:
 
o The E2E key that an endpoint uses to send SRTP = media can either be
set from DTLS or chosen by the endpoint.
 
I think "set from DTLS" should be chang= ed to make it clear that the
DTLS is with the Key Distributor. 

I changed my local text to say that.


Great!



E. Section 4.5.1:
 
Wouldn't this sentence be clearer:
 
Endpoints establish a DTLS-SRTP [RFC5764] associa= tion over the RTP
session's media ports for the purposes of key inf= ormation exchange
with the Key Distributor.
 
is worded like this:
 
Endpoints establish a DTLS-SRTP [RFC5764] associa= tion over the RTP
session with the media distributor and it's media= ports for the
purposes of key information exchange with the Key= Distributor.


Yep, sounds good. I changed "it's" t= o "its", but otherwise accepted your text as proposed.


Thanks

=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.=
com=0A=
----------------------------------------------------------------------



--_000_HE1PR0701MB2522CD96FDCB0F920CE2740F950A0HE1PR0701MB2522_--


From nobody Thu May 16 10:51:37 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECE812017A; Thu, 16 May 2019 10:51:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 3LBfHURMQx7j; Thu, 16 May 2019 10:51:29 -0700 (PDT)
Received: from smtp117.iad3b.emailsrvr.com (smtp117.iad3b.emailsrvr.com [146.20.161.117]) (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 B10C9120143; Thu, 16 May 2019 10:51:05 -0700 (PDT)
Received: from smtp15.relay.iad3b.emailsrvr.com (localhost [127.0.0.1]) by smtp15.relay.iad3b.emailsrvr.com (SMTP Server) with ESMTP id 4E5CDC0118; Thu, 16 May 2019 13:51:02 -0400 (EDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp15.relay.iad3b.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 9BE7AC01EF;  Thu, 16 May 2019 13:51:00 -0400 (EDT)
X-Sender-Id: fluffy@iii.ca
Received: from [192.168.4.53] ([UNAVAILABLE]. [128.107.241.161]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Thu, 16 May 2019 13:51:02 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_B3A4FEB2-F6CB-44E5-B953-2D1AA9F81D27"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Cullen Jennings 
In-Reply-To: 
Date: Thu, 16 May 2019 11:50:58 -0600
Cc: The IESG , IETF Crazy , "perc@ietf.org" , "draft-ietf-perc-private-media-framework@ietf.org" 
Message-Id: <46AFFB9F-8C9C-42B9-B9C8-39D774CC30C4@iii.ca>
References: <155786852996.30194.6992264311523885594.idtracker@ietfa.amsl.com>  
To: Magnus Westerlund 
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 May 2019 17:51:35 -0000

--Apple-Mail=_B3A4FEB2-F6CB-44E5-B953-2D1AA9F81D27
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On May 16, 2019, at 8:11 AM, Magnus Westerlund =
 wrote:
>=20
> Hi Cullen,
>=20
> On 2019-05-16 08:21, Cullen Jennings wrote:
>>=20
>>> On May 14, 2019, at 3:15 PM, Magnus Westerlund via Datatracker =
 wrote:
>>>=20
>>>=20
>>> A significant security vunerability in PERC that should be made more =
explicit
>>> and is totally missing is the risks with compromised endpoints. =
Beyond the very
>>> evident thing that this endpoint can decrypt all media it receives =
there are
>>> far more sinister risk here. Namely the potential for injection of =
media that
>>> attempts to impersonate another endpoints media stream. Most of =
SRTP's cipher
>>> suits only use symmetric crypto functions, thus enabling anyone with =
the key to
>>> send a packet with any SSRC, and have that being accepted as that =
source. Where
>>> it is has no practical usage in point to point communication, in =
conferencing
>>> it becomes an issue. It allows the usage of media level replay or =
deep fakes to
>>> be used to create media streams that are injected into the media =
distributors
>>> using an SSRC of another endpoint.
>>>=20
>>> The mitiagations that are missing from this document. The fact that =
a media
>>> distributor that is not compromised or collaborating with the =
compromised
>>> endpoint could actually prevent such media injection by applying =
source
>>> filtering of SSRCs and drop all that aren't associated with the =
endpoint. The
>>> other potential mitigation is to introduce another cipher suit that =
uses a non
>>> symmetric integrity protection mechanism, such as TESLA to prevent =
this type of
>>> injection.
>> And the related issue that the main way this can happen is attacker =
manipulation of the fingerprint so the providing ways to protect that =
along with SSRC based signalling or TELSA  is the obvious solution space =
to this. And just to frame the discussion, let me point out the issue =
you raise is not so much about an SSRC but binding the identity of a =
member of the group to the audio received.=20
>=20
> Yes, agree that the fundamental is to know which identity that create =
a
> particular packet. How that is accomplished there are many solutions.
>=20
>=20
>>=20
>> As other have pointed out, which member inside the conference the =
media is from is not something PERC provides any information about. Many =
existing conference systems have existing approaches to solve this =
problem and they can add PERC as a tool with out breaking theses so it =
to be specified here. Something that used TESLA could work fine with =
PERC as well. I do think future work can look at what we need for =
rosters and active speakers and how to use things like STIR and =
fingerprints and SDP to tie identity to the media. However, I think that =
problem is fairly separable from the issue of making sure the operator =
of the media switch does not have access to the media content.=20
>=20
> Yes, and to be clear I don't expect that base PERC solution should =
solve
> the issue. I only requested that the security properties that exist =
are
> made clear.=20

Yes, I agree with you that needs to be clear in the security section =
that PERC does not solve this. It=E2=80=99s a desirable property of a =
conferencing system so it would be bad if people expected it to be =
there.=20

>=20
> Regarding your below questions I will reply to that separately and it
> may take me a couple of days.
>=20

No problem, I totally understand theses things take some time to sort =
out. Thank you for looking into it.=20

> Cheers
>=20
> Magnus
>=20


--Apple-Mail=_B3A4FEB2-F6CB-44E5-B953-2D1AA9F81D27
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On May 16, 2019, at 8:11 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:

Hi Cullen,

On 2019-05-16 08:21, Cullen =
Jennings wrote:

On May 14, 2019, at 3:15 PM, Magnus Westerlund =
via Datatracker <noreply@ietf.org> wrote:


A significant security vunerability in PERC =
that should be made more explicit
and is totally missing =
is the risks with compromised endpoints. Beyond the very
evident thing that this endpoint can decrypt all media it =
receives there are
far more sinister risk here. Namely the =
potential for injection of media that
attempts to =
impersonate another endpoints media stream. Most of SRTP's cipher
suits only use symmetric crypto functions, thus enabling =
anyone with the key to
send a packet with any SSRC, and =
have that being accepted as that source. Where
it is has =
no practical usage in point to point communication, in conferencing
it becomes an issue. It allows the usage of media level =
replay or deep fakes to
be used to create media streams =
that are injected into the media distributors
using an =
SSRC of another endpoint.

The mitiagations =
that are missing from this document. The fact that a media
distributor that is not compromised or collaborating with the =
compromised
endpoint could actually prevent such media =
injection by applying source
filtering of SSRCs and drop =
all that aren't associated with the endpoint. The
other =
potential mitigation is to introduce another cipher suit that uses a =
non
symmetric integrity protection mechanism, such as =
TESLA to prevent this type of
injection.
And the related issue that the main way this can =
happen is attacker manipulation of the fingerprint so the providing ways =
to protect that along with SSRC based signalling or TELSA  is the =
obvious solution space to this. And just to frame the discussion, let me =
point out the issue you raise is not so much about an SSRC but binding =
the identity of a member of the group to the audio received. 

Yes, agree that the fundamental is to know which identity =
that create a
particular =
packet. How that is accomplished there are many solutions.



As other have pointed out, which member inside the conference =
the media is from is not something PERC provides any information about. =
Many existing conference systems have existing approaches to solve this =
problem and they can add PERC as a tool with out breaking theses so it =
to be specified here. Something that used TESLA could work fine with =
PERC as well. I do think future work can look at what we need for =
rosters and active speakers and how to use things like STIR and =
fingerprints and SDP to tie identity to the media. However, I think that =
problem is fairly separable from the issue of making sure the operator =
of the media switch does not have access to the media content. 

Yes, and to be clear I don't expect that base PERC solution =
should solve
the issue. I =
only requested that the security properties that exist are
made clear. 

Yes, I agree =
with you that needs to be clear in the security section that PERC does =
not solve this. It=E2=80=99s a desirable property of a conferencing =
system so it would be bad if people expected it to be =
there. 


Regarding your below questions I will reply to that =
separately and it
may take me a couple of days.


No problem, I totally understand theses things take =
some time to sort out. Thank you for looking into =
it. 

Cheers

Magnus


=

--Apple-Mail=_B3A4FEB2-F6CB-44E5-B953-2D1AA9F81D27--


From nobody Thu May 16 18:14:42 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC60120334; Thu, 16 May 2019 18:14:32 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 zAB6pojI9TYM; Thu, 16 May 2019 18:14:29 -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 A485612014B; Thu, 16 May 2019 18:14:29 -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=1558055664; bh=8vsWcQogJhA1SZbH9yVHSvRzhiolEu0J8gaylynXVh4=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=mMj0e20FlJvUk4+339K6t7OWcQzseO7ikSi/8kejHbe+HOg6WPtSTC0EpZYAmj0pT Ftf8fIZgAUTQ5k4tvSOmAH5zmMlhenR7/5RmW9B8LRuUlBE2siTB7ApJVdIc+5Xaws /taVLUewRpwgWAHcACtWlxbHHpGHvYfa19XNB5JU=
From: "Paul E. Jones" 
To: "Roman Danyliw" , "The IESG" 
Cc: nohlmeier@mozilla.com, perc-chairs@ietf.org, perc@ietf.org, draft-ietf-perc-private-media-framework@ietf.org
Date: Fri, 17 May 2019 01:14:21 +0000
Message-Id: 
In-Reply-To: <155797155680.30599.3634623355394252682.idtracker@ietfa.amsl.com>
References: <155797155680.30599.3634623355394252682.idtracker@ietfa.amsl.com>
Reply-To: "Paul E. Jones" 
User-Agent: eM_Client/7.2.34711.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MBE3DE109D-10AE-461E-9A00-FC793F42FA71"
Archived-At: 
Subject: Re: [Perc] Roman Danyliw's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 May 2019 01:14:33 -0000

--------=_MBE3DE109D-10AE-461E-9A00-FC793F42FA71
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Roman,

Thanks for reviewing the text.  Please see comments below:

>----------------------------------------------------------------------
>DISCUSS:
>----------------------------------------------------------------------
>
>I support Magnus=E2=80=99s DISCUSS about the need to further discuss the i=
mpact of a
>compromised/rogue end-point.  In addition to the impersonation of others i=
n the
>conference, I am wondering about the impact (perhaps a DoS?) of rogue clie=
nt
>flooding the conference with EKT Key updates.
>
ACK; will continue to work with Magnus on this.


>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>(1) Section 1.  Per =E2=80=9CVirtualized public cloud environments have be=
en viewed as
>less secure since resources are not always physically controlled by those=
 who
>use them and since there are usually several ports open to the public.  Th=
is
>document aims to improve security so as to lower the barrier to taking
>advantage of those environments=E2=80=9D, I stumbled over these sentences.=
  Improve
>security relative to what =E2=80=93 self hosted environments?  Is the secu=
rity target
>have fewer open ports and secure in the face of an adversary with physical
>access to the system?  The latter seems like a very high bar and the
>corresponding Security Considerations doesn=E2=80=99t seem to rise to that=
.

Improved security relative to traditional switching conferencing=20
platforms wherein there is a media function running on those virtualized=20
hardware platforms holding the keys to encrypt and decrypt media.

The number of open ports really doesn't make much difference, but I=20
think whoever crafted that text originally meant to emphasize how porous=20
those platforms can be. I think we could remove the bit about the open=20
ports and it would still convey the intended meaning. Want me to do=20
that?

With PERC, an adversary could do anything with the middlebox (even if=20
running in that cloud environment) and the confidentiality of the=20
conference would not be compromised. (PERC does not thwart DOS attacks,=20
but that's not an objective.)

How would you suggest we make that clearer?


>(2) Section 6.1.  =E2=80=9CEndpoints have to retain old keys for a period=
 of time to
>ensure they can properly decrypt late-arriving or out-of-order packets=E2=
=80=9D seems
>to restate what is stated in 4.5.2 using RFC2119 language.  Here =E2=80=9C=
endpoints
>have to retain=E2=80=9D.  In Section 4.5.2, =E2=80=9Cendpoints SHOULD reta=
in=E2=80=9D.  Which one is
>correct?

"have to" wasn't intended to be normative. The purpose of the sentence=20
was really to remind readers that there might be quite a few keys held=20
at any given point in time, especially when the conference is rekeyed.=20
But, I can see that wasn't clear. How about this text?

Complicating key management is the fact that the KEK can change and,=20
when
it does, the Endpoints generate new SRTP master keys that are associated=20
with
a new EKT SPI. Endpoints might retain old keys for a period of time to
ensure they can properly decrypt late-arriving or out-of-order packets,=20
which
means the number of keys held during that period of time might=20
substantially
more.


>(3) Section 8.1. Per =E2=80=9COff-path attackers could try connecting to d=
ifferent PERC
>entities and send specifically crafted packets=E2=80=9D, could you be more =
specific on
>the threat.  Is this something different than any service being exposed on =
the
>Internet?

This is saying that it's not possible for an attacker to send packets of=20
any form that could be misconstrued to be valid media that needs to be=20
forwarded or rendered since packets are authenticated before=20
consumption. (It doesn't prevent a DoS attack, but that's covered in=20
subsequent paragraphs.) But, I can see how this might not make sense. I=20
think a few more words are needed. How is this?

Off-path attackers could try connecting to different PERC entities to
send specifically crafted packets with an aim of forcing the receiver to
forward or render bogus media packets.  Endpoints and Media Distributors
mitigate such an attack by performing hop-by-hop authentication and
discarding packets that fail authentication.

>(4) Editorial Nits:
>** Section 3. Typo. s/the the/the/
>

Oh! An easy one! :)

I made those changes above to my local copy, but I'm happy to make=20
additional changes as you suggest if the text still isn't clear.

Thanks!
Paul

--------=_MBE3DE109D-10AE-461E-9A00-FC793F42FA71
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable




Roman,

Thanks for reviewing the=
 text. =C2=A0Please see comments below:



-----------------------------------------------------=
-----------------


DISCUSS:


-------------------------------------------------=
---------------------


=C2=A0


I support Magnus=E2=80=99s DISCUSS about the need =
to further discuss the impact of a


compromised/rogue end-point.  In addition to the=
 impersonation of others in the


conference, I am wondering about the impact (perh=
aps a DoS?) of rogue client


flooding the conference with EKT Key updates.


ACK; will continue to work with Magnus on this.


----------------------------------------------------=
------------------


COMMENT:


-------------------------------------------------=
---------------------


=C2=A0


(1) Section 1.  Per =E2=80=9CVirtualized public c=
loud environments have been viewed as


less secure since resources are not always physic=
ally controlled by those who


use them and since there are usually several port=
s open to the public.  This


document aims to improve security so as to lower=
 the barrier to taking


advantage of those environments=E2=80=9D, I stumb=
led over these sentences.  Improve


security relative to what =E2=80=93 self hosted e=
nvironments?  Is the security target


have fewer open ports and secure in the face of a=
n adversary with physical


access to the system?  The latter seems like a ve=
ry high bar and the


corresponding Security Considerations doesn=E2=80=
=99t seem to rise to that.
<=
br />
Improved security relative to tradi=
tional switching conferencing platforms wherein there is a media function r=
unning on those virtualized hardware platforms holding the keys to encrypt=
 and decrypt media.

The number of open ports really doesn't make much differ=
ence, but I think whoever crafted that text originally meant to emphasize h=
ow porous those platforms can be. I think we could remove the bit about the =
open ports and it would still convey the intended meaning.  Want me to do=
 that?

With PERC, an adversary could do anything with the middlebox (even if =
running in that cloud environment) and the confidentiality of the conferen=
ce would not be compromised. (PERC does not thwart DOS attacks, but that's=
 not an objective.)

How would you suggest we make that clearer?


(2) Section 6.1.  =E2=80=9CEndpoints have=
 to retain old keys for a period of time to


ensure they can properly decrypt late-arriving or =
out-of-order packets=E2=80=9D seems


to restate what is stated in 4.5.2 using RFC2119=
 language.  Here =E2=80=9Cendpoints


have to retain=E2=80=9D.  In Section 4.5.2, =E2=
=80=9Cendpoints SHOULD retain=E2=80=9D.  Which one is


correct?

"have to" wasn't intended t=
o be normative. The purpose of the sentence was really to remind readers th=
at there might be quite a few keys held at any given point in time, especia=
lly when the conference is rekeyed.  But, I can see that wasn't clear.  How =
about this text?

Complicating key management is the fact that the KEK can change and, w=
hen
it does, the Endpoints generate new SRTP master keys that are assoc=
iated with
a new EKT SPI.  Endpoints might retain old keys for a period =
of time to
ensure they can properly decrypt late-arriving or out-of-or=
der packets, which
means the number of keys held during that period of=
 time might substantially
more.


(3) Section 8.1. Per =E2=80=
=9COff-path attackers could try connecting to different PERC


entities and send specifically crafted packets=E2=
=80=9D, could you be more specific on


the threat.  Is this something different than any =
service being exposed on the


Internet?

This is saying that it's n=
ot possible for an attacker to send packets of any form that could be misco=
nstrued to be valid media that needs to be forwarded or rendered since pack=
ets are authenticated before consumption.  (It doesn't prevent a DoS attack=
, but that's covered in subsequent paragraphs.)  But, I can see how this mi=
ght not make sense.  I think a few more words are needed.  How is this?

Off-path atta=
ckers could try connecting to different PERC entities to
send specific=
ally crafted packets with an aim of forcing the receiver to
forward or =
render bogus media packets.=C2=A0 Endpoints and Media Distributors<=
/div>
mitigate such an attack by performing hop-by-hop au=
thentication and
discarding packets that fai=
l authentication.

(4) E=
ditorial Nits:


** Section 3. Typo. s/the the/the/




Oh!  An easy one! :)

I made t=
hose changes above to my local copy, but I'm happy to make additional chang=
es as you suggest if the text still isn't clear.

Thanks!
Paul



--------=_MBE3DE109D-10AE-461E-9A00-FC793F42FA71--


From nobody Thu May 16 19:10:14 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A266F120340; Thu, 16 May 2019 19:10:05 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 7VaPKAqx9I3D; Thu, 16 May 2019 19:10:02 -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 55E611200B6; Thu, 16 May 2019 19:10:02 -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=1558058996; bh=WTfD82ed891EATjZYRyat7zRmUBRkbrWvjeaxrIuMeg=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=ZpecWrlJNdp4u8ieS156nTxo0zOuN2ivfmZDGyn3dkRSE2rN7aPjfKBGEs0T6GQJD yCOmAihOMw6AkHO5R0JHEm883sRq/5Q6Hu1S0jEaq94TPPTZM7zOLBZ+Oq80RiSa5i 40LBhJLYtOuUhlya1xeSzx1qLyj8Sv7usY7hVQV0=
From: "Paul E. Jones" 
To: "Magnus Westerlund" , "The IESG" 
Cc: "nohlmeier@mozilla.com" , "draft-ietf-perc-private-media-framework@ietf.org" , "perc@ietf.org" , "perc-chairs@ietf.org" 
Date: Fri, 17 May 2019 02:09:52 +0000
Message-Id: 
In-Reply-To: 
References: <155786852996.30194.6992264311523885594.idtracker@ietfa.amsl.com>  
Reply-To: "Paul E. Jones" 
User-Agent: eM_Client/7.2.34711.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MB30CFD0CE-6878-46AE-AE21-96FAF35D3986"
Archived-At: 
Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 May 2019 02:10:06 -0000

--------=_MB30CFD0CE-6878-46AE-AE21-96FAF35D3986
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Magnus,

>>
>>How about this as a new section?
>>
>>
>>## Endpoint Attacks
>>
>>A Trusted Endpoint is so named because conference confidentiality=20
>>relies
>>heavily on the security and integrity of the Endpoint. If an adversary
>>successfully exploits a vulnerability in an Endpoint, it might be=20
>>possible
>>for the adversary to obtain all of the keying material used in the
>>conference. With that keying material, an adversary could decrypt any
>>of the media flows received from any other Endpoint, either in=20
>>real-time
>>or at a later point in time (assuming the adversary makes a copy of=20
>>the
>>media packets).
>>
>>Additionally, if an adversary successfully exploits an Endpoint, the
>>adversary could inject media into the conference. One way an adversary
>>could do that is by manipulating the RTP or SRTP software to transmit=20
>>to
>>whatever media the adversary wishes to send. This could involve
>>re-use of the Endpoint's SSRC, a new SSRC, or the SSRC value of an=20
>>existing
>>endpoint..
>>
>>However, attacks on the endpoint are not limited to the PERC-specific
>>software within the Endpoint. An attacker could inject media or record
>>media by manipulating the software that sits between the PERC-enabled
>>application and the hardware microphone of video camera, for example.
>>Likewise, an attacker could potentially access confidential media by
>>accessing memory, cache, disk storage, etc. if the endpoint is no=20
>>secured.
>I think this is mostly good, however not particular specific on the=20
>security properties of the system that the framework creates, that is=20
>dependent on the realization of the authentication tag added to the=20
>packet. So, the impersonation issue that are alluded is only possible=20
>given that there a no solution that allows specific identity assertions=20
>on a per packet basis.
>

Yeah, PERC doesn't offer a defense against impersonation since there is=20
no assignment of SSRC or sharing of user info or user-level auth info=20
with other conference participants.  The assumption is that the=20
endpoints are trusted and would not attempt to impersonate.  But, you=20
made a valid point that we need to highlight that weakness.  I tried to=20
make that clear by pointing out that a compromised endpoint could inject=20
media in a variety of ways.

Do you have suggestions for other words or more words to clarify this?


>>
>>>----------------------------------------------------------------------
>>>COMMENT:
>>>----------------------------------------------------------------------
>>>
>>>In addition I would appreciate if you really consider these issues, espe=
cially
>>>A and B.
>>>
>>>A. I think the relationship between the media distributors and the key
>>>distributor needs to be clarified either already in section 3 or in 4. T=
he fact
>>>that the key distributor needs to know the full set or their group ident=
ity of
>>>the media distributors to prevent impostering media distributors. That n=
eed is
>>>not made clear early enough, only by the end of the security considerati=
on
>>>section is is made clear that this is the fact. I think it should be sta=
ted
>>>explicitly early on.
>>
>>I would suggest a new paragraph at the end of 3.2.2 as follows:
>>
>>They Key Distributor needs to know which Endpoints and which Media
>>Distributors are authorized to participate in the conference.  How the
>>Key Distributor obtains this information is outside the scope of this
>>document.  However, Key Distributors **MUST** reject DTLS associations
>>with any unauthorized Endpoint of Media Distributor.
>Looks okay, I assume of/or.
>

Cool, thanks... fixed that.

>>
>>The relationship between these entities in terms of roster,=20
>>certificates, identity, etc. are outside the scope of the framework.
>>
>>>B. Similar the endpoints relation to the key distributor also needs to b=
e
>>>clarified. Also, here diving into potential solutions in Section 5 witho=
ut
>>>making clear why this very fundamental requirement is needed is far from
>>>optimal. Also here I think discussion in Section 3 or 4 would be good of =
their
>>>relationship. Especially as this is really relying on mechanism outside=
 of the
>>>PERC framework. Thus, such requirements should be very explicit stated a=
nd
>>>motivated.
>>
>>I think the above additional text should address this concern, too.=20
>>However, it is probably important to keep in mind that PERC can work=20
>>with many different types of conferences architectures and these=20
>>associations is deliberately out scope as the PERC framework for this=20
>>reason.
>Yes, the above text do address the comment.
>

Good.

>
>
>>
>>
>>>C. Section 4.3:
>>>
>>>If there is a need to encrypt one or more RTP header extensions end-
>>>to-end, the endpoint derives an encryption key from the E2E SRTP
>>>master key to encrypt header extensions as per [RFC6904]. The Media
>>>Distributor is unable use the information contained in those header
>>>extensions encrypted with an E2E key.
>>>
>>>As RFC 6904 works on type of header extensions, all header extensions of
>>>that type need to be encrypted independent of sender, that could be made
>>>clearer.
>>
>>I do not understand what you're saying here. The sender will create an=20
>>encrypted stream and then AND that with the mask created over the=20
>>header extensions. The mask will be over whatever extensions the=20
>>sender wants to encrypt. There's nothing different in PERC from what=20
>>is in RFC 6904.
>Yes, you are correct that this is an inherent property of RFC 6904 in=20
>that one defines on header extension ID level if it is to be encrypted=20
>or not.. In the PERC situation it is not clear how one determines which=20
>should be end-to-end encrypted and which are only hop-by-hop. I think=20
>the later should normally be all header extensions. After having read=20
>double that fails to define how one performs the end-to-end encryption=20
>of header extensions I think there are more to dig into here.
>
>So, one issue is clearly signalling that a particular type of header=20
>extensions are to be end-to-end encrypted.
>

Oh, I see why there is confusion.  There are two things here and some=20
erroneous residual text in the framework:

1) What is to be encrypted - that's outside the scope of PERC. Whatever=20
signaling mechanism used with PERC will dictate this.

2) How is it done - the draft has an error.  Double (and therefore PERC)=20
only allows HBH encryption of header extensions, but the framework still=20
talks about both E2E and HBH (which was an original objective).  I've=20
made some changes to clarify this.  Further, the details of how to=20
encrypt/decrypt are only described in Double, so I've made a reference=20
to that draft in the HBH Operations part of Framework.  (Double is still=20
high level in that regard, but I think Sections 5.1 - 5.3 of Double will=20
make sense now knowing that extensions are encrypted only HBH.)

Paul

>>Can you clarify what you are looking for here?
>>
>>>D. Section 4.5:
>>>
>>>o The E2E key that an endpoint uses to send SRTP media can either be
>>>set from DTLS or chosen by the endpoint.
>>>
>>>I think "set from DTLS" should be changed to make it clear that the
>>>DTLS is with the Key Distributor.
>>
>>I changed my local text to say that.
>
>
>Great!
>
>>
>>
>>>E. Section 4.5.1:
>>>
>>>Wouldn't this sentence be clearer:
>>>
>>>Endpoints establish a DTLS-SRTP [RFC5764] association over the RTP
>>>session's media ports for the purposes of key information exchange
>>>with the Key Distributor.
>>>
>>>is worded like this:
>>>
>>>Endpoints establish a DTLS-SRTP [RFC5764] association over the RTP
>>>session with the media distributor and it's media ports for the
>>>purposes of key information exchange with the Key Distributor.
>>>
>>
>>Yep, sounds good. I changed "it's" to "its", but otherwise accepted=20
>>your text as proposed.
>
>
>Thanks
>
>Magnus Westerlund
>
>----------------------------------------------------------------------
>Network Architecture & Protocols, Ericsson Research
>----------------------------------------------------------------------
>Ericsson AB                 | Phone  +46 10 7148287
>Torshamnsgatan 23           | Mobile +46 73 0949079
>SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>----------------------------------------------------------------------
--------=_MB30CFD0CE-6878-46AE-AE21-96FAF35D3986
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable





Magnus,








How about this as a new section?












## Endpo=
int Attacks







A Truste=
d Endpoint is so named because conference confidentiality relies

heavily=
 on the security and integrity of the Endpoint. If an adversary


successf=
ully exploits a vulnerability in an Endpoint, it might be possible

for the=
 adversary to obtain all of the keying material used in the


conferen=
ce. With that keying material, an adversary could decrypt any


of the m=
edia flows received from any other Endpoint, either in real-time

or at a=
 later point in time (assuming the adversary makes a copy of the

media pa=
ckets).







Addition=
ally, if an adversary successfully exploits an Endpoint, the


adversar=
y could inject media into the conference. One way an adversary


could do =
that is by manipulating the RTP or SRTP software to transmit to

whatever =
media the adversary wishes to send. This could involve


re-use o=
f the Endpoint's SSRC, a new SSRC, or the SSRC value of an existing<=
/div>

endpoint=
..







However, =
attacks on the endpoint are not limited to the PERC-specific


software =
within the Endpoint. An attacker could inject media or record


media by =
manipulating the software that sits between the PERC-enabled


applicat=
ion and the hardware microphone of video camera, for example.


Likewise=
, an attacker could potentially access confidential media by


accessin=
g memory, cache, disk storage, etc. if the endpoint is no secured.





I think this is mostly good, however not particular specific on the secu=
rity properties of the system that the framework creates, that is dependent =
on the realization of the authentication tag added to the packet. So, the=
 impersonation issue that are alluded
 is only possible given that there a no solution that allows specific ident=
ity assertions on a per packet basis.




Yeah, PERC doesn't offer a defense agains=
t impersonation since there is no assignment of SSRC or sharing of user inf=
o or user-level auth info with other conference participants. =C2=A0The ass=
umption is that the endpoints are trusted and would not attempt to imperson=
ate. =C2=A0But, you made a valid point that we need to highlight that weakn=
ess. =C2=A0I tried to make that clear by pointing out that a compromised en=
dpoint could inject media in a variety of ways.

Do yo=
u have suggestions for other words or more words to clarify this?









-------------------------------------------------=
---------------------


COMMENT:


-------------------------------------------------=
---------------------


=C2=A0


In addition I would appreciate if you really cons=
ider these issues, especially


A and B.


=C2=A0


A. I think the relationship between the media dis=
tributors and the key


distributor needs to be clarified either already=
 in section 3 or in 4. The fact


that the key distributor needs to know the full s=
et or their group identity of


the media distributors to prevent impostering med=
ia distributors. That need is


not made clear early enough, only by the end of t=
he security consideration


section is is made clear that this is the fact. I =
think it should be stated


explicitly early on.









I would suggest a new paragraph at the end of=
 3.2.2 as follows:







They Key Distributor needs to know whic=
h Endpoints and which Media


Distributors are authorized to participate in the confer=
ence.=C2=A0 How the

Key Distributor obtains this information is outside the scope of this

document.=C2=A0 However, Key Distributors **MUST** reject DTLS associations=


with any unauthorized Endpoint of Media Distributor.






Looks okay, I assume of/or.<=
br />


Cool, thanks... fixed that.






The relationship between these entities in ter=
ms of roster, certificates, identity, etc. are outside the scope of the fra=
mework.









B. Similar the endpoints relation to the key dist=
ributor also needs to be


clarified. Also, here diving into potential solut=
ions in Section 5 without


making clear why this very fundamental requiremen=
t is needed is far from


optimal. Also here I think discussion in Section=
 3 or 4 would be good of their


relationship. Especially as this is really relyin=
g on mechanism outside of the


PERC framework. Thus, such requirements should be =
very explicit stated and


motivated.









I think the above additional text should addre=
ss this concern, too. However, it is probably important to keep in mind tha=
t PERC can work with many different types of conferences architectures and=
 these associations is deliberately
 out scope as the PERC framework for this reason.






Yes, the above text do address the comment. 



Good.


=
















C. Section 4.3:


=C2=A0


If there is a need to encrypt one or more RTP hea=
der extensions end-


to-end, the endpoint derives an encryption key fr=
om the E2E SRTP


master key to encrypt header extensions as per [R=
FC6904]. The Media


Distributor is unable use the information contain=
ed in those header


extensions encrypted with an E2E key.


=C2=A0


As RFC 6904 works on type of header extensions, a=
ll header extensions of


that type need to be encrypted independent of sen=
der, that could be made


clearer.









I do not understand what you're saying here. T=
he sender will create an encrypted stream and then AND that with the mask c=
reated over the header extensions. The mask will be over whatever extension=
s the sender wants to encrypt. There's
 nothing different in PERC from what is in RFC 6904.






Yes, you are correct that this is an inherent property of RFC 6904 in th=
at one defines on header extension ID level if it is to be encrypted or not=
.. In the PERC situation it is not clear how one determines which should be =
end-to-end encrypted and which are
 only hop-by-hop. I think the later should normally be all header extension=
s. After having read double that fails to define how one performs the end-t=
o-end encryption of header extensions I think there are more to dig into he=
re.





So, one issue is clearly signalling that a particular type of header ext=
ensions are to be end-to-end encrypted.=C2=A0

Oh, I see why there is confusion. =C2=A0There are two things here and =
some erroneous residual text in the framework:

1) Wh=
at is to be encrypted - that's outside the scope of PERC. Whatever signalin=
g mechanism used with PERC will dictate this.

2) How=
 is it done - the draft has an error. =C2=A0Double (and therefore PERC) only =
allows HBH encryption of header extensions, but the framework still talks=
 about both E2E and HBH (which was an original objective). =C2=A0I've made s=
ome changes to clarify this. =C2=A0Further, the details of how to encrypt/d=
ecrypt are only described in Double, so I've made a reference to that draft =
in the HBH Operations part of Framework. =C2=A0(Double is still high level =
in that regard, but I think Sections 5.1 - 5.3 of Double will make sense n=
ow knowing that extensions are encrypted only HBH.)

P=
aul

Can you clarify what you are looking for here?









D. Section 4.5:


=C2=A0


o The E2E key that an endpoint uses to send SRTP=
 media can either be


set from DTLS or chosen by the endpoint.


=C2=A0


I think "set from DTLS" should be changed to make =
it clear that the


DTLS is with the Key Distributor.=C2=A0









I changed my local text to say that.











Great!

















E. Section 4.5.1:


=C2=A0


Wouldn't this sentence be clearer:


=C2=A0


Endpoints establish a DTLS-SRTP [RFC5764] associa=
tion over the RTP


session's media ports for the purposes of key inf=
ormation exchange


with the Key Distributor.


=C2=A0


is worded like this:


=C2=A0


Endpoints establish a DTLS-SRTP [RFC5764] associa=
tion over the RTP


session with the media distributor and it's media =
ports for the


purposes of key information exchange with the Key =
Distributor.














Yep, sounds good. I changed "it's" to "its", b=
ut otherwise accepted your text as proposed.











Thanks




Magnus Westerlund=20

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.=
com
----------------------------------------------------------------------





--------=_MB30CFD0CE-6878-46AE-AE21-96FAF35D3986--


From nobody Fri May 17 07:22:37 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FC3120044; Fri, 17 May 2019 07:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.029
X-Spam-Level: 
X-Spam-Status: No, score=-1.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 uorfPOWUgnu6; Fri, 17 May 2019 07:22:32 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10056.outbound.protection.outlook.com [40.107.1.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C98BC12012A; Fri, 17 May 2019 07:22:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BEbmM4gTtIYH8g0vIjw6Eb9wJFI62S3qGuP5/RD8AL0=; b=rWQDZvftbz9YcubFwR1ZwqXOeQ8ivtZaajGugAoAjLFg9mW65vLw+j8Ju+bBR0ieTYLNP8uE4vbUaDMGDxhCIYLNGTPidGg7ATYeSI+3ES1zhOqyzTOmgmnXaW2DuedFSsLVkV6/prYVX9pf5Nxbxi7mX9dZ2sGvgSvCnJC46+w=
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2281.eurprd07.prod.outlook.com (10.168.29.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.11; Fri, 17 May 2019 14:22:28 +0000
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::896a:7ada:8bc9:d99d]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::896a:7ada:8bc9:d99d%6]) with mapi id 15.20.1900.010; Fri, 17 May 2019 14:22:28 +0000
From: Magnus Westerlund 
To: "Paul E. Jones" , The IESG 
CC: "nohlmeier@mozilla.com" , "draft-ietf-perc-private-media-framework@ietf.org" , "perc@ietf.org" , "perc-chairs@ietf.org" 
Thread-Topic: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)
Thread-Index: AQHVDLv05Xj4KxTpkE2ssVAnd4w1Bg==
Date: Fri, 17 May 2019 14:22:28 +0000
Message-ID: 
References: <155786852996.30194.6992264311523885594.idtracker@ietfa.amsl.com>   
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; 
x-originating-ip: [192.176.1.81]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 146424a9-06ce-4d60-4c29-08d6dad31754
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2281; 
x-ms-traffictypediagnostic: HE1PR0701MB2281:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0040126723
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(396003)(366004)(136003)(52314003)(51444003)(189003)(199004)(55016002)(44832011)(6246003)(9686003)(229853002)(476003)(33656002)(64756008)(66556008)(76176011)(14454004)(236005)(99286004)(66446008)(446003)(71190400001)(86362001)(486006)(6116002)(3846002)(54896002)(6436002)(66476007)(4326008)(66946007)(7696005)(68736007)(71200400001)(76116006)(73956011)(5660300002)(2906002)(66066001)(26005)(186003)(7736002)(74316002)(81166006)(14444005)(256004)(81156014)(8676002)(8936002)(6506007)(53936002)(316002)(102836004)(53546011)(52536014)(508600001)(54906003)(25786009)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2281; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: qfPWdtmAhWBX9mLc4qYWm7IRJaBKGachwZsYk7CaYspWwG0WE3/NY5v58ayOUtSCB5W5e5KJz6FNwFW0ZYOjzL5eg4Mq7yA3+nDwcs61JNC4YZvQGu2qCJhwx4uDoWesttX/K2JgzJJp/89aBoMdSmMirkLHry1fiNfcH55/pQZf+AJnbg9MBtxx+Mk4kgyyuMgpHwGAoGAkV5I/18X/Nkvbcbhrpi6SMviGJsbsYfr1sHeoXPdoNBTBxdmhJSZNEgX0Ka+zTSk5YXHdA+u1vyMxCeZwSK/qxB/fD8+WN5hpOAopgUNQ6HJnRDtgtaEqP1wIK51OOnkJc8fVRbi3LLGHhcW3sNh4V6V0I/xXIo0azG+yqoFQw62FovOU+/dEHF0Cj/h5jSTYImCUu/B/aRZZFkxU7yczi8C0zoVtkns=
Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB25225ED31452D0FCC2787500950B0HE1PR0701MB2522_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 146424a9-06ce-4d60-4c29-08d6dad31754
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2019 14:22:28.2217 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2281
Archived-At: 
Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 May 2019 14:22:36 -0000

--_000_HE1PR0701MB25225ED31452D0FCC2787500950B0HE1PR0701MB2522_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

On 2019-05-17 04:10, Paul E. Jones wrote:
Magnus,


How about this as a new section?


## Endpoint Attacks

A Trusted Endpoint is so named because conference confidentiality relies
heavily on the security and integrity of the Endpoint. If an adversary
successfully exploits a vulnerability in an Endpoint, it might be possible
for the adversary to obtain all of the keying material used in the
conference. With that keying material, an adversary could decrypt any
of the media flows received from any other Endpoint, either in real-time
or at a later point in time (assuming the adversary makes a copy of the
media packets).

Additionally, if an adversary successfully exploits an Endpoint, the
adversary could inject media into the conference. One way an adversary
could do that is by manipulating the RTP or SRTP software to transmit to
whatever media the adversary wishes to send. This could involve
re-use of the Endpoint's SSRC, a new SSRC, or the SSRC value of an existing
endpoint..

However, attacks on the endpoint are not limited to the PERC-specific
software within the Endpoint. An attacker could inject media or record
media by manipulating the software that sits between the PERC-enabled
application and the hardware microphone of video camera, for example.
Likewise, an attacker could potentially access confidential media by
accessing memory, cache, disk storage, etc. if the endpoint is no secured.

I think this is mostly good, however not particular specific on the securit=
y properties of the system that the framework creates, that is dependent on=
 the realization of the authentication tag added to the packet. So, the imp=
ersonation issue that are alluded is only possible given that there a no so=
lution that allows specific identity assertions on a per packet basis.

Yeah, PERC doesn't offer a defense against impersonation since there is no =
assignment of SSRC or sharing of user info or user-level auth info with oth=
er conference participants.  The assumption is that the endpoints are trust=
ed and would not attempt to impersonate.  But, you made a valid point that =
we need to highlight that weakness.  I tried to make that clear by pointing=
 out that a compromised endpoint could inject media in a variety of ways.

Do you have suggestions for other words or more words to clarify this?

Maybe if the second paragraph is somewhat expanded:

Additionally, if an adversary successfully exploits an Endpoint, the
adversary could inject media into the conference. One way an adversary
could do that is by manipulating the RTP or SRTP software to transmit to
whatever media the adversary wishes to send. This could involve
re-use of the Endpoint's SSRC, a new SSRC, or the SSRC value of an existing

endpoint. So far only a single SRTP cipher suits defined provides source au=
thentication properties that allow an endpoint to cryptographically assert =
that it sent a particular E2E protected packet. Instead, the common propert=
y is that one can determine only that any endpoint that has received the KE=
K has produced the packet.






C. Section 4.3:

If there is a need to encrypt one or more RTP header extensions end-
to-end, the endpoint derives an encryption key from the E2E SRTP
master key to encrypt header extensions as per [RFC6904]. The Media
Distributor is unable use the information contained in those header
extensions encrypted with an E2E key.

As RFC 6904 works on type of header extensions, all header extensions of
that type need to be encrypted independent of sender, that could be made
clearer.

I do not understand what you're saying here. The sender will create an encr=
ypted stream and then AND that with the mask created over the header extens=
ions. The mask will be over whatever extensions the sender wants to encrypt=
. There's nothing different in PERC from what is in RFC 6904.

Yes, you are correct that this is an inherent property of RFC 6904 in that =
one defines on header extension ID level if it is to be encrypted or not.. =
In the PERC situation it is not clear how one determines which should be en=
d-to-end encrypted and which are only hop-by-hop. I think the later should =
normally be all header extensions. After having read double that fails to d=
efine how one performs the end-to-end encryption of header extensions I thi=
nk there are more to dig into here.

So, one issue is clearly signalling that a particular type of header extens=
ions are to be end-to-end encrypted.

Oh, I see why there is confusion.  There are two things here and some erron=
eous residual text in the framework:

1) What is to be encrypted - that's outside the scope of PERC. Whatever sig=
naling mechanism used with PERC will dictate this.

>From my perspective it is up to the framework to discuss what needs to be e=
ncrypted in RTP to achieve the properties described by the framework. Actua=
lly I think it is unfortunate that PERC fails to provide E2E authentication=
 of certain header extensions, and also end-to-end encryption. However, tha=
t is the WG's decision but I think that choice and the perils of that shoul=
d be well documented.

2) How is it done - the draft has an error.  Double (and therefore PERC) on=
ly allows HBH encryption of header extensions, but the framework still talk=
s about both E2E and HBH (which was an original objective).  I've made some=
 changes to clarify this.  Further, the details of how to encrypt/decrypt a=
re only described in Double, so I've made a reference to that draft in the =
HBH Operations part of Framework.  (Double is still high level in that rega=
rd, but I think Sections 5.1 - 5.3 of Double will make sense now knowing th=
at extensions are encrypted only HBH.)


Double could easily support it, however it does require a signalling either=
 inband or outband so that all end-points and the MD know which header exte=
nsions that it applies to. I think that signalling may be the bigger hurdle=
 here, rather than double.

Anyway, the fact that there are neither possible to have E2E authentication=
 nor encryption of header extension are potentially problematic. Looking at=
 the available header extension several of them are of the nature that they=
 should at least be E2E source authenticated. Those that I see no reason fo=
r an MD to change are:

urn:ietf:params:rtp-hdrext:smpte-tc SMPTE time-code mapping

urn:3gpp:video-orientation Coordination of video orientation (CVO) feature,=
 see clause 6.2.3

urn:3gpp:video-orientation:6 Higher granularity (6-bit) coordination of vid=
eo orientation (CVO) feature, see clause 6.2.3

urn:3gpp:roi-sent Signalling of the arbitrary region-of-interest (ROI) info=
rmation for the sent video, see clause 6.2.3.4

urn:3gpp:predefined-roi-sent Signalling of the predefined region-of-interes=
t (ROI) information for the sent video, see clause 6.2.3.4

These are all meta data directly associated with the media sent, can affect=
 how it is presented at the receiver. These should be expected to be passed=
 through a PERC system unchanged. However, the PERC proponents use case wou=
ld normally not see these being used. Also I would not be surprised over fu=
ture extensions with that property or at least proprietary extensions.

The set of header extensions that are related to how the endpoint bind and =
use the RTP Streams it receives, such as CNAME, rtp-stream-id, CaptId and m=
id are really hard to protect and be efficient at the same time as they are=
 expected to be added when switching RTP streams.

Anyway I understand the choice to some degree. But I think the framework sh=
ould discuss the possible need for E2E protection, and the risks of not pro=
viding it in DOUBLE.

Cheers


Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

--_000_HE1PR0701MB25225ED31452D0FCC2787500950B0HE1PR0701MB2522_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







On 2019-05-17 04:10, Paul E. Jones wrote:






Magnus,




















How about this as a new section?












## Endpoint Attacks







A Trusted Endpoint is so named because conference co=
nfidentiality relies


heavily on the security and integrity of the Endpoin=
t. If an adversary


successfully exploits a vulnerability in an Endpoint=
, it might be possible


for the adversary to obtain all of the keying materi=
al used in the


conference. With that keying material, an adversary =
could decrypt any


of the media flows received from any other Endpoint,=
 either in real-time


or at a later point in time (assuming the adversary =
makes a copy of the


media packets).







Additionally, if an adversary successfully exploits =
an Endpoint, the


adversary could inject media into the conference. On=
e way an adversary


could do that is by manipulating the RTP or SRTP sof=
tware to transmit to


whatever media the adversary wishes to send. This co=
uld involve


re-use of the Endpoint's SSRC, a new SSRC, or the SS=
RC value of an existing


endpoint..







However, attacks on the endpoint are not limited to =
the PERC-specific


software within the Endpoint. An attacker could inje=
ct media or record


media by manipulating the software that sits between=
 the PERC-enabled


application and the hardware microphone of video cam=
era, for example.


Likewise, an attacker could potentially access confi=
dential media by


accessing memory, cache, disk storage, etc. if the e=
ndpoint is no secured.






I think this is mostly good, however not particular specific on the secu=
rity properties of the system that the framework creates, that is dependent=
 on the realization of the authentication tag added to the packet. So, the =
impersonation issue that are alluded
 is only possible given that there a no solution that allows specific ident=
ity assertions on a per packet basis.












Yeah, PERC doesn't offer a defense =
against impersonation since there is no assignment of SSRC or sharing of us=
er info or user-level auth info with other conference participants.  T=
he assumption is that the endpoints are trusted
 and would not attempt to impersonate.  But, you made a valid point th=
at we need to highlight that weakness.  I tried to make that clear by =
pointing out that a compromised endpoint could inject media in a variety of=
 ways.







Do you have suggestions for other w=
ords or more words to clarify this?






Maybe if the second paragraph is somewhat expanded:


Addition=
ally, if an adversary successfully exploits an Endpoint, the


adversar=
y could inject media into the conference. One way an adversary


could do=
 that is by manipulating the RTP or SRTP software to transmit to

whatever=
 media the adversary wishes to send. This could involve


re-use o=
f the Endpoint's SSRC, a new SSRC, or the SSRC value of an existing<=
/div>

endpoint. So far only a single SRT=
P cipher suits defined provides source authentication properties that allow=
 an endpoint to cryptographically assert that it sent a particular E2E prot=
ected packet. Instead, the common property
 is that one can determine only that any endpoint that has received the KEK=
 has produced the packet.







































C. Section 4.3:


 


If there is a need to encrypt one or more RTP hea=
der extensions end-


to-end, the endpoint derives an encryption key fr=
om the E2E SRTP


master key to encrypt header extensions as per [R=
FC6904]. The Media


Distributor is unable use the information contain=
ed in those header


extensions encrypted with an E2E key.


 


As RFC 6904 works on type of header extensions, a=
ll header extensions of


that type need to be encrypted independent of sen=
der, that could be made


clearer.









I do not understand what you're saying here. T=
he sender will create an encrypted stream and then AND that with the mask c=
reated over the header extensions. The mask will be over whatever extension=
s the sender wants to encrypt. There's
 nothing different in PERC from what is in RFC 6904.






Yes, you are correct that this is an inherent property of RFC 6904 in th=
at one defines on header extension ID level if it is to be encrypted or not=
.. In the PERC situation it is not clear how one determines which should be=
 end-to-end encrypted and which
 are only hop-by-hop. I think the later should normally be all header exten=
sions. After having read double that fails to define how one performs the e=
nd-to-end encryption of header extensions I think there are more to dig int=
o here.





So, one issue is clearly signalling that a particular type of header ext=
ensions are to be end-to-end encrypted. 









Oh, I see why there is confusion. &=
nbsp;There are two things here and some erroneous residual text in the fram=
ework:







1) What is to be encrypted - that's=
 outside the scope of PERC. Whatever signaling mechanism used with PERC wil=
l dictate this.






From my perspective it is up to the framework to discuss what needs to b=
e encrypted in RTP to achieve the properties described by the framework. Ac=
tually I think it is unfortunate that PERC fails to provide E2E authenticat=
ion of certain header extensions,
 and also end-to-end encryption. However, that is the WG's decision but I t=
hink that choice and the perils of that should be well documented.














2) How is it done - the draft has a=
n error.  Double (and therefore PERC) only allows HBH encryption of he=
ader extensions, but the framework still talks about both E2E and HBH (whic=
h was an original objective).  I've made
 some changes to clarify this.  Further, the details of how to encrypt=
/decrypt are only described in Double, so I've made a reference to that dra=
ft in the HBH Operations part of Framework.  (Double is still high lev=
el in that regard, but I think Sections 5.1
 - 5.3 of Double will make sense now knowing that extensions are encrypted =
only HBH.)











Double could easily support it, however it does require a signalling eit=
her inband or outband so that all end-points and the MD know which header e=
xtensions that it applies to. I think that signalling may be the bigger hur=
dle here, rather than double.





Anyway, the fact that there are neither possible to have E2E authenticat=
ion nor encryption of header extension are potentially problematic. Looking=
 at the available header extension several of them are of the nature that t=
hey should at least be E2E source
 authenticated. Those that I see no reason for an MD to change are: 




urn:ietf:params:rtp-hdrext:smpte-tc SMPTE time-code mapping


urn:3gpp:video-orientation Coordination of video orientation (CVO) featu=
re, see clause 6.2.3


urn:3gpp:video-orientation:6 Higher granularity (6-bit) coordination of =
video orientation (CVO) feature, see clause 6.2.3


urn:3gpp:roi-sent Signalling of the arbitrary region-of-interest (ROI) i=
nformation for the sent video, see clause 6.2.3.4


urn:3gpp:predefined-roi-sent Signalling of the predefined region-of-inte=
rest (ROI) information for the sent video, see clause 6.2.3.4


These are all meta data directly associated with the media sent, can aff=
ect how it is presented at the receiver. These should be expected to be pas=
sed through a PERC system unchanged. However, the PERC proponents use case =
would normally not see these being
 used. Also I would not be surprised over future extensions with that prope=
rty or at least proprietary extensions.





The set of header extensions that are related to how the endpoint bind a=
nd use the RTP Streams it receives, such as CNAME, rtp-stream-id, CaptId an=
d mid are really hard to protect and be efficient at the same time as they =
are expected to be added when switching
 RTP streams. 




Anyway I understand the choice to some degree. But I think the framework=
 should discuss the possible need for E2E protection, and the risks of not =
providing it in DOUBLE.




Cheers


=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.=
com=0A=
----------------------------------------------------------------------



--_000_HE1PR0701MB25225ED31452D0FCC2787500950B0HE1PR0701MB2522_--


From nobody Fri May 17 11:24:29 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6631A12012C; Fri, 17 May 2019 11:24:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 bxSz92GhgJ96; Fri, 17 May 2019 11:24:25 -0700 (PDT)
Received: from smtp101.iad3a.emailsrvr.com (smtp101.iad3a.emailsrvr.com [173.203.187.101]) (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 1ADD8120272; Fri, 17 May 2019 11:24:12 -0700 (PDT)
Received: from smtp13.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp13.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id CBB005549; Fri, 17 May 2019 14:24:10 -0400 (EDT)
X-Auth-ID: fluffy@iii.ca
Received: by smtp13.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 130074327;  Fri, 17 May 2019 14:24:10 -0400 (EDT)
X-Sender-Id: fluffy@iii.ca
Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 17 May 2019 14:24:10 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_86B6084B-EAF1-451B-8C35-FCAA8403E23E"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Cullen Jennings 
In-Reply-To: 
Date: Fri, 17 May 2019 12:24:08 -0600
Cc: Paul Jones , The IESG , "nohlmeier@mozilla.com" , "perc-chairs@ietf.org" , "perc@ietf.org" , "draft-ietf-perc-private-media-framework@ietf.org" 
Message-Id: <234A5249-3D7B-468C-9A77-72DBBF5CF46A@iii.ca>
References: <155786852996.30194.6992264311523885594.idtracker@ietfa.amsl.com>    
To: Magnus Westerlund 
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 May 2019 18:24:26 -0000

--Apple-Mail=_86B6084B-EAF1-451B-8C35-FCAA8403E23E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On May 17, 2019, at 8:22 AM, Magnus Westerlund =
 wrote:
>=20
>  So far only a single SRTP cipher suits defined provides source =
authentication properties that allow an endpoint to cryptographically =
assert that it sent a particular E2E protected packet. Instead, the =
common property is that one can determine only that any endpoint that =
has received the KEK has produced the packet.

Magnus, I=E2=80=99m just a bit confused on what the above two senses are =
trying to say - can you just expand it out a bit more so I get it. I =
think I am struggling with what cipher you refer to in the first =
sentense.=20


--Apple-Mail=_86B6084B-EAF1-451B-8C35-FCAA8403E23E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On May 17, 2019, at 8:22 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:

 So far only a single SRTP =
cipher suits defined provides source authentication properties that =
allow an endpoint to cryptographically assert that it sent a particular =
E2E protected packet. Instead, the common property is that one can =
determine only that any endpoint that has received the KEK has produced =
the packet.

Magnus, I=E2=80=99m just a bit confused on what the above two =
senses are trying to say - can you just expand it out a bit more so I =
get it. I think I am struggling with what cipher you refer to in the =
first sentense. 

=

--Apple-Mail=_86B6084B-EAF1-451B-8C35-FCAA8403E23E--


From nobody Fri May 17 11:34:26 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C1312024B; Fri, 17 May 2019 11:34:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=g001.emailsrvr.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 N0H-UlYREma9; Fri, 17 May 2019 11:34:23 -0700 (PDT)
Received: from smtp69.iad3a.emailsrvr.com (smtp69.iad3a.emailsrvr.com [173.203.187.69]) (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 D57F3120025; Fri, 17 May 2019 11:34:23 -0700 (PDT)
Received: from smtp33.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp33.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 988AE54DF; Fri, 17 May 2019 14:34:22 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=g001.emailsrvr.com; s=20190322-9u7zjiwi; t=1558118062; bh=UlKGTHiwaIqjUEjWaxYGdwGL4fBsS4rfzqdAa5AY9N4=; h=Subject:From:Date:To:From; b=LtG1mDc+mDh+u8vPh6aEH/7XE3h5tFJzM4ysErRFnS/7qYZ8tWS8ivwq47S5SN6Vp eyOQajuZu9p2ulgR57vJhMeBYQMH7SwegwziceATSMfmvo1zTN0AVDE0Fm7w/3PBhx 63bwp9GB3BCmwibdyEy8dgxo5iU0oxC09/B5hIr0=
X-Auth-ID: fluffy@iii.ca
Received: by smtp33.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id E36E75407;  Fri, 17 May 2019 14:34:21 -0400 (EDT)
X-Sender-Id: fluffy@iii.ca
Received: from [10.1.3.91] (S0106004268479ae3.cg.shawcable.net [70.77.44.153]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 17 May 2019 14:34:22 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Cullen Jennings 
In-Reply-To: <155800082724.19580.16483563575859435866.idtracker@ietfa.amsl.com>
Date: Fri, 17 May 2019 12:34:20 -0600
Cc: The IESG , perc-chairs@ietf.org, draft-ietf-perc-double@ietf.org, suhasietf@gmail.com, perc@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <65737EA1-49AF-4EB9-AD1F-25157B3F010D@iii.ca>
References: <155800082724.19580.16483563575859435866.idtracker@ietfa.amsl.com>
To: Magnus Westerlund 
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-double-10: (with DISCUSS and COMMENT)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 May 2019 18:34:25 -0000

>=20
> 1. Section 5.1:
>=20
> To me it appears that one fundamental security flaw exists in the =
definition of
> the inner encryption. That is the fact that RTP padding is not =
included into
> the inner encrypted part. This prevents the application of RTP padding =
to
> prevent the potential privacy leakage that "Guidelines for the Use of =
Variable
> Bit Rate Audio with Secure RTP" (RFC 6562) documents. To prevent this =
type of
> information leakage and other privacy preserving operations based on =
applying
> RTP padding it would be necessary to include the RTP padding into the =
inner
> encrypted envelope. Appendix A figure indicates that is the case, but =
the
> process description in 5.1 is not matching that.
>=20

So my read of 5.1 is that does this. Clearly we need to make the text =
clear that it does that - what part of the 5.1 makes you think the =
padding is stripped from the  payload ?

Perhaps to make it explicitly clear we should change=20

"* Payload: The RTP payload of the original packet=E2=80=9D

to be=20

"* Payload (including padding) The RTP payload (including passing) of =
the original packet=E2=80=9D






From nobody Mon May 20 00:10:25 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E016120020; Mon, 20 May 2019 00:10:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level: 
X-Spam-Status: No, score=-2.009 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 dYautrfusYze; Mon, 20 May 2019 00:10:21 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30087.outbound.protection.outlook.com [40.107.3.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B0AD120049; Mon, 20 May 2019 00:10:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=81Qujyq/mp7e6/7zKIHmXND4LgUsyblmifT7mK6NAME=; b=bcL1KiGKC9Pj69GERTg6R1D3S3Li+IrwbslFD3EBufjsuVEUmlMK9ggDHaoOsku+jYqO2QjFVM7ELFd95eKfaXYYHj5IJyRySrP3kfcF5vdLUDQOTIS054qWuzUY5n3yaeTLrbX+6iVm6E0MitRU/T6Y4T0LCbuniub7jll+1zI=
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2891.eurprd07.prod.outlook.com (10.168.92.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.11; Mon, 20 May 2019 07:10:17 +0000
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::896a:7ada:8bc9:d99d]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::896a:7ada:8bc9:d99d%6]) with mapi id 15.20.1922.013; Mon, 20 May 2019 07:10:17 +0000
From: Magnus Westerlund 
To: Cullen Jennings 
CC: Paul Jones , The IESG , "nohlmeier@mozilla.com" , "perc-chairs@ietf.org" , "perc@ietf.org" , "draft-ietf-perc-private-media-framework@ietf.org" 
Thread-Topic: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)
Thread-Index: AQHVDLv05Xj4KxTpkE2ssVAnd4w1Bg==
Date: Mon, 20 May 2019 07:10:17 +0000
Message-ID: 
References: <155786852996.30194.6992264311523885594.idtracker@ietfa.amsl.com>     <234A5249-3D7B-468C-9A77-72DBBF5CF46A@iii.ca>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; 
x-originating-ip: [192.176.1.87]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a620f759-cfe2-466a-a204-08d6dcf236b9
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2891; 
x-ms-traffictypediagnostic: HE1PR0701MB2891:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 004395A01C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(346002)(39860400002)(136003)(396003)(199004)(189003)(256004)(6116002)(14454004)(53546011)(6506007)(71200400001)(3846002)(2906002)(14444005)(66066001)(5660300002)(6916009)(25786009)(4326008)(102836004)(476003)(99286004)(446003)(478600001)(76176011)(44832011)(229853002)(33656002)(71190400001)(486006)(316002)(7696005)(64756008)(66446008)(55016002)(8676002)(81156014)(81166006)(54906003)(6436002)(66946007)(66556008)(66476007)(73956011)(76116006)(236005)(54896002)(86362001)(26005)(9686003)(74316002)(8936002)(186003)(52536014)(6246003)(68736007)(7736002)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2891; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: AkIJeIDu3eNTc/D9Yav3nPkk2ZYm+MTjfQhuF2vxLqyxu3lkvA9BhdiyrwUq4StM1KiVzTFwcTxV/FEmQUg8xC4GkTxKwPYn1n8lYNr+Co3YSL8Q7b7b0soj+EIrw0PhlKNPkn6tEU3EHSifDN99snZWmDv/iSRaKH9taaAgjZ7rVaLtVJ+xKJgsFSS1sugY6J//Z3uC2TVoTuTYpp8roig67K6Z6hue1IiTZ99QOF6UyKtbhCi25xEC0QqRilOYyNeOAOb4xy8RETbC21zvcxzApdxlGRoG8DOe+zuzOhbcqCR+o1QNHbRJSOPOtnkgkYIWi6m1fybt99Sl6oSDY+VdL5UL7Cuw+NYw6v4ypoVlGafqXJCUB/RiMvDcs26bTdYLrb7nfFYlhbWFe++nb8NZP48IfE2bpSunp+NqFzg=
Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB252253FCF1EEB0D1BD502D9495060HE1PR0701MB2522_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a620f759-cfe2-466a-a204-08d6dcf236b9
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2019 07:10:17.5683 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: magnus.westerlund@ericsson.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2891
Archived-At: 
Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 May 2019 07:10:24 -0000

--_000_HE1PR0701MB252253FCF1EEB0D1BD502D9495060HE1PR0701MB2522_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

On 2019-05-17 20:24, Cullen Jennings wrote:


On May 17, 2019, at 8:22 AM, Magnus Westerlund > wrote:

 So far only a single SRTP cipher suits defined provides source authenticat=
ion properties that allow an endpoint to cryptographically assert that it s=
ent a particular E2E protected packet. Instead, the common property is that=
 one can determine only that any endpoint that has received the KEK has pro=
duced the packet.

Magnus, I=92m just a bit confused on what the above two senses are trying t=
o say - can you just expand it out a bit more so I get it. I think I am str=
uggling with what cipher you refer to in the first sentense.


The single SRTP cipher suit that exists that provides any stronger source a=
uthentication property than, one of those that have the key has generated t=
his message, is to my knowledge TESLA (RFC  4383).

Let me cite one paragraph from Section 3.1 of RFC 7201:

   The source authentication guarantees provided by SRTP depend on the
   cryptographic transform and key management used.  Some transforms
   give strong source authentication even in multiparty sessions; others
   give weaker guarantees and can authenticate group membership but not
   sources.  Timed Efficient Stream Loss-Tolerant Authentication (TESLA)
   [RFC4383] offers a complement to the regular symmetric keyed
   authentication transforms, like HMAC-SHA-1, and can provide
   per-source authentication in some group communication scenarios.  The
   downside is the need for buffering the packets for a while before
   authenticity can be verified.

So as DOUBLE is AES-GCM which falls into the symmetric cipher suits, or cry=
ptographic transform as I think SRTP actually calls it, the only source aut=
hentication provided is that who ever generated the packet has the key. If =
one have the KEK, one will also receive all endpoints used master key and c=
an derive the actual used key that protects the inner payload and generates=
 the integrity tag. Thus, unless the involved parties has been compromised,=
 the source authentication statement provide is: Someone that was given the=
 KEK has generated this inner protected packet.

You are welcome to formulate this property however you want that you think =
makes sense.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

--_000_HE1PR0701MB252253FCF1EEB0D1BD502D9495060HE1PR0701MB2522_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable







On 2019-05-17 20:24, Cullen Jennings wrote:<=
br>











On May 17, 2019, at 8:22 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:




 So
 far only a single SRTP cipher suits defined provides source authentication=
 properties that allow an endpoint to cryptographically assert that it sent=
 a particular E2E protected packet. Instead, the common property is that on=
e can determine only that any endpoint
 that has received the KEK has produced the packet.








Magnus, I=92m just a bit confused on what the above two sen=
ses are trying to say - can you just expand it out a bit more so I get it. =
I think I am struggling with what cipher you refer to in the first sentense=
. 









The single SRTP cipher suit that exists that provides any stronger sourc=
e authentication property than, one of those that have the key has generate=
d this message, is to my knowledge TESLA (RFC  4383).





Let me cite one paragraph from Section 3.1 of RFC 7201: 




   The source authentication guarantees provided by SRTP depend on the=
=0A=
   cryptographic transform and key management used.  Some transforms=0A=
   give strong source authentication even in multiparty sessions; others=0A=
   give weaker guarantees and can authenticate group membership but not=0A=
   sources.  Timed Efficient Stream Loss-Tolerant Authentication (TESLA)=0A=
   [RFC4383] offers a complement to the regular symmetric keyed=0A=
   authentication transforms, like HMAC-SHA-1, and can provide=0A=
   per-source authentication in some group communication scenarios.  The=0A=
   downside is the need for buffering the packets for a while before=0A=
   authenticity can be verified.


So as DOUBLE is AES-GCM which falls into the symmetric cipher suits, or =
cryptographic transform as I think SRTP actually calls it, the only source =
authentication provided is that who ever generated the packet has the key. =
If one have the KEK, one will also
 receive all endpoints used master key and can derive the actual used key t=
hat protects the inner payload and generates the integrity tag. Thus, unles=
s the involved parties has been compromised, the source authentication stat=
ement provide is: Someone that was
 given the KEK has generated this inner protected packet.


You are welcome to formulate this property however you want that you thi=
nk makes sense.




Cheers =0A=
=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.=
com=0A=
----------------------------------------------------------------------



--_000_HE1PR0701MB252253FCF1EEB0D1BD502D9495060HE1PR0701MB2522_--


From nobody Mon May 20 00:24:30 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4B0120139; Mon, 20 May 2019 00:24:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level: 
X-Spam-Status: No, score=-2.009 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 LstkzpQVNCky; Mon, 20 May 2019 00:24:13 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40079.outbound.protection.outlook.com [40.107.4.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A9F11200D5; Mon, 20 May 2019 00:24:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HBBwoHIDMm/+rmW1d0YlFY6dpYtBv0RJp6M7pbKIXgA=; b=JTT29vrbbPVzE6Ge89x7livAYpvOigjLDIKJCi8bD867xuNIOMVeyFoWGWviCdMET0qmMAII4DC5ZQHQzbH83MHmnfNUmcNMoWk62xUbWRycy38KiESgCDpCBjbWljGZO7JHiC5dPL6w0KVEJ6cMpmwBQFt9pYP1gyf/JJmSd3c=
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2649.eurprd07.prod.outlook.com (10.168.186.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.10; Mon, 20 May 2019 07:24:09 +0000
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::896a:7ada:8bc9:d99d]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::896a:7ada:8bc9:d99d%6]) with mapi id 15.20.1922.013; Mon, 20 May 2019 07:24:09 +0000
From: Magnus Westerlund 
To: Cullen Jennings 
CC: The IESG , "perc-chairs@ietf.org" , "draft-ietf-perc-double@ietf.org" , "suhasietf@gmail.com" , "perc@ietf.org" 
Thread-Topic: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-double-10: (with DISCUSS and COMMENT)
Thread-Index: AQHVC85uMqFQ5/RAl0Cyrib7XAHyUA==
Date: Mon, 20 May 2019 07:24:09 +0000
Message-ID: 
References: <155800082724.19580.16483563575859435866.idtracker@ietfa.amsl.com> <65737EA1-49AF-4EB9-AD1F-25157B3F010D@iii.ca>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; 
x-originating-ip: [192.176.1.87]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 86e2fcf8-f33d-4e8b-2869-08d6dcf4265f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2649; 
x-ms-traffictypediagnostic: HE1PR0701MB2649:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 004395A01C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(39860400002)(346002)(136003)(396003)(199004)(189003)(20264003)(99286004)(53546011)(6506007)(446003)(71190400001)(73956011)(7696005)(66946007)(102836004)(66556008)(66446008)(6116002)(476003)(76116006)(66476007)(71200400001)(64756008)(33656002)(256004)(14444005)(3846002)(76176011)(25786009)(68736007)(7736002)(4326008)(9686003)(486006)(54906003)(81166006)(81156014)(8936002)(44832011)(53936002)(14454004)(8676002)(236005)(66066001)(6436002)(55016002)(2906002)(5660300002)(54896002)(478600001)(86362001)(26005)(6246003)(186003)(74316002)(229853002)(52536014)(6916009)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2649; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: XKdxv6/LP6K1j18lhdFG9LRnmdJV4oLRjIVA3e37fy1apAnPr6/dipr7FpbtsKryuev74xOPGREDU7nBeqOtUT7EDCYYRYLgIl0UEuG5B35xcK9FgYJD/5IWmTnkAvHBpcSGtFRxea9arUZse0BxYT+Yui2E03rhhluCZCSIsYjbCQ4zD0/v8N0KqQr9oYB+k7tcSojvknVjaxezruKXEFPMU2mfn6U1PFo5fhHbN8801sLAKOod1Q9EMA0UBhZDimG2fzBn9zpRUTcrAEBr3r1pYAlfSPItBRXGeNMw5C6EwF7C1Cimf4hVjskpNJf5K/mqgO99PyrnsCFpdjfmNstouvVpGq9e4zcqk3VFA7xUZkusxmBU56RWsoUwXfFkAlsJinhVc5BJRac03YibVKh8fDc7tvssdz7PtILHRE4=
Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB2522BE3811FBB03C3846F2EF95060HE1PR0701MB2522_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 86e2fcf8-f33d-4e8b-2869-08d6dcf4265f
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2019 07:24:09.1653 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: magnus.westerlund@ericsson.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2649
Archived-At: 
Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-double-10: (with DISCUSS and COMMENT)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 May 2019 07:24:16 -0000

--_000_HE1PR0701MB2522BE3811FBB03C3846F2EF95060HE1PR0701MB2522_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Cullen and WG,

Implementors, please see question at the end!

On 2019-05-17 20:34, Cullen Jennings wrote:


1. Section 5.1:

To me it appears that one fundamental security flaw exists in the definitio=
n of
the inner encryption. That is the fact that RTP padding is not included int=
o
the inner encrypted part. This prevents the application of RTP padding to
prevent the potential privacy leakage that "Guidelines for the Use of Varia=
ble
Bit Rate Audio with Secure RTP" (RFC 6562) documents. To prevent this type =
of
information leakage and other privacy preserving operations based on applyi=
ng
RTP padding it would be necessary to include the RTP padding into the inner
encrypted envelope. Appendix A figure indicates that is the case, but the
process description in 5.1 is not matching that.




So my read of 5.1 is that does this. Clearly we need to make the text clear=
 that it does that - what part of the 5.1 makes you think the padding is st=
ripped from the  payload ?

Perhaps to make it explicitly clear we should change

"* Payload: The RTP payload of the original packet=94

to be

"* Payload (including padding) The RTP payload (including passing) of the o=
riginal packet=94

Yes, making it explicit is necessary. The payload and the padding are two d=
istinct protocol parts, thus I think using "Including" is not the right way=
 of formulating it.

I think it would be clearer to do this:

OLD:

   3.  Form a synthetic RTP packet with the following contents:

       *  Header: The RTP header of the original packet with the
          following modifications:

       *  The X bit is set to zero

       *  The header is truncated to remove any extensions (i.e., keep
          only the first 12 + 4 * CC bytes of the header)

       *  Payload: The RTP payload of the original packet

NEW:
   3.  Form a synthetic RTP packet with the following contents:

       *  Header: The RTP header of the original packet with the
          following modifications:

       *  The X bit is set to zero

       *  The header is truncated to remove any extensions (i.e., keep
          only the first 12 + 4 * CC bytes of the header)

       *  Payload: The RTP payload of the original packet

       *  Padding: If padding is applied (P=3D1), include the padding count=
 octet and any padding octets.


I would also note that likely the padding need to be explicitly discussed
as being applied in the inner stage so that the outer packet generation
don't attempt to strip it away if P=3D1. Otherwise an MD could screw up the
packet completely.

Actually a question here to the people that has
implementation. If P=3D1 in the RTP header and they apply only the outer pa=
rt
of DOUBLE decryption will their stacks actually attempt to strip an RTP pad=
ding off using the
OHB config octet as padding byte count?


Cheers



Magnus Westerlund


----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

--_000_HE1PR0701MB2522BE3811FBB03C3846F2EF95060HE1PR0701MB2522_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable







Hi Cullen and WG,







Implementors, please see question at the end=
!









On 2019-05-17 20:34, Cullen Jennings wrote:<=
br>







=0A=
1. Section 5.1:=0A=
=0A=
To me it appears that one fundamental security flaw exists in the definitio=
n of=0A=
the inner encryption. That is the fact that RTP padding is not included int=
o=0A=
the inner encrypted part. This prevents the application of RTP padding to=
=0A=
prevent the potential privacy leakage that "Guidelines for the Use of =
Variable=0A=
Bit Rate Audio with Secure RTP" (RFC 6562) documents. To prevent this =
type of=0A=
information leakage and other privacy preserving operations based on applyi=
ng=0A=
RTP padding it would be necessary to include the RTP padding into the inner=
=0A=
encrypted envelope. Appendix A figure indicates that is the case, but the=
=0A=
process description in 5.1 is not matching that.=0A=
=0A=





=0A=
So my read of 5.1 is that does this. Clearly we need to make the text clear=
 that it does that - what part of the 5.1 makes you think the padding is st=
ripped from the  payload ?=0A=
=0A=
Perhaps to make it explicitly clear we should change =0A=
=0A=
"* Payload: The RTP payload of the original packet=94=0A=
=0A=
to be =0A=
=0A=
"* Payload (including padding) The RTP payload (including passing) of =
the original packet=94




Yes, making it explicit is necessary. The payload and the padding are tw=
o distinct protocol parts, thus I think using "Including" is not =
the right way of formulating it.





I think it would be clearer to do this:


OLD:


   3.  Form a synthetic RTP packet with the following contents:=0A=
=0A=
       *  Header: The RTP header of the original packet with the=0A=
          following modifications:=0A=
=0A=
       *  The X bit is set to zero=0A=
=0A=
       *  The header is truncated to remove any extensions (i.e., keep=0A=
          only the first 12 + 4 * CC bytes of the header)=0A=
=0A=
       *  Payload: The RTP payload of the original packet=0A=
=0A=
NEW:=0A=
   3.  Form a synthetic RTP packet with the following contents:=0A=
=0A=
       *  Header: The RTP header of the original packet with the=0A=
          following modifications:=0A=
=0A=
       *  The X bit is set to zero=0A=
=0A=
       *  The header is truncated to remove any extensions (i.e., keep=0A=
          only the first 12 + 4 * CC bytes of the header)=0A=
=0A=
       *  Payload: The RTP payload of the original packet=0A=
=0A=
       *  Padding: If padding is applied (P=3D1), include the padding count=
 octet and any padding octets. =0A=
=0A=
=0A=
I would also note that likely the padding need to be explicitly discussed=
=0A=
as being applied in the inner stage so that the outer packet generation =0A=
don't attempt to strip it away if P=3D1. Otherwise an MD could screw up the=
 =0A=
packet completely. =0A=
=0A=
Actually a question here to the people that has =0A=
implementation. If P=3D1 in the RTP header and they apply only the outer pa=
rt =0A=
of DOUBLE decryption will their stacks actually attempt to strip an RTP pad=
ding off using the =0A=
OHB config octet as padding byte count?=0A=
=0A=
=0A=
Cheers=0A=
=0A=


Magnus Westerlund

=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.=
com=0A=
----------------------------------------------------------------------



--_000_HE1PR0701MB2522BE3811FBB03C3846F2EF95060HE1PR0701MB2522_--


From nobody Mon May 20 09:11:57 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939A412017D; Mon, 20 May 2019 09:11:48 -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 cgxvGf7ZrR4B; Mon, 20 May 2019 09:11:46 -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 19B4112017A; Mon, 20 May 2019 09:11:46 -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=1558368701; bh=7UmGp0PMb8ca+v00WklFlCp7SPy8etAE+wA7dFK7qUE=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=W+E0Vlp0+96FnS8ArkFZzRds2QwHJViECZVrQrV4rarL97s4SlE4/Cx/J/jndgcw5 LSqAa1DzVpr2i1k2JDmvpHhbBQLaoNKGPm8SpdZtS1yz2utA8J39aPMr9GmHn4/IZf B6cnkL8WHdxxOv7bnCluOJzvxoxWeBqrVObjmpbM=
From: "Paul E. Jones" 
To: "Magnus Westerlund" , "Cullen Jennings" 
Cc: "The IESG" , "nohlmeier@mozilla.com" , "perc-chairs@ietf.org" , "perc@ietf.org" , "draft-ietf-perc-private-media-framework@ietf.org" 
Date: Mon, 20 May 2019 16:11:38 +0000
Message-Id: 
In-Reply-To: 
References: <155786852996.30194.6992264311523885594.idtracker@ietfa.amsl.com>     <234A5249-3D7B-468C-9A77-72DBBF5CF46A@iii.ca> 
Reply-To: "Paul E. Jones" 
User-Agent: eM_Client/7.2.35595.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MB0C1EAF0B-0A66-4BF5-BDB9-BBCDE967721C"
Archived-At: 
Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 May 2019 16:11:49 -0000

--------=_MB0C1EAF0B-0A66-4BF5-BDB9-BBCDE967721C
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Magnus,

How about this?

Additionally, if an adversary successfully exploits an Endpoint, the
adversary could inject media into the conference. One way an adversary
could do that is by manipulating the RTP or SRTP software to transmit
whatever media the adversary wishes to send.  This could involve
re-use of the Endpoint's SSRC, a new SSRC, or the SSRC value of an=20
existing
endpoint.  Only a single SRTP cipher suite defined provides source
authentication properties that allow an endpoint to cryptographically
assert that it sent a particular E2E protected packet, and its usage is
presently not defined for PERC.  The suite defined in PERC only allows
an Endpoint to determine that whoever sent a packet had received the=20
KEK.

I think that might capture the intent.  But, is this really useful to=20
speak of the issue in terms of cipher suites?  The text already explains=20
that an attacker could re-use another endpoint's SSRC.  It doesn't=20
explain why, though?  Maybe that would be useful?  For example, saying=20
right after "of an existing endpont" something like "This is made=20
possible since all conference
participants share the same KEK.

Anyway, I'm OK with inserting whatever you wish.  I just want to convey=20
what's most readily understood.

Paul

------ Original Message ------
From: "Magnus Westerlund" 
To: "Cullen Jennings" 
Cc: "Paul Jones" ; "The IESG" ;=20
"nohlmeier@mozilla.com" ; "perc-chairs@ietf.org"=20
; "perc@ietf.org" ;=20
"draft-ietf-perc-private-media-framework@ietf.org"=20

Sent: 5/20/2019 3:10:17 AM
Subject: Re: [Perc] Magnus Westerlund's Discuss on=20
draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)

>On 2019-05-17 20:24, Cullen Jennings wrote:
>>
>>
>>>On May 17, 2019, at 8:22 AM, Magnus Westerlund=20
>>> wrote:
>>>
>>>  So far only a single SRTP cipher suits defined provides source=20
>>>authentication properties that allow an endpoint to cryptographically=20
>>>assert that it sent a particular E2E protected packet. Instead, the=20
>>>common property is that one can determine only that any endpoint that=20
>>>has received the KEK has produced the packet.
>>
>>Magnus, I=E2=80=99m just a bit confused on what the above two senses are=
=20
>>trying to say - can you just expand it out a bit more so I get it. I=20
>>think I am struggling with what cipher you refer to in the first=20
>>sentense.
>>
>The single SRTP cipher suit that exists that provides any stronger=20
>source authentication property than, one of those that have the key has=20
>generated this message, is to my knowledge TESLA (RFC  4383).
>
>Let me cite one paragraph from Section 3.1 of RFC 7201:
>
>    The source authentication guarantees provided by SRTP depend on the
>    cryptographic transform and key management used.  Some transforms
>    give strong source authentication even in multiparty sessions; others
>    give weaker guarantees and can authenticate group membership but not
>    sources.  Timed Efficient Stream Loss-Tolerant Authentication (TESLA)
>    [RFC4383] offers a complement to the regular symmetric keyed
>    authentication transforms, like HMAC-SHA-1, and can provide
>    per-source authentication in some group communication scenarios.  The
>    downside is the need for buffering the packets for a while before
>    authenticity can be verified.
>So as DOUBLE is AES-GCM which falls into the symmetric cipher suits, or=20
>cryptographic transform as I think SRTP actually calls it, the only=20
>source authentication provided is that who ever generated the packet=20
>has the key. If one have the KEK, one will also receive all endpoints=20
>used master key and can derive the actual used key that protects the=20
>inner payload and generates the integrity tag. Thus, unless the=20
>involved parties has been compromised, the source authentication=20
>statement provide is: Someone that was given the KEK has generated this=20
>inner protected packet.
>
>You are welcome to formulate this property however you want that you=20
>think makes sense.
>
>Cheers
>
>Magnus Westerlund
>
>----------------------------------------------------------------------
>Network Architecture & Protocols, Ericsson Research
>----------------------------------------------------------------------
>Ericsson AB                 | Phone  +46 10 7148287
>Torshamnsgatan 23           | Mobile +46 73 0949079
>SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>----------------------------------------------------------------------
--------=_MB0C1EAF0B-0A66-4BF5-BDB9-BBCDE967721C
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable





Magnus,

How about this?

Additionally, if an adversary successfully exploits a=
n Endpoint, the
adversary could inject media into the conference. One=
 way an adversary
could do that is by manipulating the RTP or SRTP soft=
ware to transmit
whatever media the adversary wishes to send.=C2=A0 Th=
is could involve
re-use of the Endpoint's SSRC, a new SSRC, or the SSR=
C value of an existing
endpoint.=C2=A0 Only a single SRTP cipher suite =
defined provides source
authentication properties that allow an endpo=
int to cryptographically
assert that it sent a particular E2E protecte=
d packet, and its usage is
presently not defined for PERC.=C2=A0 The s=
uite defined in PERC only allows
an Endpoint to determine that whoever =
sent a packet had received the KEK.

I th=
ink that might capture the intent. =C2=A0But, is this really useful to spea=
k of the issue in terms of cipher suites? =C2=A0The text already explains t=
hat an attacker could re-use another endpoint's SSRC. =C2=A0It doesn't expl=
ain why, though? =C2=A0Maybe that would be useful? =C2=A0For example, sayin=
g right after "of an existing endpont" something like "This is made possibl=
e since all conference
participants share the same KEK.

Anyway, I'm OK with inserting whatever you wish. =C2=A0I=
 just want to convey what's most readily understood.

<=
div>Paul





------ Original Message ------


From: "Magnus Westerlund" <magnus.westerlund@ericsson.com>


To: "Cullen Jennings" <fluffy@iii.=
ca>


Cc: "Paul Jones" <paulej@p=
acketizer.com>; "The IESG" <iesg=
@ietf.org>; "nohlmeier@mozilla.com" <nohlmeier@mozilla.com>; "perc-chairs@ietf.org" <perc-chairs@ietf.org>; "perc@iet=
f.org" <perc@ietf.org>; "draft-i=
etf-perc-private-media-framework@ietf.org" <draft-ietf-perc-private-media-frame=
work@ietf.org>


Sent: 5/20/2019 3:10:17 AM


Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-pri=
vate-media-framework-10: (with DISCUSS and COMMENT)






On 2019-05-17 20:24, Cullen Jennings wrote:<=
br />











On May 17, 2019, at 8:22 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:




=
=C2=A0So
 far only a single SRTP cipher suits defined provides source authentication =
properties that allow an endpoint to cryptographically assert that it sent =
a particular E2E protected packet. Instead, the common property is that on=
e can determine only that any endpoint
 that has received the KEK has produced the packet.








Magnus, I=E2=80=99m just a bit confused on what the above t=
wo senses are trying to say - can you just expand it out a bit more so I ge=
t it. I think I am struggling with what cipher you refer to in the first se=
ntense.=C2=A0









The single SRTP cipher suit that exists that provides any stronger sourc=
e authentication property than, one of those that have the key has generate=
d this message, is to my knowledge TESLA (RFC=C2=A0 4383).





Let me cite one paragraph from Section 3.1 of RFC 7201: 




   The source authentication guarantees provided by SRTP depend on the
   cryptographic transform and key management used.  Some transforms
   give strong source authentication even in multiparty sessions; others
   give weaker guarantees and can authenticate group membership but not
   sources.  Timed Efficient Stream Loss-Tolerant Authentication (TESLA)
   [RFC4383] offers a complement to the regular symmetric keyed
   authentication transforms, like HMAC-SHA-1, and can provide
   per-source authentication in some group communication scenarios.  The
   downside is the need for buffering the packets for a while before
   authenticity can be verified.


So as DOUBLE is AES-GCM which falls into the symmetric cipher suits, or=
 cryptographic transform as I think SRTP actually calls it, the only source=
 authentication provided is that who ever generated the packet has the key.=
 If one have the KEK, one will also
 receive all endpoints used master key and can derive the actual used key t=
hat protects the inner payload and generates the integrity tag. Thus, unles=
s the involved parties has been compromised, the source authentication stat=
ement provide is: Someone that was
 given the KEK has generated this inner protected packet.


You are welcome to formulate this property however you want that you thi=
nk makes sense.




Cheers=20

Magnus Westerlund=20

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.=
com
----------------------------------------------------------------------





--------=_MB0C1EAF0B-0A66-4BF5-BDB9-BBCDE967721C--


From nobody Tue May 21 01:24:46 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9542E120059; Tue, 21 May 2019 01:24:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 L69n_dItmlAS; Tue, 21 May 2019 01:24:34 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0627.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::627]) (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 E658412011C; Tue, 21 May 2019 01:24:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ssGrXva8ZD2IR3uI8Z0QvI8zUPyLY2dBYqwb07BLG3Q=; b=mWGaA77Iw8OY0wcmCZLSn8NHVHj+/dLxPkd/rJiplTNbAkx6/UE2sKlvajzHJ7ioYoZ4Ia++JcKSv0VqNUNgMpMA1/5ypKnS1oReaXwwKX2igkQqWUpHVs1QEgJCAk9YLUb6JF2ndpot84CszouZiTuUg9ZrwbA1pPSAgaCDsk0=
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2236.eurprd07.prod.outlook.com (10.168.31.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.10; Tue, 21 May 2019 08:24:29 +0000
Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::896a:7ada:8bc9:d99d]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::896a:7ada:8bc9:d99d%6]) with mapi id 15.20.1922.013; Tue, 21 May 2019 08:24:29 +0000
From: Magnus Westerlund 
To: "paulej@packetizer.com" , "fluffy@iii.ca" 
CC: "perc-chairs@ietf.org" , "iesg@ietf.org" , "nohlmeier@mozilla.com" , "perc@ietf.org" , "draft-ietf-perc-private-media-framework@ietf.org" 
Thread-Topic: Re[2]: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)
Thread-Index: AQHVDLv05Xj4KxTpkE2ssVAnd4w1BqZ0M/AAgAEPwYA=
Date: Tue, 21 May 2019 08:24:28 +0000
Message-ID: <1558427057.31263.3.camel@ericsson.com>
References: <155786852996.30194.6992264311523885594.idtracker@ietfa.amsl.com>     <234A5249-3D7B-468C-9A77-72DBBF5CF46A@iii.ca>  
In-Reply-To: 
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; 
x-originating-ip: [129.192.74.4]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a918dfe3-6d6f-495e-e3a7-08d6ddc5be4f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(49563074)(7193020); SRVR:HE1PR0701MB2236; 
x-ms-traffictypediagnostic: HE1PR0701MB2236:
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:517;
x-forefront-prvs: 0044C17179
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(376002)(346002)(396003)(366004)(51444003)(13464003)(52314003)(199004)(189003)(110136005)(103116003)(4326008)(508600001)(76176011)(54906003)(486006)(25786009)(44832011)(54896002)(36756003)(236005)(3846002)(6116002)(2616005)(26005)(2906002)(6512007)(229853002)(99286004)(102836004)(316002)(11346002)(53546011)(186003)(6506007)(446003)(2690700001)(6486002)(8676002)(81156014)(99936001)(81166006)(53936002)(6436002)(6246003)(256004)(7736002)(476003)(8936002)(14444005)(71200400001)(71190400001)(66946007)(91956017)(86362001)(68736007)(76116006)(66556008)(14454004)(66446008)(66066001)(5660300002)(66476007)(73956011)(66616009)(64756008)(66574012)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2236; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: A2bVvINrco/vQ8Wmhx8vrTlWKFrGrvglnbrErvD2aa2aqnI8on98w5ExDFiHITinClX5hqWw0KKMi5bV4SnxJSDA7TgJ9dzesTRCD2peNzpvCjH75OGK2MS6ygojFxFF6AMbHm8v/P59/szDyOl3C/bSxKwmZ3aM+UP2kNFAUkTJS8O2+fV248mk5/CSxnZmYKaEaXwTQmNuboAk1T/48hF3syv1b3XnnqZAMowHAfYebyjCjwVksTIfHBtajhP7qH0h91Gc8ojYySn/4GFLCsbQ52wJX61nK1aMDskNphxD8Dft/VZrQH0sGUSgFAst0ZPBpAnBATrRA6+eiipqPMuaEYYuUXw5ecG4BFvM9cpeKauMFkTZ45PJUWXJvMG/7dv4Eu06I4NPODujWX2Flu3o3dQhhWnm4HNMRWNOp+g=
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-bp96dndxNFC2M9eDhO5Z"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a918dfe3-6d6f-495e-e3a7-08d6ddc5be4f
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2019 08:24:28.8494 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: magnus.westerlund@ericsson.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2236
Archived-At: 
Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 May 2019 08:24:38 -0000

--=-bp96dndxNFC2M9eDhO5Z
Content-Type: multipart/alternative; boundary="=-XrgB1KnDTDhUQ0myxnrU"


--=-XrgB1KnDTDhUQ0myxnrU
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,
I think the below with the suggested added sentence is good enough for
what needs to be described.=C2=A0
Additionally, if an adversary successfully exploits an Endpoint, the
adversary could inject media into the conference. One way an adversary
could do that is by manipulating the RTP or SRTP software to transmit
whatever media the adversary wishes to send.=C2=A0=C2=A0This could involve
re-use of the Endpoint's SSRC, a new SSRC, or the SSRC value of an
existing
endpoint. This is made possible since all conference participants share
the same KEK. Only a single SRTP cipher suite defined provides source
authentication properties that allow an endpoint to cryptographically
assert that it sent a particular E2E protected packet, and its usage is
presently not defined for PERC.=C2=A0=C2=A0The suite defined in PERC only a=
llows
an Endpoint to determine that whoever sent a packet had received the
KEK.
Cheers
Magnus
On m=C3=A5n, 2019-05-20 at 16:11 +0000, Paul E. Jones wrote:
> Magnus,
>=20
> How about this?
>=20
> Additionally, if an adversary successfully exploits an Endpoint, the
> adversary could inject media into the conference. One way an
> adversary
> could do that is by manipulating the RTP or SRTP software to transmit
> whatever media the adversary wishes to send.=C2=A0 This could involve
> re-use of the Endpoint's SSRC, a new SSRC, or the SSRC value of an
> existing
> endpoint.=C2=A0This is made possible since all conference=C2=A0participan=
ts
> share
> the same KEK. > Only a single SRTP cipher suite defined provides source
> authentication properties that allow an endpoint to cryptographically
> assert that it sent a particular E2E protected packet, and its usage is
> presently not defined for PERC.=C2=A0 The suite defined in PERC only allo=
ws
> an Endpoint to determine that whoever sent a packet had received the KEK.
>=20
>=20
> I think that might capture the intent. =C2=A0But, is this really useful t=
o speak of the issue in terms of cipher suites? =C2=A0The text already expl=
ains that an attacker could re-use another endpoint's SSRC. =C2=A0It doesn'=
t explain why, though? =C2=A0Maybe that would be useful? =C2=A0For example,=
 saying right after "of an existing endpont" something like "This is made p=
ossible since all conference
> participants share the same KEK.
>=20
> Anyway, I'm OK with inserting whatever you wish. =C2=A0I just want to con=
vey what's most readily understood.
>=20
> Paul
>=20
>=20
>=20
> ------ Original Message ------
>=20
> From: "Magnus Westerlund" 
>=20
> To: "Cullen Jennings" 
>=20
> Cc: "Paul Jones" ; "The IESG" ; "no=
hlmeier@mozilla.com" ; "perc-chairs@ietf.org" ; "perc@ietf.org" ; "draft-ietf-perc-private=
-media-framework@ietf.org" 
>=20
> Sent: 5/20/2019 3:10:17 AM
>=20
> Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-privat=
e-media-framework-10: (with DISCUSS and COMMENT)
>=20
>=20
> >=20
> >=20
> >=20
> > On 2019-05-17 20:24, Cullen Jennings wrote:
> >=20

> >=20

> > >=20

> > >=20
> > > >=20
> > > > On May 17, 2019, at 8:22 AM, Magnus Westerlund  wrote:
> > > >=20

> > > >=20
> > > > =C2=A0> > > > So
> > > >  far only a single SRTP cipher suits defined provides source authen=
tication properties that allow an endpoint to cryptographically assert that=
 it sent a particular E2E protected packet. Instead, the common property is=
 that one can determine only that any endpoint
> > > >  that has received the KEK has produced the packet.
> > > >=20

> > >=20

> > >=20

> > >=20
> > > Magnus, I=E2=80=99m just a bit confused on what the above two senses =
are trying to say - can you just expand it out a bit more so I get it. I th=
ink I am struggling with what cipher you refer to in the first sentense.=C2=
=A0
> > >=20

> > >=20

> > >=20

> >=20
> > The single SRTP cipher suit that exists that provides any stronger sour=
ce authentication property than, one of those that have the key has generat=
ed this message, is to my knowledge TESLA (RFC=C2=A0 4383).
> >=20

> >=20

> >=20
> > Let me cite one paragraph from Section 3.1 of RFC 7201:=20
> >=20

> >=20
> >    The source authentication guarantees provided by SRTP depend on the
> >    cryptographic transform and key management used.  Some transforms
> >    give strong source authentication even in multiparty sessions; other=
s
> >    give weaker guarantees and can authenticate group membership but not
> >    sources.  Timed Efficient Stream Loss-Tolerant Authentication (TESLA=
)
> >    [RFC4383] offers a complement to the regular symmetric keyed
> >    authentication transforms, like HMAC-SHA-1, and can provide
> >    per-source authentication in some group communication scenarios.  Th=
e
> >    downside is the need for buffering the packets for a while before
> >    authenticity can be verified.
> >=20
> > So as DOUBLE is AES-GCM which falls into the symmetric cipher suits, or=
 cryptographic transform as I think SRTP actually calls it, the only source=
 authentication provided is that who ever generated the packet has the key.=
 If one have the KEK, one will also
> >  receive all endpoints used master key and can derive the actual used k=
ey that protects the inner payload and generates the integrity tag. Thus, u=
nless the involved parties has been compromised, the source authentication =
statement provide is: Someone that was
> >  given the KEK has generated this inner protected packet.
> >=20
> > You are welcome to formulate this property however you want that you th=
ink makes sense.
> >=20

> >=20
> > Cheers=20
> >=20
> > Magnus Westerlund=20
> >=20
> > ----------------------------------------------------------------------
> > Network Architecture & Protocols, Ericsson Research
> > ----------------------------------------------------------------------
> > Ericsson AB                 | Phone  +46 10 7148287
> > Torshamnsgatan 23           | Mobile +46 73 0949079
> > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> >=20
> > ----------------------------------------------------------------------
> >=20

>=20
>=20
>=20
>=20

--=-XrgB1KnDTDhUQ0myxnrU
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable


blockquote.cite { margin-left: 5px=
; margin-right: 0px; padding-left: 10px; padding-right:0px; border-left: 1p=
x solid #cccccc }
blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px; =
padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; padding=
-top: 0px; }
a img { border: 0px; }
li[style=3D'text-align: center;'], li[style=3D'text-align: right;'] {  list=
-style-position: inside;}
body { font-family: Calibri; font-size: 11pt;   }

Hi,

I think the below with the suggeste=
d added sentence is good enough for what needs to be described. 
=


Additionally, if an adversary successfully exploits an =
Endpoint, the
adversary could inject media into the conference. O=
ne way an adversary
could do that is by manipulating the RTP or S=
RTP software to transmit
whatever media the adversary wishes to s=
end.  This could involve
re-use of the Endpoint's SSRC,=
 a new SSRC, or the SSRC value of an existing
endpoint. This is m=
ade possible since all conference participants share
the same KEK=
. Only a single SRTP cipher suite defined provides source
authent=
ication properties that allow an endpoint to cryptographically
as=
sert that it sent a particular E2E protected packet, and its usage is
=

presently not defined for PERC.  The suite defined in PERC o=
nly allows
an Endpoint to determine that whoever sent a packet ha=
d received the KEK.

Cheers

Magnus

On m=C3=A5n, 2019-05-20 at 16:11 +0000, P=
aul E. Jones wrote:
Magnus,
<=
br>
How about this?

Additionally=
, if an adversary successfully exploits an Endpoint, the
adversary could=
 inject media into the conference. One way an adversary
could do that is=
 by manipulating the RTP or SRTP software to transmit
whatever media the=
 adversary wishes to send.  This could involve
re-use of the Endpoi=
nt's SSRC, a new SSRC, or the SSRC value of an existing
endpoint. <=
/font>This is made possible since all conf=
erence participants share 
the same KEK. Only a single SRTP cipher suite defined provides source<=
/span>
authentication properties that allow an endpoint to cryp=
tographically
assert that it sent a particular E2E protected packet, and=
 its usage is
presently not defined for PERC.  The suite defined in=
 PERC only allows
an Endpoint to determine that whoever sent a packet ha=
d received the KEK.


I think that might capture the intent.  =
;But, is this really useful to speak of the issue in terms of cipher suites=
?  The text already explains that an attacker could re-use another end=
point's SSRC.  It doesn't explain why, though?  Maybe that would =
be useful?  For example, saying right after "of an existing endpont" s=
omething like "This is made possible since all conference
partici=
pants share the same KEK.

Anyway, I'm OK with inse=
rting whatever you wish.  I just want to convey what's most readily un=
derstood.

Paul





------ Original Message ------


From: "Magnus Westerlund" <magnus.westerlund@ericsson.com>


To: "Cullen Jennings" <fluffy@iii.=
ca>


Cc: "Paul Jones" <paulej@p=
acketizer.com>; "The IESG" <iesg=
@ietf.org>; "nohlmeier@mozilla.com" <nohlmeier@mozilla.com>; "perc-chairs@ietf.org" <perc-chairs@ietf.org>; "perc@iet=
f.org" <perc@ietf.org>; "draft-i=
etf-perc-private-media-framework@ietf.org" <draft-ietf-perc-private-media-frame=
work@ietf.org>


Sent: 5/20/2019 3:10:17 AM


Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-pri=
vate-media-framework-10: (with DISCUSS and COMMENT)






On 2019-05-17 20:24, Cullen Jennings wrote:<=
br>











On May 17, 2019, at 8:22 AM, Magnus Westerlund <magnus.=
westerlund@ericsson.com> wrote:




 So
 far only a single SRTP cipher suits defined provides source authentication=
 properties that allow an endpoint to cryptographically assert that it sent=
 a particular E2E protected packet. Instead, the common property is that on=
e can determine only that any endpoint
 that has received the KEK has produced the packet.








Magnus, I=E2=80=99m just a bit confused on what the above t=
wo senses are trying to say - can you just expand it out a bit more so I ge=
t it. I think I am struggling with what cipher you refer to in the first se=
ntense. 









The single SRTP cipher suit that exists that provides any stronger sourc=
e authentication property than, one of those that have the key has generate=
d this message, is to my knowledge TESLA (RFC  4383).





Let me cite one paragraph from Section 3.1 of RFC 7201: 




   The source authentication guarantees provided by SRTP depend on the
   cryptographic transform and key management used.  Some transforms
   give strong source authentication even in multiparty sessions; others
   give weaker guarantees and can authenticate group membership but not
   sources.  Timed Efficient Stream Loss-Tolerant Authentication (TESLA)
   [RFC4383] offers a complement to the regular symmetric keyed
   authentication transforms, like HMAC-SHA-1, and can provide
   per-source authentication in some group communication scenarios.  The
   downside is the need for buffering the packets for a while before
   authenticity can be verified.


So as DOUBLE is AES-GCM which falls into the symmetric cipher suits, or =
cryptographic transform as I think SRTP actually calls it, the only source =
authentication provided is that who ever generated the packet has the key. =
If one have the KEK, one will also
 receive all endpoints used master key and can derive the actual used key t=
hat protects the inner payload and generates the integrity tag. Thus, unles=
s the involved parties has been compromised, the source authentication stat=
ement provide is: Someone that was
 given the KEK has generated this inner protected packet.


You are welcome to formulate this property however you want that you thi=
nk makes sense.




Cheers=20

Magnus Westerlund=20

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------






--=-XrgB1KnDTDhUQ0myxnrU--

--=-bp96dndxNFC2M9eDhO5Z
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww
ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT
AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD
QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u
MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl
cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT
+2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9
uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig
GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr
bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD
VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2
aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu
dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu
Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl
cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH
AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW
MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD
VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB
CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c
vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ
yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi
SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD
o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu
bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l
9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC
QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z
la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/
/n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL
MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp
dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI
RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu
dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K
QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR
V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba
9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84
6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE
MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv
bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6
Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp
YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu
dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4
BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw
HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe
xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ
KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO
3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI
X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e
eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr
gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc
rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4
ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH
KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH
rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB
SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B
AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD
QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD
VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw
DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D
tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK
6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk
TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ
kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2
haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO
UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW
9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0
5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL
sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8
MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH
MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv
b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC
MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v
Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v
dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G
A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU
8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL
Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb
AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4
Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2
d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu
zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg
0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F
04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d
1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7
C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw
CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2
aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3
DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDUyMTA4MjQxN1owLwYJKoZIhvcN
AQkEMSIEIOtUwXZLnB4/E0tPjHYu7NNRzpFZr9u1ZDrCipx3SsALMGoGCSsGAQQBgjcQBDFdMFsw
RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ
bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw
CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2
aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAGrRHz1mDNtIx
kZQEs3/BI1HeZDgBr9gk+yDwVL7WgSJZTmh5rhvdJJLKQnE9a4FwjJSO6tXJSwEbfWV/CpQwnckv
lnP9mfW4SwVcqVEGBMZ7n3JmduLPGdonZd2D1uK3e4QUGFF06eoVZRffXcS0+zNghRdIeyt6forU
qohmo/3Vjh9TI6MToI1w59R9sf5SuqmGjgKcvtHN17PgJaUSKsdyfOPtV/r7J9lmQJWI10IHjDE+
qEIxZdyzyVIfbJmpj73uiBT7vCOnEgBULZbYJeqptMHOgzt6oQ9hXVOrVsJofMTBjsVpE1DxK2Yr
sl5hR+F1+YflI6BJo9LbXyEEqwAAAAAAAA==


--=-bp96dndxNFC2M9eDhO5Z--


From nobody Tue May 21 07:15:17 2019
Return-Path: 
X-Original-To: perc@ietfa.amsl.com
Delivered-To: perc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F80120099; Tue, 21 May 2019 07:15:16 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 C_qVLap2iNvz; Tue, 21 May 2019 07:15:13 -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 6BFF1120020; Tue, 21 May 2019 07:15:13 -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=1558448107; bh=dLz08db0yogai4ucF/tDYV+AJoIn5IPAGsZs0l+R+Fw=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=Ygvc+Khv4aSDgI4KbTGTHFA5ZvYcXum7n7owPv35uMd9Hkh77x9Jx01okmopnbdTm h4GFZuKGVDHEFa7YY8c/adUUUAfen6qxmsnbIN2bWALrOBsHMBi+LnyuNlD/TslJ+F sEbP5IwaZy2BjFWIQsXdR8pFALQq2P7n/zph2HKU=
From: "Paul E. Jones" 
To: "Magnus Westerlund" , "fluffy@iii.ca" 
Cc: "perc-chairs@ietf.org" , "iesg@ietf.org" , "nohlmeier@mozilla.com" , "perc@ietf.org" , "draft-ietf-perc-private-media-framework@ietf.org" 
Date: Tue, 21 May 2019 14:15:03 +0000
Message-Id: 
In-Reply-To: <1558427057.31263.3.camel@ericsson.com>
References: <155786852996.30194.6992264311523885594.idtracker@ietfa.amsl.com>     <234A5249-3D7B-468C-9A77-72DBBF5CF46A@iii.ca>   <1558427057.31263.3.camel@ericsson.com>
Reply-To: "Paul E. Jones" 
User-Agent: eM_Client/7.2.35595.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MB800EBB8C-8C3F-4CB5-A6C9-38B4E4C3CCCB"
Archived-At: 
Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 May 2019 14:15:16 -0000

--------=_MB800EBB8C-8C3F-4CB5-A6C9-38B4E4C3CCCB
Content-Type: text/plain; format=flowed; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Think we should reference TESLA (RFC  4383) as informational? =20
Otherwise, the "one a single..." statement will leave most wondering=20
which one it is.

------ Original Message ------
From: "Magnus Westerlund" 
To: "paulej@packetizer.com" ; "fluffy@iii.ca"=20

Cc: "perc-chairs@ietf.org" ; "iesg@ietf.org"=20
; "nohlmeier@mozilla.com" ;=20
"perc@ietf.org" ;=20
"draft-ietf-perc-private-media-framework@ietf.org"=20

Sent: 5/21/2019 4:24:28 AM
Subject: Re: Re[2]: [Perc] Magnus Westerlund's Discuss on=20
draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)

>Hi,
>
>I think the below with the suggested added sentence is good enough for=20
>what needs to be described.
>
>Additionally, if an adversary successfully exploits an Endpoint, the
>adversary could inject media into the conference. One way an adversary
>could do that is by manipulating the RTP or SRTP software to transmit
>whatever media the adversary wishes to send.  This could involve
>re-use of the Endpoint's SSRC, a new SSRC, or the SSRC value of an=20
>existing
>endpoint. This is made possible since all conference participants share
>the same KEK. Only a single SRTP cipher suite defined provides source
>authentication properties that allow an endpoint to cryptographically
>assert that it sent a particular E2E protected packet, and its usage is
>presently not defined for PERC.  The suite defined in PERC only allows
>an Endpoint to determine that whoever sent a packet had received the=20
>KEK.
>
>Cheers
>
>Magnus
>
>On m=C3=A5n, 2019-05-20 at 16:11 +0000, Paul E. Jones wrote:
>>Magnus,
>>
>>How about this?
>>
>>Additionally, if an adversary successfully exploits an Endpoint, the
>>adversary could inject media into the conference. One way an adversary
>>could do that is by manipulating the RTP or SRTP software to transmit
>>whatever media the adversary wishes to send.  This could involve
>>re-use of the Endpoint's SSRC, a new SSRC, or the SSRC value of an=20
>>existing
>>endpoint. This is made possible since all conference participants=20
>>share
>>the same KEK. Only a single SRTP cipher suite defined provides source
>>authentication properties that allow an endpoint to cryptographically
>>assert that it sent a particular E2E protected packet, and its usage=20
>>is
>>presently not defined for PERC.  The suite defined in PERC only allows
>>an Endpoint to determine that whoever sent a packet had received the=20
>>KEK.
>>
>>
>>I think that might capture the intent.  But, is this really useful to=20
>>speak of the issue in terms of cipher suites?  The text already=20
>>explains that an attacker could re-use another endpoint's SSRC.  It=20
>>doesn't explain why, though?  Maybe that would be useful?  For=20
>>example, saying right after "of an existing endpont" something like=20
>>"This is made possible since all conference
>>participants share the same KEK.
>>
>>Anyway, I'm OK with inserting whatever you wish.  I just want to=20
>>convey what's most readily understood.
>>
>>Paul
>>
>>------ Original Message ------
>>From: "Magnus Westerlund" 
>>To: "Cullen Jennings" 
>>Cc: "Paul Jones" ; "The IESG" ;=20
>>"nohlmeier@mozilla.com" ;=20
>>"perc-chairs@ietf.org" ; "perc@ietf.org"=20
>>; "draft-ietf-perc-private-media-framework@ietf.org"=20
>>
>>Sent: 5/20/2019 3:10:17 AM
>>Subject: Re: [Perc] Magnus Westerlund's Discuss on=20
>>draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT)
>>
>>>On 2019-05-17 20:24, Cullen Jennings wrote:
>>>>
>>>>
>>>>>On May 17, 2019, at 8:22 AM, Magnus Westerlund=20
>>>>> wrote:
>>>>>
>>>>>  So far only a single SRTP cipher suits defined provides source=20
>>>>>authentication properties that allow an endpoint to=20
>>>>>cryptographically assert that it sent a particular E2E protected=20
>>>>>packet. Instead, the common property is that one can determine only=20
>>>>>that any endpoint that has received the KEK has produced the=20
>>>>>packet.
>>>>
>>>>Magnus, I=E2=80=99m just a bit confused on what the above two senses ar=
e=20
>>>>trying to say - can you just expand it out a bit more so I get it. I=20
>>>>think I am struggling with what cipher you refer to in the first=20
>>>>sentense.
>>>>
>>>The single SRTP cipher suit that exists that provides any stronger=20
>>>source authentication property than, one of those that have the key=20
>>>has generated this message, is to my knowledge TESLA (RFC  4383).
>>>
>>>Let me cite one paragraph from Section 3.1 of RFC 7201:
>>>
>>>    The source authentication guarantees provided by SRTP depend on the
>>>    cryptographic transform and key management used.  Some transforms
>>>    give strong source authentication even in multiparty sessions; other=
s
>>>    give weaker guarantees and can authenticate group membership but not
>>>    sources.  Timed Efficient Stream Loss-Tolerant Authentication (TESLA=
)
>>>    [RFC4383] offers a complement to the regular symmetric keyed
>>>    authentication transforms, like HMAC-SHA-1, and can provide
>>>    per-source authentication in some group communication scenarios.  Th=
e
>>>    downside is the need for buffering the packets for a while before
>>>    authenticity can be verified.
>>>So as DOUBLE is AES-GCM which falls into the symmetric cipher suits,=20
>>>or cryptographic transform as I think SRTP actually calls it, the=20
>>>only source authentication provided is that who ever generated the=20
>>>packet has the key. If one have the KEK, one will also receive all=20
>>>endpoints used master key and can derive the actual used key that=20
>>>protects the inner payload and generates the integrity tag. Thus,=20
>>>unless the involved parties has been compromised, the source=20
>>>authentication statement provide is: Someone that was given the KEK=20
>>>has generated this inner protected packet.
>>>
>>>You are welcome to formulate this property however you want that you=20
>>>think makes sense.
>>>
>>>Cheers
>>>
>>>Magnus Westerlund
>>>
>>>----------------------------------------------------------------------
>>>Network Architecture & Protocols, Ericsson Research
>>>----------------------------------------------------------------------
>>>Ericsson AB                 | Phone  +46 10 7148287
>>>Torshamnsgatan 23           | Mobile +46 73 0949079
>>>SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>>>----------------------------------------------------------------------
--------=_MB800EBB8C-8C3F-4CB5-A6C9-38B4E4C3CCCB
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable




Think we should reference TESLA (RFC=C2=A0 4383) as informational? =C2=A0Otherwise, t=
he "one a single..." statement will leave most wondering which one it is.





------ Original Message ------


From: "Magnus Westerlund" <magnus.westerlund@ericsson.com>


To: "paulej@packetizer.com" <paulej@packetizer.com>; "fluffy@iii.ca" <fluffy@iii.ca>


Cc: "perc-chairs@ietf.org" <perc-chairs@ietf.org>; "iesg@ietf.org" <iesg@ietf.org>; "nohlmeier@mozilla.com" <nohlmeier@mozilla.com>; "perc@ietf.org" &l=
t;perc@ietf.org>; "draft-ietf-perc-=
private-media-framework@ietf.org" <draft-ietf-perc-private-media-framework@ietf=
.org>


Sent: 5/21/2019 4:24:28 AM


Subject: Re: Re[2]: [Perc] Magnus Westerlund's Discuss on draft-ietf-p=
erc-private-media-framework-10: (with DISCUSS and COMMENT)

=





Hi,

I think the below with the suggested ad=
ded sentence is good enough for what needs to be described.=C2=A0

Additionally, if an adversary successfully exploits an En=
dpoint, the
adversary could inject media into the conference. One =
way an adversary
could do that is by manipulating the RTP or SRT=
P software to transmit
whatever media the adversary wishes to sen=
d.=C2=A0=C2=A0This could involve
re-use of the Endpoint's SSRC, a =
new SSRC, or the SSRC value of an existing
endpoint. This is mad=
e possible since all conference participants share
the same KEK.=
 Only a single SRTP cipher suite defined provides source
authentic=
ation properties that allow an endpoint to cryptographically
asse=
rt that it sent a particular E2E protected packet, and its usage is
presently not defined for PERC.=C2=A0=C2=A0The suite defined in PERC onl=
y allows
an Endpoint to determine that whoever sent a packet had= received the KEK.

Cheers

<= div>Magnus

On m=C3=A5n, 2019-05-20 at 16:11 +000= 0, Paul E. Jones wrote:
= Magnus,

How about this?

Additionally, if an adversary successfully exploits an Endpoint, = the
adversary could inject media into the conference. One way an adve= rsary
could do that is by manipulating the RTP or SRTP software to tra= nsmit
whatever media the adversary wishes to send.=C2=A0 This could in= volve
re-use of the Endpoint's SSRC, a new SSRC, or the SSRC value of= an existing
endpoint.=C2=A0This is made possible since all conf= erence=C2=A0participants share
the same KEK.
participants share the same KEK.

Anyway, I'm OK with inserting whatever you wish. =C2= =A0I just want to convey what's most readily understood.

Paul

------ Original Message ------
From: "Magnus Westerlund" <magnus.westerlund@ericsson.com>
To: "Cullen Jennings" <fluffy@iii.= ca>
Sent: 5/20/2019 3:10:17 AM
Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-pri= vate-media-framework-10: (with DISCUSS and COMMENT)

On 2019-05-17 20:24, Cullen Jennings wrote:<= br />


On May 17, 2019, at 8:22 AM, Magnus Westerlund <magnus.= westerlund@ericsson.com> wrote:

= =C2=A0So far only a single SRTP cipher suits defined provides source authentication = properties that allow an endpoint to cryptographically assert that it sent = a particular E2E protected packet. Instead, the common property is that on= e can determine only that any endpoint that has received the KEK has produced the packet.

Magnus, I=E2=80=99m just a bit confused on what the above t= wo senses are trying to say - can you just expand it out a bit more so I ge= t it. I think I am struggling with what cipher you refer to in the first se= ntense.=C2=A0

The single SRTP cipher suit that exists that provides any stronger sourc= e authentication property than, one of those that have the key has generate= d this message, is to my knowledge TESLA (RFC=C2=A0 4383).

Let me cite one paragraph from Section 3.1 of RFC 7201: 

   The source authentication guarantees provided by SRTP depend on the
   cryptographic transform and key management used.  Some transforms
   give strong source authentication even in multiparty sessions; others
   give weaker guarantees and can authenticate group membership but not
   sources.  Timed Efficient Stream Loss-Tolerant Authentication (TESLA)
   [RFC4383] offers a complement to the regular symmetric keyed
   authentication transforms, like HMAC-SHA-1, and can provide
   per-source authentication in some group communication scenarios.  The
   downside is the need for buffering the packets for a while before
   authenticity can be verified.

So as DOUBLE is AES-GCM which falls into the symmetric cipher suits, or= cryptographic transform as I think SRTP actually calls it, the only source= authentication provided is that who ever generated the packet has the key.= If one have the KEK, one will also receive all endpoints used master key and can derive the actual used key t= hat protects the inner payload and generates the integrity tag. Thus, unles= s the involved parties has been compromised, the source authentication stat= ement provide is: Someone that was given the KEK has generated this inner protected packet.

You are welcome to formulate this property however you want that you thi= nk makes sense.

Cheers=20

Magnus Westerlund=20

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------
--------=_MB800EBB8C-8C3F-4CB5-A6C9-38B4E4C3CCCB-- From nobody Tue May 21 07:31:44 2019 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C0F120020; Tue, 21 May 2019 07:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 5Ubf8bLQvwgO; Tue, 21 May 2019 07:31:38 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00047.outbound.protection.outlook.com [40.107.0.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45C62120157; Tue, 21 May 2019 07:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fH6cnOeBMkOSXcWiTxkePT/AOTBS0IeSvK/S91bzPLY=; b=NjultemQy+MVT7k3wfMiwUC5bWGkPaVMyKe+UOVrhqjkkSG63qv2xCL1fTpmu9GNhEnDCnSMZYV7wopkcTIgVvbHZxtDNkWUcrEqwPiVMTbYCSX9TARG2tnmyjz7a6s9ChNp/tY2Q6NUvYvnYJKVZO1+c9NM352qFBkSZehPvn4= Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2825.eurprd07.prod.outlook.com (10.168.96.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.6; Tue, 21 May 2019 14:31:26 +0000 Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::896a:7ada:8bc9:d99d]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::896a:7ada:8bc9:d99d%6]) with mapi id 15.20.1922.013; Tue, 21 May 2019 14:31:26 +0000 From: Magnus Westerlund To: "Paul E. Jones" , "fluffy@iii.ca" CC: "perc-chairs@ietf.org" , "iesg@ietf.org" , "nohlmeier@mozilla.com" , "perc@ietf.org" , "draft-ietf-perc-private-media-framework@ietf.org" Thread-Topic: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT) Thread-Index: AQHVD+HePj9MsLdQ6Eu4SCPlSQvv7w== Date: Tue, 21 May 2019 14:31:25 +0000 Message-ID: References: <155786852996.30194.6992264311523885594.idtracker@ietfa.amsl.com> <234A5249-3D7B-468C-9A77-72DBBF5CF46A@iii.ca> <1558427057.31263.3.camel@ericsson.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 899beb5f-26d8-4d2b-c448-08d6ddf901fb x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2825; x-ms-traffictypediagnostic: HE1PR0701MB2825: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0044C17179 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(396003)(346002)(366004)(376002)(13464003)(52314003)(51444003)(189003)(199004)(3846002)(6246003)(4326008)(316002)(76176011)(25786009)(6116002)(14444005)(256004)(53936002)(52536014)(14454004)(7696005)(446003)(5660300002)(486006)(44832011)(476003)(33656002)(102836004)(19627405001)(66066001)(7736002)(8676002)(55016002)(54896002)(9686003)(236005)(53546011)(2501003)(6436002)(26005)(74316002)(99286004)(186003)(86362001)(68736007)(508600001)(66446008)(64756008)(66556008)(66476007)(76116006)(71190400001)(6506007)(73956011)(81166006)(229853002)(54906003)(71200400001)(81156014)(8936002)(66574012)(110136005)(66946007)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2825; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 6Fs3OjKlcD+AElwvoys+YNdJfuRY2Jbaj0lNyRNiHHbymubi8oTBceEWjOTfPgoD/UK1Wrg0TvCD7waBUA26LNoS1ExOgTiWiE5tCUyVBvA00wiQH7whYWL7IDzh1bDq9jhAexvLf06SmaQ3643lGT6GiajqHX+ZheD668nm4iwWqTS5bVD6uDHzEYLFvBExSVoJLCXH8YsQ5BllweQon7a224Grvq6ilm3L/8cq4jbFZ6701JugvOPJuC/Dwll3Gm5eDS/LQ5YnAZew4PVAXuSSRFRdaKjOPDNqh0P8dcU/kvsE/5/3zUmwNddvbUCob+sw6Hy0t6YHIJaJGAdAETyPjUHcCnauF4G5RFcd/U58nAP1nsoWL6wauvm/0VF8fqUA/yZXpKS4vMh/OtyYQxKL30q1TE+P1VIWdHXnlxo= Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB2522054EBB1D8DD8BB7A376795070HE1PR0701MB2522_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 899beb5f-26d8-4d2b-c448-08d6ddf901fb X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2019 14:31:25.6165 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: magnus.westerlund@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2825 Archived-At: Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-media-framework-10: (with DISCUSS and COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2019 14:31:42 -0000 --_000_HE1PR0701MB2522054EBB1D8DD8BB7A376795070HE1PR0701MB2522_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 2019-05-21 16:15, Paul E. Jones wrote: Think we should reference TESLA (RFC 4383) as informational? Otherwise, t= he "one a single..." statement will leave most wondering which one it is. Yes, I think you are correct. /Magnus ------ Original Message ------ From: "Magnus Westerlund" > To: "paulej@packetizer.com" >; "fluffy@iii.ca"= > Cc: "perc-chairs@ietf.org" >; "iesg@ietf.org" >; "nohlmeier@mozilla.com" >; "perc= @ietf.org" >; "dr= aft-ietf-perc-private-media-framework@ietf.org" > Sent: 5/21/2019 4:24:28 AM Subject: Re: Re[2]: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-p= rivate-media-framework-10: (with DISCUSS and COMMENT) Hi, I think the below with the suggested added sentence is good enough for what= needs to be described. Additionally, if an adversary successfully exploits an Endpoint, the adversary could inject media into the conference. One way an adversary could do that is by manipulating the RTP or SRTP software to transmit whatever media the adversary wishes to send. This could involve re-use of the Endpoint's SSRC, a new SSRC, or the SSRC value of an existing endpoint. This is made possible since all conference participants share the same KEK. Only a single SRTP cipher suite defined provides source authentication properties that allow an endpoint to cryptographically assert that it sent a particular E2E protected packet, and its usage is presently not defined for PERC. The suite defined in PERC only allows an Endpoint to determine that whoever sent a packet had received the KEK. Cheers Magnus On m=E5n, 2019-05-20 at 16:11 +0000, Paul E. Jones wrote: Magnus, How about this? Additionally, if an adversary successfully exploits an Endpoint, the adversary could inject media into the conference. One way an adversary could do that is by manipulating the RTP or SRTP software to transmit whatever media the adversary wishes to send. This could involve re-use of the Endpoint's SSRC, a new SSRC, or the SSRC value of an existing endpoint. This is made possible since all conference participants share the same KEK. Only a single SRTP cipher suite defined provides source authentication properties that allow an endpoint to cryptographically assert that it sent a particular E2E protected packet, and its usage is presently not defined for PERC. The suite defined in PERC only allows an Endpoint to determine that whoever sent a packet had received the KEK. I think that might capture the intent. But, is this really useful to speak= of the issue in terms of cipher suites? The text already explains that an= attacker could re-use another endpoint's SSRC. It doesn't explain why, th= ough? Maybe that would be useful? For example, saying right after "of an = existing endpont" something like "This is made possible since all conferenc= e participants share the same KEK. Anyway, I'm OK with inserting whatever you wish. I just want to convey wha= t's most readily understood. Paul ------ Original Message ------ From: "Magnus Westerlund" > To: "Cullen Jennings" > Cc: "Paul Jones" >; "Th= e IESG" >; "nohlmeier@mozilla.com" >; "perc-chairs@ietf.org" >; "perc@ietf.org" <= perc@ietf.org>; "draft-ietf-perc-private-media-framew= ork@ietf.org" > Sent: 5/20/2019 3:10:17 AM Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-private-= media-framework-10: (with DISCUSS and COMMENT) On 2019-05-17 20:24, Cullen Jennings wrote: On May 17, 2019, at 8:22 AM, Magnus Westerlund > wrote: So far only a single SRTP cipher suits defined provides source authenticat= ion properties that allow an endpoint to cryptographically assert that it s= ent a particular E2E protected packet. Instead, the common property is that= one can determine only that any endpoint that has received the KEK has pro= duced the packet. Magnus, I=92m just a bit confused on what the above two senses are trying t= o say - can you just expand it out a bit more so I get it. I think I am str= uggling with what cipher you refer to in the first sentense. The single SRTP cipher suit that exists that provides any stronger source a= uthentication property than, one of those that have the key has generated t= his message, is to my knowledge TESLA (RFC 4383). Let me cite one paragraph from Section 3.1 of RFC 7201: The source authentication guarantees provided by SRTP depend on the cryptographic transform and key management used. Some transforms give strong source authentication even in multiparty sessions; others give weaker guarantees and can authenticate group membership but not sources. Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [RFC4383] offers a complement to the regular symmetric keyed authentication transforms, like HMAC-SHA-1, and can provide per-source authentication in some group communication scenarios. The downside is the need for buffering the packets for a while before authenticity can be verified. So as DOUBLE is AES-GCM which falls into the symmetric cipher suits, or cry= ptographic transform as I think SRTP actually calls it, the only source aut= hentication provided is that who ever generated the packet has the key. If = one have the KEK, one will also receive all endpoints used master key and c= an derive the actual used key that protects the inner payload and generates= the integrity tag. Thus, unless the involved parties has been compromised,= the source authentication statement provide is: Someone that was given the= KEK has generated this inner protected packet. You are welcome to formulate this property however you want that you think = makes sense. Cheers Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- -- Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --_000_HE1PR0701MB2522054EBB1D8DD8BB7A376795070HE1PR0701MB2522_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
On 2019-05-21 16:15, Paul E. Jones wrote:
Think we should reference TESLA (RFC  4383) as informational?  Otherwise, the "one a s= ingle..." statement will leave most wondering which one it is.<= /div>

Yes, I think you are correct. 

/Magnus



------ Original Message ------
From: "Magnus Westerlund" <magnus.westerlund@ericsson.com= >
Sent: 5/21/2019 4:24:28 AM
Subject: Re: Re[2]: [Perc] Magnus Westerlund's Discuss on draft-ietf-p= erc-private-media-framework-10: (with DISCUSS and COMMENT)

Hi,

I think the below with the suggested added sentence is good enough for= what needs to be described. 

Additionally, if an adversary successfully exploits an Endpoint, the
adversary could inject media into the conference. One way an adversary=
could do that is by manipulating the RTP or SRTP software to transmit<= /div>
whatever media the adversary wishes to send.  This could inv= olve
re-use of the Endpoint's SSRC, a new SSRC, or the SSRC value of an exi= sting
endpoint. This is made possible since all conference participants shar= e
the same KEK. Only a single SRTP cipher suite defined provides source<= /div>
authentication properties that allow an endpoint to cryptographically<= /div>
assert that it sent a particular E2E protected packet, and its usage i= s
presently not defined for PERC.  The suite defined in PERC o= nly allows
an Endpoint to determine that whoever sent a packet had received the K= EK.

Cheers

Magnus

On m=E5n, 2019-05-20 at 16:11 +0000, Paul E. Jones wrote:
Magnus,

How about this?

Additionally, if an adversary su= ccessfully exploits an Endpoint, the
adversary could inject media into the conference. One way an adversary
could do that is by manipulating the RTP or SRTP software to transmit
whatever media the adversary wishes to send.  This could involve
re-use of the Endpoint's SSRC, a new SSRC, or the SSRC value of an existing=
endpoint. This is made possible since all conference parti= cipants share
the same KEK. Only a single SRTP cipher suite defined provides source
authentication properties that a= llow an endpoint to cryptographically
assert that it sent a particular E2E protected packet, and its usage is
presently not defined for PERC.  The suite defined in PERC only allows=
an Endpoint to determine that whoever sent a packet had received the KEK.


I think that might capture the intent.  But, is this really usefu= l to speak of the issue in terms of cipher suites?  The text already e= xplains that an attacker could re-use another endpoint's SSRC.  It doe= sn't explain why, though?  Maybe that would be useful?  For example, saying right after "of an existing endpont= " something like "This is made possible since all conference
participants share the same KEK.

Anyway, I'm OK with inserting whatever you wish.  I just want to = convey what's most readily understood.

Paul

------ Original Message ------
From: "Magnus Westerlund" <magnus.westerlund@ericsson.com= >
To: "Cullen Jennings" <fluffy@iii.ca>
Sent: 5/20/2019 3:10:17 AM
Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-pri= vate-media-framework-10: (with DISCUSS and COMMENT)

On 2019-05-17 20:24, Cullen Jennings wrote:<= br>


On May 17, 2019, at 8:22 AM, Magnus Westerlund <magnus.= westerlund@ericsson.com> wrote:

 So far only a single SRTP cipher suits defined provides source authentication= properties that allow an endpoint to cryptographically assert that it sent= a particular E2E protected packet. Instead, the common property is that on= e can determine only that any endpoint that has received the KEK has produced the packet.

Magnus, I=92m just a bit confused on what the above two sen= ses are trying to say - can you just expand it out a bit more so I get it. = I think I am struggling with what cipher you refer to in the first sentense= . 

The single SRTP cipher suit that exists that provides any stronger sourc= e authentication property than, one of those that have the key has generate= d this message, is to my knowledge TESLA (RFC  4383).

Let me cite one paragraph from Section 3.1 of RFC 7201: 

   The source authentication guarantees provided by SRTP depend on the=
=0A=
   cryptographic transform and key management used.  Some transforms=0A=
   give strong source authentication even in multiparty sessions; others=0A=
   give weaker guarantees and can authenticate group membership but not=0A=
   sources.  Timed Efficient Stream Loss-Tolerant Authentication (TESLA)=0A=
   [RFC4383] offers a complement to the regular symmetric keyed=0A=
   authentication transforms, like HMAC-SHA-1, and can provide=0A=
   per-source authentication in some group communication scenarios.  The=0A=
   downside is the need for buffering the packets for a while before=0A=
   authenticity can be verified.

So as DOUBLE is AES-GCM which falls into the symmetric cipher suits, or = cryptographic transform as I think SRTP actually calls it, the only source = authentication provided is that who ever generated the packet has the key. = If one have the KEK, one will also receive all endpoints used master key and can derive the actual used key t= hat protects the inner payload and generates the integrity tag. Thus, unles= s the involved parties has been compromised, the source authentication stat= ement provide is: Someone that was given the KEK has generated this inner protected packet.

You are welcome to formulate this property however you want that you thi= nk makes sense.

Cheers =0A=
=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A=
----------------------------------------------------------------------



-- =0A=
=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.=
com=0A=
----------------------------------------------------------------------



--_000_HE1PR0701MB2522054EBB1D8DD8BB7A376795070HE1PR0701MB2522_--


From nobody Tue May 21 12:25:15 2019
Return-Path: 
X-Original-To: perc@ietf.org
Delivered-To: perc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCB7120025; Tue, 21 May 2019 12:25:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: perc@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: perc@ietf.org
Message-ID: <155846670783.2625.15985045654905814426@ietfa.amsl.com>
Date: Tue, 21 May 2019 12:25:07 -0700
Archived-At: 
Subject: [Perc] I-D Action: draft-ietf-perc-private-media-framework-11.txt
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Privacy Enhanced RTP Conferencing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 May 2019 19:25:08 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Privacy Enhanced RTP Conferencing WG of the IETF.

        Title           : A Solution Framework for Private Media in Privacy Enhanced RTP Conferencing (PERC)
        Authors         : Paul E. Jones
                          David Benham
                          Christian Groves
	Filename        : draft-ietf-perc-private-media-framework-11.txt
	Pages           : 28
	Date            : 2019-05-21

Abstract:
   This document describes a solution framework for ensuring that media
   confidentiality and integrity are maintained end-to-end within the
   context of a switched conferencing environment where media
   distributors are not trusted with the end-to-end media encryption
   keys.  The solution builds upon existing security mechanisms defined
   for the real-time transport protocol (RTP).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-perc-private-media-framework-11
https://datatracker.ietf.org/doc/html/draft-ietf-perc-private-media-framework-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-private-media-framework-11


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/