From nobody Fri Aug 2 11:49:01 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 C42011207DE for ; Fri, 2 Aug 2019 11:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 Shm_ILyCGyZO for ; Fri, 2 Aug 2019 11:48:56 -0700 (PDT) Received: from mail-oi1-f195.google.com (mail-oi1-f195.google.com [209.85.167.195]) (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 458F91207E1 for ; Fri, 2 Aug 2019 11:48:54 -0700 (PDT) Received: by mail-oi1-f195.google.com with SMTP id c15so2163028oic.3 for ; Fri, 02 Aug 2019 11:48:54 -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=GYxQR2Vn41Rc+HX6KHQfejw66Ji3Kji3BPFgIkW6VYM=; b=JP6RoUSQDf7K+ckbkeww4JgyhrSG+soQvXHF0DNBLCgGc35xvhHiriF3BR/4v/kyqt olJtHXi4/+jcHgRFf5GH1yl55RnBq649nOkHccTzM4HhDZSU+TIWqeUfcpMFzAPcjoVb Q2pqG/G22otaCce93xeEpQIjP/0W7aOI6TCty67Xy2XB45e+ZxHlLIhjKHqcP4lRJ2lJ E4NK8+yecpzXp+FgOkTZyTSqBZ+uFYhvorUC+wGPRJ+C77WzyxcqMKyXWM9tJ9cxd6SH vQsKW6n8CIPRAa3Q0zR1aqzHEpuDqVI2i30H1dhhkuWlhMalVtKPoz/OGW95pM9n/rFn ki/g== 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=GYxQR2Vn41Rc+HX6KHQfejw66Ji3Kji3BPFgIkW6VYM=; b=OMxfFlp1SC7r7zbywhTZhK32xRTTL6pNjesrkhLx7NP4+Uqdu95UXaXUimmXCgI0Q1 nWAbm5Yn9zwUK4GZdNZgIoQQMaqvIu2ksSDSW7P6cF7A9FflwTThs1SBgus6MoT0wXPt XVLzz5W1PqqrGmj0gSGsH1/27+AxDDQgkjczhHpRvSycKHGjCr0oNSBqXqZjFBhqpR9R H8Jv5lBiVvPPsH2/LfW7LcUWaow1tLaarvTpCjmj11rF8e6RFoYR35AQY45t71Bld79q 4RKwxOCy+D9AWLJslpw3Ajq+TbRz5qDTAtG5r1wdqb1ieNpKJsI2m73Zj00kTkbjXl9A GNMw== X-Gm-Message-State: APjAAAWOf2XkqT9sqN2qDyvFuOY7iGWhmYrgk2Q7Ra1jFifl0a+a0jgi eErrQuPjE794igSRFf5lDtY0tKWrM2/M1+v5MhvNBQ== X-Google-Smtp-Source: APXvYqzNpnY4Don7MHfEBZEJydfr2N3e00oKM0GURshV0zz0c3qO0RbDohZOhlpKCouXeF+hojVWTm84T7Rh6iEYtb4= X-Received: by 2002:aca:5410:: with SMTP id i16mr3513871oib.36.1564771733146; Fri, 02 Aug 2019 11:48:53 -0700 (PDT) MIME-Version: 1.0 References: <156339433620.25783.14611652111059201524.idtracker@ietfa.amsl.com> In-Reply-To: <156339433620.25783.14611652111059201524.idtracker@ietfa.amsl.com> From: Richard Barnes Date: Fri, 2 Aug 2019 13:48:11 -0500 Message-ID: To: Benjamin Kaduk 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="0000000000004f2187058f26cf5f" Archived-At: Subject: Re: [Perc] Benjamin Kaduk's Discuss on draft-ietf-perc-srtp-ekt-diet-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, 02 Aug 2019 18:49:00 -0000 --0000000000004f2187058f26cf5f Content-Type: text/plain; charset="UTF-8" On Wed, Jul 17, 2019 at 3:12 PM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-perc-srtp-ekt-diet-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-srtp-ekt-diet/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for the updates in the -10; we're making progress. I think there > are still some issues left to resolve, though. > > My previous position had: > > """I think we need to discuss whether the mechanism described in Section > 4.1 > contains an EKT-specific extension mechanism or is in fact a more general > mechanism for including extensions in SRTP packets outside the SRTP > cryptographic protection. (If so, we would probably need to Update 3711 to > indicate as much, and perhaps allow for multiple extension types to be > present adjacently.) In particular, how would this EKT extension interact > with any other future mechanism that needs to add data to SRTP packets > outside the SRTP cryptographic wrapper?""" > > I think I remember having such a discussion, but cannot find any record of > it. Does anyone have a pointer handy (or a corrective to my memory)? > We may have had one in person, but I'm not seeing one in my email history either. The short answer is that I don't think any generalization is needed. The longer version is: RTP and SRTP packet formats are not intended to self-describing. Instead, they rely heavily on external negotiation to tell the endpoint how to parse the packet. For example, there is no standard format for the RTP extension field; the format of the field (and even the identifiers for individual extensions used therein) are negotiated in SDP. In this context, that means that it's up to the application to make good decisions about which extensions apply. Note that EKT is already incompatible with the SRTP MKI mechanism (as noted in the document), as an example of the types of incompatibilities that application need to navigate. > Similarly, I don't remember any discussion on: > > """I also think we need to discuss whether it is appropriate to set a > precedent that any standards-track protocol can get a dedicated TLS > HandshakeType (noting that this is a potentially scarce one-octet field. > Would it be more appropriate to define a generic "key transport" container > that can be generally applicable to many protocols, and have an internal > extension point that allows for an SRTP+EKT-specific usage within the TLS > HandshakeType?""" > > We are also still waiting on IANA, if I understand correctly. I do not see > any indication that the needed expert review for TLS ExtensionType > allocation has been requested (the authors should initiate this, per RFC > 8447), and there may have been other matters that needed clarification. > On the HandshakeType: The authors had a fairly extensive (but unfortunately off-list) discussion with EKR about how to transmit the EKT key. After evaluating the full range of options -- from EncryptedExtensions all the way to the application layer -- the conclusion of that discussion was that a HandshakeType fit best with the requirements here. I'm not sure I understand your worry about the scarcity of HandshakeType values. "Any standards-track protocol" is basically the highest bar we have; what more would you ask? Practically speaking, we are defining new HandshakeType values at a high enough rate that we seem likely to exhaust the pool. On the ExtensionType: Thanks for calling that out; I have sent a request to the mailing list. Is there a reason that IANA doesn't send those emails, like they do with other approvals from designated experts? --Richard > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > [original comment section unchanged; contents likely stale] > > There is no cryptographic binding between the EKTCiphertext and the main > SRTP packet, nor is there an authentication tag on the EKTCiphertext that > protects the SPI or length fields (or, for that matter, the message type). > The consequences of this are probably minor, given that an attacker who can > tamper with them could also tamper with the main plaintext, but there is > perhaps potential for causing trouble later in the pipeline, especially > since (as this document admits) there is the possibility of SRTP transforms > that do not provide integrity protection. > > The EKT is a group shared symmetric key, with all the usual caveats that > any group member can spoof a message "from" any other group member. > (Reading the group's messages is of course a necessary feature.) > The EKT is furthermore possessed by the central broker in the portrayed > deployment scenario, allowing the broker access to the plaintext of media > if it did not already have such access. > > It's probably worth mentioning somewhere what the master salt is used for > so the reader not familiar with the details of RFC 3711 is not left > wondering why we are conveying it. > > Section 1 > > This document defines Encrypted Key Transport (EKT) for SRTP and > reduces the amount of external signaling control that is needed in a > SRTP session with multiple receivers. EKT securely distributes the > SRTP master key and other information for each SRTP source. With > this method, SRTP entities are free to choose SSRC values as they see > fit, and to start up new SRTP sources with new SRTP master keys > within a session without coordinating with other entities via > external signaling or other external means. > > I think you need an explanation and/or reference for previous systems that > required central SSRC allocation (or otherwise why the "free to choose" is > noteworthy here). > > EKT provides a way for an SRTP session participant, to securely > transport its SRTP master key and current SRTP rollover counter to > the other participants in the session. [...] > > nit: spurious comma. > > This reduces the amount of CPU time > needed for encryption and can be used for some optimization to media > sending that use source specific multicast. > > nit: I think there's a singular/plural mismatch here. > > Section 4 > > EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key > Identifier) or with SRTP's [RFC3711], as those SRTP > features duplicate some of the functions of EKT. Senders MUST NOT > include MKI when using EKT. Receivers SHOULD simply ignore any MKI > field received if EKT is in use. > > It feels like we're specifically emphasizing the prohibition on EKT with > MKI, and only saying once that EKT with is prohibited. Is there > a reason to have a stronger prohibition of the one than the other? > > Section 4.1 > > The EKTField uses the format defined in Figure 1 for the FullEKTField > and ShortEKTField. > > nit: the ShortEKTField is in Figure 2. > > SRTPMasterKeyLength = BYTE > SRTPMasterKey = 1*256BYTE > SSRC = 4BYTE; SSRC from RTP > ROC = 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC > > nit: is it conventional to all-caps "FOR THE GIVEN"? > > EKTCiphertext: The data that is output from the EKT encryption > operation, described in Section 4.4. This field is included in SRTP > packets when EKT is in use. The length of EKTCiphertext can be > larger than the length of the EKTPlaintext that was encrypted. > > Doesn't it *need* to be larger in order to provide the stated properties? > (I.e., it "will be larger".) > > SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes. This > depends on the cipher suite negotiated for SRTP using SDP Offer/ > Answer [RFC3264] for the SRTP. > > This text would seem to forbid using EKT with any mechanism other than SDP > Offer/Answer for central control. > > Do we want to say why a Message Type of 1 is not usable? > > Section 4.2.2 > > [Isn't there a step 0 to figure out whether any EKT/extensions are in use?] > > 5. If the SSRC in the EKTPlaintext does not match the SSRC of the > SRTP packet received, then all the information from this > EKTPlaintext MUST be discarded and the following steps in this > list are skipped. > > Does this mean I just ignore EKT and attempt to process the SRTP packet > with whatever non-EKT material I have on hand? > > * Unless the transform specifies other acceptable key lengths, > the length of the SRTP Master Key MUST be the same as the > > This is the first usage of "transform" in this document; perhaps a reminder > to the reader that this is a stock SRTP concept is in order. > > master key length for the SRTP transform in use. If this is > not the case, then the receiver MUST abort EKT processing and > SHOULD discared the whole UDP packet. > > nit: The "this" in "if this is not the case" should probably be spelled out > more clearly, as it seems to require both that the master key length is > different from the master key length for the SRTP transform in use and that > the transform specifies other acceptable key lengths. (Presumably the > master key still needs to match one of those other acceptable key lengths, > though?) > > * If the length of the SRTP Master Key is less than the master > key length for the SRTP transform in use, and the transform > specifies that this length is acceptable, then the SRTP Master > Key value is used to replace the first bytes in the existing > master key. [...] > > Do we need to be more clear about what the "existing master key" is? (Are > there reordering issues where we could operate on a different key than > intended?) Also, what do I do if the length of the SRTP master key is > larger than the master key length for the transform in use? > > Section 4.3 > > Section 4.2.1 recommends that SRTP senders continue using an old key > for some time after sending a new key in an EKT tag. Receivers that > wish to avoid packet loss due to decryption failures MAY perform > trial decryption with both the old key and the new key, keeping the > result of whichever decryption succeeds. Note that this approach is > > We have multiple types of key floating around; please be clear about which > ones are which. > > only compatible with SRTP transforms that include integrity > protection. > > What's the guidance for when that's not the case? > > 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 ). If > > Since we knowingly create EKTCiphertexts that are identical, do we count > those as a single encryption or do we count each time we send them? > (I guess Section 4.4 mostly answers this by way of example but a > non-example statement is probably in order.) > > At this point implementation need to either use the > call signaling to renegotiate a new session or need to terminate the > > nit: "call signaling" seems more SIP-specific than necessary. > > The encryption function returns a ciphertext value C whose length is > N bytes, where N may be larger than M. [...] > > (same comment about "may be larger" as above) > > Section 4.4.2 > > An EKTCipher determines how the EKTCiphertext field is written, and > how it is processed when it is read. This field is opaque to the > other aspects of EKT processing. EKT ciphers are free to use this > field in any way, but they SHOULD NOT use other EKT or SRTP fields as > an input. [...] > > Why is this SHOULD NOT instead of MUST NOT? > > Section 4.5 > > Is it worth mentioning (or internally referencing) the 250ms delay before > using the new key? > > Section 5.2.1 > > Given that you're using the DTLS 1.3 handshake structure, why is RFC 5246 > the syntax reference? > > Section 5.2.2 > > If the server did not provide a supported_ekt_ciphers extension in > its ServerHello, then EKTKey messages MUST NOT be sent by the client > or the server. > > The general text and Figure 4 only show EKTKey being sent by the server. > Is it ever allowed to be sent by the client? > > When an EKTKey is received and processed successfully, the recipient > MUST respond with an Ack handshake message as described in Section 7 > of [I-D.ietf-tls-dtls13]. The EKTKey message and Ack MUST be > retransmitted following the rules in Section 4.2.4 of [RFC6347]. > > It is super-weird to cite draft-ietf-tls-dtls13 and RFC 6347 in adjacent > sentences. > > Section 6 > > With EKT, each SRTP sender and receiver MUST generate distinct SRTP > master keys. [...] > > Er, isn't this just senders? > > Note that the inputs of EKT are the same as for SRTP with key- > > "inputs" in terms of shared cryptographic material that is fed into the > SRTP (plus EKT) protocol collection? > > sharing: a single key is provided to protect an entire SRTP session. > However, EKT remains secure even when SSRC values collide. > > I think you need to say more about what "secure" is supposed to mean, here. > > The presence of the SSRC in the EKTPlaintext ensures that an attacker > cannot substitute an EKTCiphertext from one SRTP stream into another > SRTP stream. > > Depends on the attacker; if one of the call participants has the network > positioning to do so, their knowledge of the EKT allows for generating an > EKTCiphertext that matches the SSRC of an arbitrary message. (I guess > technically that involves modifying and not straight substitution of the > EKTCiphertext.) > > 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. > > I think this last sentence went a bit funky; presumably it's "any attacker > that can modify the packets in transit can already cause the SRTP integrity > check to fail even in the absence of EKT". > > An attacker could send packets containing a FullEKTField, in an > attempt to consume additional CPU resources of the receiving system > by causing the receiving system to decrypt the EKT ciphertext and > detect an authentication failure. In some cases, caching the > previous values of the Ciphertext as described in Section 4.3 helps > mitigate this issue. > > I'm not really sure what cases those are supposed to be, since an attacker > can send arbitrary junk and tweak it by a bit each time, and the recipient > has to do the full decryption to validate the integrity IV. > > In a similar vein, EKT has no replay protection, so an attacker could > implant improper keys in receivers by capturing EKTCiphertext values > encrypted with a given EKTKey and replaying them in a different > context, e.g., from a different sender. When the underlying SRTP > > Wouldn't the SSRC check block this particular replay? > > transform provides integrity protection, this attack will just result > in packet loss. If it does not, then it will result in random data > being fed to RTP payload processing. An attacker that is in a > position to mount these attacks, however, could achieve the same > effects more easily without attacking EKT. > > maybe add "by directly modifying the SRTP packet contents"? > > The confidentiality, integrity, and authentication of the EKT cipher > MUST be at least as strong as the SRTP cipher and at least as strong > as the DTLS-SRTP ciphers. > > EKT doesn't carry anything that's an input to DTLS, so shouldn't this > restriction be that the DTLS cipher must be as stront as the EKT one? > > Section 7.1 > > All new EKT messages MUST be defined to have a length as second from > the last element. > > "16-bit", right? > > section 7.4 > > IANA is requested to add ekt_key as a new entry in the "TLS > HandshakeType Registry" table of the "Transport Layer Security (TLS) > Parameters" registry with a reference to this specification, a DTLS- > OK value of "Y", and allocate a value of TBD to for this content > type. > > HandshakeType != content type > > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --0000000000004f2187058f26cf5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 17, 2019 at 3:12 PM Benjamin = Kaduk via Datatracker <noreply@ietf.org> wrote:
Benjamin Kaduk has entered = the following ballot position for
draft-ietf-perc-srtp-ekt-diet-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/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:
----------------------------------------------------------------------

Thanks for the updates in the -10; we're=C2=A0 making progress.=C2=A0 I= think there
are still some issues left to resolve, though.

My previous position had:

"""I think we need to discuss whether the mechanism describe= d in Section 4.1
contains an EKT-specific extension mechanism or is in fact a more general mechanism for including extensions in SRTP packets outside the SRTP
cryptographic protection.=C2=A0 (If so, we would probably need to Update 37= 11 to
indicate as much, and perhaps allow for multiple extension types to be
present adjacently.)=C2=A0 In particular, how would this EKT extension inte= ract
with any other future mechanism that needs to add data to SRTP=C2=A0 packet= s
outside the SRTP cryptographic wrapper?"""

I think I remember having such a discussion, but cannot find any record of<= br> it.=C2=A0 Does anyone have a pointer handy (or a corrective to my memory)?<= br>

We may have had one in person, but I= 9;m not seeing one in my email history either.=C2=A0 The short answer is th= at I don't think any generalization is needed.

=
The longer version is: RTP and SRTP packet formats are not intended to= self-describing.=C2=A0 Instead, they rely heavily on external negotiation = to tell the endpoint how to parse the packet.=C2=A0 For example, there is n= o standard format for the RTP extension field; the format of the field (and= even the identifiers for individual extensions used therein) are negotiate= d in SDP.

In this context, that means that it'= s up to the application to make good decisions about which extensions apply= .=C2=A0 Note that EKT is already incompatible with the SRTP MKI mechanism (= as noted in the document), as an example of the types of incompatibilities = that application need to navigate.

=C2=A0
Similarly, I don't remember any discussion on:

"""I also think we need to discuss whether it is appropriate= to set a
precedent that any standards-track protocol can get a dedicated TLS
HandshakeType (noting that this is a potentially scarce one-octet field. Would it be more appropriate to define a generic "key transport" = container
that can be generally applicable to many protocols, and have an internal extension point that allows for an SRTP+EKT-specific usage within the TLS HandshakeType?"""

We are also still waiting on IANA, if I understand correctly.=C2=A0 I do no= t see
any indication that the needed expert review for TLS ExtensionType
allocation has been requested (the authors should initiate this, per RFC 8447), and there may have been other matters that needed clarification.
=

On the HandshakeType: The authors had a fa= irly extensive (but unfortunately off-list) discussion with EKR about how t= o transmit the EKT key.=C2=A0 After evaluating the full range of options --= from EncryptedExtensions all the way to the application layer -- the concl= usion of that discussion was that a HandshakeType fit best with the require= ments here.=C2=A0 I'm not sure I understand your worry about the scarci= ty of HandshakeType values. "Any standards-track protocol" is bas= ically the highest bar we have; what more would you ask?=C2=A0 Practically = speaking, we are defining new HandshakeType values at a high enough rate th= at we seem likely to exhaust the pool.

On the = ExtensionType: Thanks for calling that out; I have sent a request to the ma= iling list.=C2=A0 Is there a reason that IANA doesn't send those emails= , like they do with other approvals from designated experts?

=
--Richard

=C2=A0


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

[original comment section unchanged; contents likely stale]

There is no cryptographic binding between the EKTCiphertext and the main SRTP packet, nor is there an authentication tag on the EKTCiphertext that protects the SPI or length fields (or, for that matter, the message type).<= br> The consequences of this are probably minor, given that an attacker who can=
tamper with them could also tamper with the main plaintext, but there is perhaps potential for causing trouble later in the pipeline, especially
since (as this document admits) there is the possibility of SRTP transforms=
that do not provide integrity protection.

The EKT is a group shared symmetric key, with all the usual caveats that any group member can spoof a message "from" any other group membe= r.
(Reading the group's messages is of course a necessary feature.)
The EKT is furthermore possessed by the central broker in the portrayed
deployment scenario, allowing the broker access to the plaintext of media if it did not already have such access.

It's probably worth mentioning somewhere what the master salt is used f= or
so the reader not familiar with the details of RFC 3711 is not left
wondering why we are conveying it.

Section 1

=C2=A0 =C2=A0This document defines Encrypted Key Transport (EKT) for SRTP a= nd
=C2=A0 =C2=A0reduces the amount of external signaling control that is neede= d in a
=C2=A0 =C2=A0SRTP session with multiple receivers.=C2=A0 EKT securely distr= ibutes the
=C2=A0 =C2=A0SRTP master key and other information for each SRTP source.=C2= =A0 With
=C2=A0 =C2=A0this method, SRTP entities are free to choose SSRC values as t= hey see
=C2=A0 =C2=A0fit, and to start up new SRTP sources with new SRTP master key= s
=C2=A0 =C2=A0within a session without coordinating with other entities via<= br> =C2=A0 =C2=A0external signaling or other external means.

I think you need an explanation and/or reference for previous systems that<= br> required central SSRC allocation (or otherwise why the "free to choose= " is
noteworthy here).

=C2=A0 =C2=A0EKT provides a way for an SRTP session participant, to securel= y
=C2=A0 =C2=A0transport its SRTP master key and current SRTP rollover counte= r to
=C2=A0 =C2=A0the other participants in the session.=C2=A0 [...]

nit: spurious comma.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This reduces the amount of CP= U time
=C2=A0 =C2=A0needed for encryption and can be used for some optimization to= media
=C2=A0 =C2=A0sending that use source specific multicast.

nit: I think there's a singular/plural mismatch here.

Section 4

=C2=A0 =C2=A0EKT MUST NOT be used in conjunction with SRTP's MKI (Maste= r Key
=C2=A0 =C2=A0Identifier) or with SRTP's <From, To> [RFC3711], as = those SRTP
=C2=A0 =C2=A0features duplicate some of the functions of EKT.=C2=A0 Senders= MUST NOT
=C2=A0 =C2=A0include MKI when using EKT.=C2=A0 Receivers SHOULD simply igno= re any MKI
=C2=A0 =C2=A0field received if EKT is in use.

It feels like we're specifically emphasizing the prohibition on EKT wit= h
MKI, and only saying once that EKT with <From, To> is prohibited.=C2= =A0 Is there
a reason to have a stronger prohibition of the one than the other?

Section 4.1

=C2=A0 =C2=A0The EKTField uses the format defined in Figure 1 for the FullE= KTField
=C2=A0 =C2=A0and ShortEKTField.

nit: the ShortEKTField is in Figure 2.

=C2=A0 =C2=A0 SRTPMasterKeyLength =3D BYTE
=C2=A0 =C2=A0 SRTPMasterKey =3D 1*256BYTE
=C2=A0 =C2=A0 SSRC =3D 4BYTE; SSRC from RTP
=C2=A0 =C2=A0 ROC =3D 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC

nit: is it conventional to all-caps "FOR THE GIVEN"?

=C2=A0 =C2=A0EKTCiphertext: The data that is output from the EKT encryption=
=C2=A0 =C2=A0operation, described in Section 4.4.=C2=A0 This field is inclu= ded in SRTP
=C2=A0 =C2=A0packets when EKT is in use.=C2=A0 The length of EKTCiphertext = can be
=C2=A0 =C2=A0larger than the length of the EKTPlaintext that was encrypted.=

Doesn't it *need* to be larger in order to provide the stated propertie= s?
(I.e., it "will be larger".)

=C2=A0 =C2=A0SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes.= =C2=A0 This
=C2=A0 =C2=A0depends on the cipher suite negotiated for SRTP using SDP Offe= r/
=C2=A0 =C2=A0Answer [RFC3264] for the SRTP.

This text would seem to forbid using EKT with any mechanism other than SDP<= br> Offer/Answer for central control.

Do we want to say why a Message Type of 1 is not usable?

Section 4.2.2

[Isn't there a step 0 to figure out whether any EKT/extensions are in u= se?]

=C2=A0 =C2=A05.=C2=A0 If the SSRC in the EKTPlaintext does not match the SS= RC of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0SRTP packet received, then all the information f= rom this
=C2=A0 =C2=A0 =C2=A0 =C2=A0EKTPlaintext MUST be discarded and the following= steps in this
=C2=A0 =C2=A0 =C2=A0 =C2=A0list are skipped.

Does this mean I just ignore EKT and attempt to process the SRTP packet
with whatever non-EKT material I have on hand?

=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 Unless the transform specifies other acc= eptable key lengths,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the length of the SRTP Master Key MUST b= e the same as the

This is the first usage of "transform" in this document; perhaps = a reminder
to the reader that this is a stock SRTP concept is in order.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 master key length for the SRTP transform= in use.=C2=A0 If this is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 not the case, then the receiver MUST abo= rt EKT processing and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SHOULD discared the whole UDP packet.
nit: The "this" in "if this is not the case" should pro= bably be spelled out
more clearly, as it seems to require both that the master key length is
different from the master key length for the SRTP transform in use and that=
the transform specifies other acceptable key lengths.=C2=A0 (Presumably the=
master key still needs to match one of those other acceptable key lengths,<= br> though?)

=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 If the length of the SRTP Master Key is = less than the master
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key length for the SRTP transform in use= , and the transform
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 specifies that this length is acceptable= , then the SRTP Master
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Key value is used to replace the first b= ytes in the existing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 master key.=C2=A0 [...]

Do we need to be more clear about what the "existing master key" = is?=C2=A0 (Are
there reordering issues where we could operate on a different key than
intended?)=C2=A0 Also, what do I do if the length of the SRTP master key is=
larger than the master key length for the transform in use?

Section 4.3

=C2=A0 =C2=A0Section 4.2.1 recommends that SRTP senders continue using an o= ld key
=C2=A0 =C2=A0for some time after sending a new key in an EKT tag.=C2=A0 Rec= eivers that
=C2=A0 =C2=A0wish to avoid packet loss due to decryption failures MAY perfo= rm
=C2=A0 =C2=A0trial decryption with both the old key and the new key, keepin= g the
=C2=A0 =C2=A0result of whichever decryption succeeds.=C2=A0 Note that this = approach is

We have multiple types of key floating around; please be clear about which<= br> ones are which.

=C2=A0 =C2=A0only compatible with SRTP transforms that include integrity =C2=A0 =C2=A0protection.

What's the guidance for when that's not the case?

=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 ).= =C2=A0 If

Since we knowingly create EKTCiphertexts that are identical, do we count those as a single encryption or do we count each time we send them?
(I guess Section 4.4 mostly answers this by way of example but a
non-example statement is probably in order.)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 At th= is point implementation need to either use the
=C2=A0 =C2=A0call signaling to renegotiate a new session or need to termina= te the

nit: "call signaling" seems more SIP-specific than necessary.

=C2=A0 =C2=A0The encryption function returns a ciphertext value C whose len= gth is
=C2=A0 =C2=A0N bytes, where N may be larger than M.=C2=A0 [...]

(same comment about "may be larger" as above)

Section 4.4.2

=C2=A0 =C2=A0An EKTCipher determines how the EKTCiphertext field is written= , and
=C2=A0 =C2=A0how it is processed when it is read.=C2=A0 This field is opaqu= e to the
=C2=A0 =C2=A0other aspects of EKT processing.=C2=A0 EKT ciphers are free to= use this
=C2=A0 =C2=A0field in any way, but they SHOULD NOT use other EKT or SRTP fi= elds as
=C2=A0 =C2=A0an input.=C2=A0 [...]

Why is this SHOULD NOT instead of MUST NOT?

Section 4.5

Is it worth mentioning (or internally referencing) the 250ms delay before using the new key?

Section 5.2.1

Given that you're using the DTLS 1.3 handshake structure, why is RFC 52= 46
the syntax reference?

Section 5.2.2

=C2=A0 =C2=A0If the server did not provide a supported_ekt_ciphers extensio= n in
=C2=A0 =C2=A0its ServerHello, then EKTKey messages MUST NOT be sent by the = client
=C2=A0 =C2=A0or the server.

The general text and Figure 4 only show EKTKey being sent by the server. Is it ever allowed to be sent by the client?

=C2=A0 =C2=A0When an EKTKey is received and processed successfully, the rec= ipient
=C2=A0 =C2=A0MUST respond with an Ack handshake message as described in Sec= tion 7
=C2=A0 =C2=A0of [I-D.ietf-tls-dtls13].=C2=A0 The EKTKey message and Ack MUS= T be
=C2=A0 =C2=A0retransmitted following the rules in Section 4.2.4 of [RFC6347= ].

It is super-weird to cite draft-ietf-tls-dtls13 and RFC 6347 in adjacent sentences.

Section 6

=C2=A0 =C2=A0With EKT, each SRTP sender and receiver MUST generate distinct= SRTP
=C2=A0 =C2=A0master keys.=C2=A0 [...]

Er, isn't this just senders?

=C2=A0 =C2=A0Note that the inputs of EKT are the same as for SRTP with key-=

"inputs" in terms of shared cryptographic material that is fed in= to the
SRTP (plus EKT) protocol collection?

=C2=A0 =C2=A0sharing: a single key is provided to protect an entire SRTP se= ssion.
=C2=A0 =C2=A0However, EKT remains secure even when SSRC values collide.

I think you need to say more about what "secure" is supposed to m= ean, here.

=C2=A0 =C2=A0The presence of the SSRC in the EKTPlaintext ensures that an a= ttacker
=C2=A0 =C2=A0cannot substitute an EKTCiphertext from one SRTP stream into a= nother
=C2=A0 =C2=A0SRTP stream.

Depends on the attacker; if one of the call participants has the network positioning to do so, their knowledge of the EKT allows for generating an EKTCiphertext that matches the SSRC of an arbitrary message.=C2=A0 (I guess=
technically that involves modifying and not straight substitution of the EKTCiphertext.)

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

I think this last sentence went a bit funky; presumably it's "any = attacker
that can modify the packets in transit can already cause the SRTP integrity=
check to fail even in the absence of EKT".

=C2=A0 =C2=A0An attacker could send packets containing a FullEKTField, in a= n
=C2=A0 =C2=A0attempt to consume additional CPU resources of the receiving s= ystem
=C2=A0 =C2=A0by causing the receiving system to decrypt the EKT ciphertext = and
=C2=A0 =C2=A0detect an authentication failure.=C2=A0 In some cases, caching= the
=C2=A0 =C2=A0previous values of the Ciphertext as described in Section 4.3 = helps
=C2=A0 =C2=A0mitigate this issue.

I'm not really sure what cases those are supposed to be, since an attac= ker
can send arbitrary junk and tweak it by a bit each time, and the recipient<= br> has to do the full decryption to validate the integrity IV.

=C2=A0 =C2=A0In a similar vein, EKT has no replay protection, so an attacke= r could
=C2=A0 =C2=A0implant improper keys in receivers by capturing EKTCiphertext = values
=C2=A0 =C2=A0encrypted with a given EKTKey and replaying them in a differen= t
=C2=A0 =C2=A0context, e.g., from a different sender.=C2=A0 When the underly= ing SRTP

Wouldn't the SSRC check block this particular replay?

=C2=A0 =C2=A0transform provides integrity protection, this attack will just= result
=C2=A0 =C2=A0in packet loss.=C2=A0 If it does not, then it will result in r= andom data
=C2=A0 =C2=A0being fed to RTP payload processing.=C2=A0 An attacker that is= in a
=C2=A0 =C2=A0position to mount these attacks, however, could achieve the sa= me
=C2=A0 =C2=A0effects more easily without attacking EKT.

maybe add "by directly modifying the SRTP packet contents"?

=C2=A0 =C2=A0The confidentiality, integrity, and authentication of the EKT = cipher
=C2=A0 =C2=A0MUST be at least as strong as the SRTP cipher and at least as = strong
=C2=A0 =C2=A0as the DTLS-SRTP ciphers.

EKT doesn't carry anything that's an input to DTLS, so shouldn'= t this
restriction be that the DTLS cipher must be as stront as the EKT one?

Section 7.1

=C2=A0 =C2=A0All new EKT messages MUST be defined to have a length as secon= d from
=C2=A0 =C2=A0the last element.

"16-bit", right?

section 7.4

=C2=A0 =C2=A0IANA is requested to add ekt_key as a new entry in the "T= LS
=C2=A0 =C2=A0HandshakeType Registry" table of the "Transport Laye= r Security (TLS)
=C2=A0 =C2=A0Parameters" registry with a reference to this specificati= on, a DTLS-
=C2=A0 =C2=A0OK value of "Y", and allocate a value of TBD to for = this content
=C2=A0 =C2=A0type.

HandshakeType !=3D content type


_______________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc
--0000000000004f2187058f26cf5f-- From nobody Fri Aug 2 13:33:24 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 BE5D112013B for ; Fri, 2 Aug 2019 13:33:22 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3gz5GUjwWdu0 for ; Fri, 2 Aug 2019 13:33:19 -0700 (PDT) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 AB377120134 for ; Fri, 2 Aug 2019 13:33:19 -0700 (PDT) Received: by mail-vs1-xe29.google.com with SMTP id h28so52117248vsl.12 for ; Fri, 02 Aug 2019 13:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ekI6Jont6OuGOs9FfhBbb5giaVm3xbJSdnnpWaoyIgw=; b=T9w/ZZUziJL9vpcsc6ktciL2xJv6rpJ+/1/THYJl6OB3o0VxFACfuPtU74X2OZ2/qW eJgT1Gj0FxVjd2q1PjSxl0HjPhBJv74QwQBK66LwL/70IE2042Gpdg58BF8LpdtMSnqd gyRjJPdImkKB8zjeV9god/GXLFrrGYM49RhpXPgezVVVxyUMm+497Cg/3q71QLumGtQF Q8aVPrmg4g+QoLfir0wXzcx+dJyxdrbu7XjTbWDsRXYRR17kEIKr9V58lexiBUVy7t1j QR5mSUWGK+BSrsGFyKyj2z2VSja4vI6whI08+Ou9K5eKegW8NrH1+G4E/3dUCgH5kOql 9Gsg== 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=ekI6Jont6OuGOs9FfhBbb5giaVm3xbJSdnnpWaoyIgw=; b=S03y86qQvg1gqP/BSacOLPAXZf4WncBP3FOrtTkVhGChjp/+DSPHsDcUsRT9KbK3aV HxXlRANax6CtR46qlhu4iEAviiN5Kcs66yiZiEUfCx52T8XmoJFMc3e4a3zndlxmoewj y3aMU1ffJLY9LMaTvLYeUT4bphOi/bOo2X0H3szdUWE1mjzmvOKNQKw4jGW/oHUpuy9j ksfZWbklW8Cw5Ty/CJvuc5g6Jgvzq43mW0+kp7Fy+NjdXr7/toF+ZIGPDQ68D9OvZdF+ Kog+zI7UsB45LYQv/VDpePBvFALbWh8sekwdsL/5XnhngkP0Z2gbaiX9UTxYE08hA6gw 12TA== X-Gm-Message-State: APjAAAVfx9DyEIcMPIyTuBb+b3ZgBmyiVr8A/mvvIlB3r11O4bgjCr9b p2cP2qDxg0iiqTTVdAfF36U0dG/IlUH68HlUiic= X-Google-Smtp-Source: APXvYqz5qU1kdlycP9/cGTtH8MhAd07KbyMfN8f6yzLxOqbp3XaBlUHTQ9jjOJfnqhuQkLWMy0K1q6NcZO4eK6tUxTE= X-Received: by 2002:a67:fe5a:: with SMTP id m26mr61291298vsr.230.1564777998768; Fri, 02 Aug 2019 13:33:18 -0700 (PDT) MIME-Version: 1.0 References: <156262385467.745.6643466213611763109@ietfa.amsl.com> In-Reply-To: <156262385467.745.6643466213611763109@ietfa.amsl.com> From: Suhas Nandakumar Date: Fri, 2 Aug 2019 13:33:08 -0700 Message-ID: To: Magnus Westerlund Cc: Alexey Melnikov , "perc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c4de40058f2844d1" Archived-At: Subject: Re: [Perc] I-D Action: draft-ietf-perc-double-11.txt 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, 02 Aug 2019 20:33:23 -0000 --000000000000c4de40058f2844d1 Content-Type: text/plain; charset="UTF-8" Hi Magnus Could you please verify if the draft-11 addresses your concerns Thanks Suhas On Mon, Jul 8, 2019 at 3:12 PM wrote: > > 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 : SRTP Double Encryption Procedures > Authors : Cullen Jennings > Paul E. Jones > Richard Barnes > Adam Roach > Filename : draft-ietf-perc-double-11.txt > Pages : 18 > Date : 2019-07-08 > > Abstract: > In some conferencing scenarios, it is desirable for an intermediary > to be able to manipulate some parameters in Real Time Protocol (RTP) > packets, while still providing strong end-to-end security guarantees. > This document defines a cryptographic transform for the Secure Real > Time Protocol (SRTP) that uses two separate but related cryptographic > operations to provide hop-by-hop and end-to-end security guarantees. > Both the end-to-end and hop-by-hop cryptographic algorithms can > utilize an authenticated encryption with associated data (AEAD) > algorithm or take advantage of future SRTP transforms with different > properties. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-perc-double/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-perc-double-11 > https://datatracker.ietf.org/doc/html/draft-ietf-perc-double-11 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-double-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/ > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --000000000000c4de40058f2844d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Magnus

=C2=A0 Could you please verify if the draft-11 addresses your con= cerns=C2=A0

Thanks=C2=A0=
Suhas

=C2=A0=C2=A0

On Mon, Jul 8, = 2019 at 3:12 PM <internet-dr= afts@ietf.org> wrote:

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= SRTP Double Encryption Procedures
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Cull= en Jennings
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Paul E. Jones
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Richard Barnes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Adam Roach
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-perc-double-11.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 18
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-07-08

Abstract:
=C2=A0 =C2=A0In some conferencing scenarios, it is desirable for an interme= diary
=C2=A0 =C2=A0to be able to manipulate some parameters in Real Time Protocol= (RTP)
=C2=A0 =C2=A0packets, while still providing strong end-to-end security guar= antees.
=C2=A0 =C2=A0This document defines a cryptographic transform for the Secure= Real
=C2=A0 =C2=A0Time Protocol (SRTP) that uses two separate but related crypto= graphic
=C2=A0 =C2=A0operations to provide hop-by-hop and end-to-end security guara= ntees.
=C2=A0 =C2=A0Both the end-to-end and hop-by-hop cryptographic algorithms ca= n
=C2=A0 =C2=A0utilize an authenticated encryption with associated data (AEAD= )
=C2=A0 =C2=A0algorithm or take advantage of future SRTP transforms with dif= ferent
=C2=A0 =C2=A0properties.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-= perc-double/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-perc-dou= ble-11
https://datatracker.ietf.org/doc/html= /draft-ietf-perc-double-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddra= ft-ietf-perc-double-11


Please note that it may take a couple of minutes from the time of submissio= n
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/

_______________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc
--000000000000c4de40058f2844d1-- From nobody Sun Aug 4 23:32:03 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 7D193120134; Sun, 4 Aug 2019 23:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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=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 9JQFHIdJ9xUi; Sun, 4 Aug 2019 23:32:00 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60057.outbound.protection.outlook.com [40.107.6.57]) (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 89096120059; Sun, 4 Aug 2019 23:31:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=as5E137HYIvgyeQsu/AKJxPmh97ccL+xdVEdq4wA3MP85/XOG6KoPQJbiMAoGSEcjJGEz6IY7kiuMEIFzbLAeuxa0hQFTRLu32cLODQ+j9qqgjirY9GMZ9dwHkqiw4R37KUokKfLPvWOysZPaw+iG+4EtRtYgqCiO19gS+UZYu/pENg0NcWI0IUwy7nMk3Pta56LQEoizDDuVJiwC1jCLCHtOtKpSSS+FqAZvHRtoUFIdDa/CCJ531jdku1beB2xw3iA5lcF9O+d8k4CoZfvbZ5lkmR/aaGANgOiZ1v77Guyu5tlCmmalclYwj/yJM3iM64TCygZNnFBLNTRzhmz5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vcOl6WXcVWzGCvMhMnhPPc/uiPEcGgh/3C7fH2ER0sw=; b=KlsG45W6vKSPnYj16IZbhOXE4NUed9WQ3c0Bsyz8GBSOuPnEG6+b0y7r1qzUr8/LFUsfoqVSn8z8/bB+RoB0SpGZxzEmfaceygxaY/rk6k7Q70o1qHh7uFOyghPlr4Ursy6xYRzpXntsKbkV8bP2cdFvbUwriSNbFpg7yx9yJMKaYnMBoZrRsDAw/D8dBE7S89TiiUqiohg560tfOAKOm7Kl5ROiXI40F9J3QKmKEf/iYEdB90gjpe4wkzNz/fCDeJDAGNScTTlxBjNwYDAtPv/DEO/bTA5GfuZfe+rJni1H2vQwFnNaSmMn4R1tz5JtgOrPb9xdbxzg+8wkkQKT6Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=vcOl6WXcVWzGCvMhMnhPPc/uiPEcGgh/3C7fH2ER0sw=; b=Kq7p1sFI1k9SS0VRGVCOatv5SO5hXRnf5ppR7Sg7I8qox/VG0K/mBbWWjqoSSQmw5g5r9ieLExZuJiGusmC49Tpl9aX0IPuO9765Eg1wIddUKZMLOdmc51bfQ4SjcZurBzaWRY/Vv3dYbpTn3WAj3P10sTyY6qecIavCM8y4e+s= Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2249.eurprd07.prod.outlook.com (10.168.31.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.8; Mon, 5 Aug 2019 06:31:54 +0000 Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b9ec:6368:2a23:30fb]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::b9ec:6368:2a23:30fb%6]) with mapi id 15.20.2157.011; Mon, 5 Aug 2019 06:31:54 +0000 From: Magnus Westerlund To: "fluffy@iii.ca" CC: "iesg@ietf.org" , "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/RAl0Cyrib7XAHyUKZvpqsAgHzvMNA= Date: Mon, 5 Aug 2019 06:31:53 +0000 Message-ID: References: <155800082724.19580.16483563575859435866.idtracker@ietfa.amsl.com> <65737EA1-49AF-4EB9-AD1F-25157B3F010D@iii.ca> In-Reply-To: <65737EA1-49AF-4EB9-AD1F-25157B3F010D@iii.ca> 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: [176.10.164.40] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 91bd7c6f-34cf-411e-97e6-08d7196e9b82 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(49563074)(7193020); SRVR:HE1PR0701MB2249; x-ms-traffictypediagnostic: HE1PR0701MB2249: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01208B1E18 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(136003)(366004)(376002)(346002)(51914003)(13464003)(189003)(199004)(86362001)(5660300002)(14454004)(186003)(33656002)(6916009)(6116002)(3846002)(26005)(6246003)(7736002)(305945005)(316002)(53936002)(68736007)(7696005)(478600001)(53546011)(6506007)(76176011)(8936002)(102836004)(2351001)(99286004)(74316002)(54906003)(8676002)(4326008)(9686003)(2906002)(55016002)(76116006)(81166006)(81156014)(6436002)(1730700003)(66066001)(25786009)(99936001)(14444005)(256004)(71190400001)(71200400001)(229853002)(486006)(5640700003)(66446008)(44832011)(476003)(446003)(11346002)(66476007)(66616009)(66556008)(64756008)(66946007)(2501003)(52536014); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2249; 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: kN9vvvLiXJkDSSyEhHUvEEZOLOqS6cQn+HTzQIo6sLooxBi/g9uwPIp656ZtR8RLvSOQ4A0OeryLY+3oWMq85tHc0Sd1X1GSQdIsKJtLPRGDV4bIb1M+snaWYNgR9LZLej2/dGL7GNe4DStWblzP53a+LZAa8LbaTfD3Ncjin6cmN2dDhFahz2iN/HsMqaf2ob8/Ox9MXKdb3F3evkQe4LpAhBte8/vbSfngCBZbgqh7DT9S7JPEaktCYgPr30FniHJfcZuYWNmIi76KacEwsWUQbALaHkvCkTTRPPbwxRIJ2zX5jVbRRurAfBgWcW3mOnmpcjxSWQpJz2HYQbdRu6ZzYeOdA/KGDnITxtonJDlvs87WbK1kNxIZV62Iz+BRoIIDDFSvxpPl0rSLYLrpajgI66yUp65ND/TtN9UR0Po= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_007D_01D54B68.3BA356E0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 91bd7c6f-34cf-411e-97e6-08d7196e9b82 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Aug 2019 06:31:54.0479 (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: M4XGaah7OFSHqhNqhU/HOyZ6ftY/4thToiK6YxzlsJ5CyQz9m4i0FHmk0Wp3cxvUtETU9s3pq4f8f9zBd3W0YBQnBCPAu2YmxTLXmOXI7D4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2249 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, 05 Aug 2019 06:32:02 -0000 ------=_NextPart_000_007D_01D54B68.3BA356E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, Sorry, I missed when this update was submitted, thanks for the reminder. = The new version addresses most of my discuss, but missed to do anything = about point 1 below.=20 Otherwise it appears to address my discuss points. How do you want to = resolve it?=20 Cheers Magnus Westerlund > -----Original Message----- > From: Cullen Jennings > Sent: den 17 maj 2019 20:34 > To: Magnus Westerlund > Cc: The IESG ; perc-chairs@ietf.org; draft-ietf-perc- > double@ietf.org; suhasietf@gmail.com; perc@ietf.org > Subject: Re: [Perc] Magnus Westerlund's Discuss on = draft-ietf-perc-double- > 10: (with DISCUSS and COMMENT) >=20 > > > > 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. > > >=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 ? >=20 > Perhaps to make it explicitly clear we should change >=20 > "* Payload: The RTP payload of the original packet=E2=80=9D >=20 > to be >=20 > "* Payload (including padding) The RTP payload (including passing) of = the > original packet=E2=80=9D >=20 >=20 >=20 >=20 ------=_NextPart_000_007D_01D54B68.3BA356E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVdjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGBzCCA++gAwIBAgIQ C0ZtzXB7bjBlrrZreXF57TANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMjE1 MDcyMjIzWhcNMjAxMjE1MDcyMjIyWjBwMREwDwYDVQQKDAhFcmljc3NvbjEaMBgGA1UEAwwRTWFn bnVzIFdlc3Rlcmx1bmQxLTArBgkqhkiG9w0BCQEWHm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u LmNvbTEQMA4GA1UEBRMHZXJhbXN3ZDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALCp R2bwd07JixA7T0ohRSgIe90tsAKbfpWqoOXl06qJ6p80/cpBBi9ncfZgU/tlmYiCsaOMNrIrFZdx BGE6l05HLabq+3DdvYCwvBd7SRxiNrFFaTvQMKVazflLhxFXrR7e4XcVvbmHdCySfEz+v8BpCHwB WmcZWVJ+/TtnhxJX4odYlSIk2Vy3BHtawSbc4VDUR1oDptr0JQyeLAqYoBhaucPl0kb4hEDJEGUb 8NQkJm9+UEvwv09+qIMyERw7gHZKEmolDmP0tnS6eB5MLzjoPrQA6Wh5K23ZnZ4yhq2EpyYoJscN eKSboMS/1W9hHlXIKQH1VbLey5uDzj0SPPsCAwEAAaOCAcQwggHAMEgGA1UdHwRBMD8wPaA7oDmG N2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmww gYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNv bTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5s aW5kaXZpZHVhbGNhdjMuY2VyMCkGA1UdEQQiMCCBHm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u LmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcDBAYI KwYBBQUHAwIwHQYDVR0OBBYEFOYr7oaVOdVuFIQQwVsH/F7FPN+2MB8GA1UdIwQYMBaAFBx7GZ6X nHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEAZ9BSrpIN NFDf3PxEqcUiGmE67HfJYhxzLuay6TgTTmnKRjQTBjYFAw7eEIoYaEEd3L4WFwqwDOfTU78NBzZY Kh2aBHlWO2JySWJyVwwi1H5CuQ59vBN0K88pJBeoIlDlw8hfZoVmG0gJCcsdGI9F3PHp98GDcqBW BKo5SrWa3VdKXIBcxHl1S0vA1q80su/in1LQzhIjOh98zt57KvvigZrDokipFp+KGBEWYOShJRAB 4rPWr/tyiGhD5zgLfEEVkaRXxmeHfPRdeqhbxJbqeZ+5fOuBasZwtn64g6OIS0GOhDWjmmCIoV4W 5dlGMQBg5PPWiZv0uaWMqu8M5viityHFJetK5nPEiZbekFysNMFxDhNTLm2rmCjLGndrPIw/qxJF 6fmoE0ZfrHs1mkcRwacblCg3ejIcA4oN0mYtaj+w/w7OFfiSyI41CXNuZfbbzBgvfpaiND/rzCN2 cq6LtDTX2+ebi0GqtfDvuwWfCr+47xXcWMlIG8UNEjxIsocpXCxwJiXiwkGomR5gkRAZAiykn9Du JRNk61c3Tg9/MI87kNu1N1HXVQg/REN7Re6OhFYacSSVJQesXv9lFsMuGZWu9XSi1IWpHVazeWm8 8ahVr8zgE/ZwWth82FQbaW3Luihoe9mCfjO/X2vYiJHEAoFJ8N4CAHlnf/5+GG2NkIQwggbCMIIE qqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlh U29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloX DTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIIC CgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5no rG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3 Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05ZrJldk UgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmbNJ7o58IZ YzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PVtO57HBKH MgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBsbpWIXwM6 kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUOxSqw1wup 5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT9rOdgdgS 3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx5Yd1c5Gs xuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9v Y3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnku dHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQI MAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6 Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6 aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNy bDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQW BBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjAN BgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUB D0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr 0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9 jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBdK/aj dbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0rI0RoGzIC fsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+i5CCKEZc dAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GITb/i7IBd Loo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5mdZ+RzPTo mgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeCaPKkveBJ zqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQC0ZtzXB7bjBl rrZreXF57TAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xOTA4MDUwNjMxNTJaMCMGCSqGSIb3DQEJBDEWBBSxb3DcA7cIl3R4CFBpKpC42Sc6 uTBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhF cmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQC0ZtzXB7bjBl rrZreXF57TBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5 cXntMA0GCSqGSIb3DQEBAQUABIIBAJafJYP+bmPiWxeUV8qCiQa/ImhcgGgwRE4S36unlVqdikG6 zc6BjbSweSPdzyiyKzly/v1ue67DrtrUkN1CEUd7Mj+W5I+G2Ye/6zotBGOcVk4SHv60pN2BVPf+ 81msCu8rVv3us9R/PyngO1KzDCmPfC8rUvV7HCEM5q5LZbiCmTKnWvYvxlaso5VUCFyis9Fj6/UY YWiVrckXbLL1OY0n0i32jeDSXsEQgRxm1P+e9OB/pBkcVvciIuK77ZIGMsVSL2CKJyQTlAIZs/sO Jg2D8l4aQRsJm6Ww+BTIXVl8hsHMgBPWYzTKWqUGTG+NczNe7kcAreSdFJ0wLYDhQa8AAAAAAAA= ------=_NextPart_000_007D_01D54B68.3BA356E0-- From nobody Mon Aug 5 07:48:50 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 4A58C12028E for ; Mon, 5 Aug 2019 07:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 8WBzLAIqMmgQ for ; Mon, 5 Aug 2019 07:48:39 -0700 (PDT) Received: from mail-oi1-x234.google.com (mail-oi1-x234.google.com [IPv6:2607:f8b0:4864:20::234]) (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 84AF7120242 for ; Mon, 5 Aug 2019 07:48:32 -0700 (PDT) Received: by mail-oi1-x234.google.com with SMTP id u15so62242077oiv.0 for ; Mon, 05 Aug 2019 07:48:32 -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=MBHpEwX50lzvDvtJzHuYq5PgV3T4TAybrcAEjpW+kfk=; b=E7AJW8ptGDHVeJxVLQWI8kgySyH9G65XjHS5hOnOqv9tViIy6/IXFVeRtE5Ovx/BOq wE4a1ZQSAQafPypyRLprL2hR+5fV4f2DY2JpSLbuRfifV4aANg16UVnNkr/F/g4kM1fM +AvsZLtRAC/AOZ1ulqzBhxV6gGAm6rpJ+OETg33rDlslpNWMleIXkeIMKpuNFOOFOSk5 ITTczwc3H6aVGO4o0XLDa4TJ4mpJJSrB03DzyKMnF7fmPKw6zZ6d3WhF1JcD2mHttVUM sry+1fVvMXHYf6Vt/S9FT6J1DxT0wY1h9IMu0LEoB8Vo0eSmxbcF7Yhrwo3JaQMeToME vl5A== 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=MBHpEwX50lzvDvtJzHuYq5PgV3T4TAybrcAEjpW+kfk=; b=IoxGFwjX6WGL+fvE4/5TSWwWROC8E0byBkc3Vkbwf3QKDwUIucuAegaaVttmjIis5W xWvqhFFc17mhZHdRF8nVOFpNsYNHT2Hxo2XPacwOM+LjCNVuHXoSIBniG68JykPD+aNV 3TVLlArAzx1Fz7I9tGUYuY2T3J4MqDi4XlZUaiDVxuI1GW87z1eJBCA7Rkm9pXeEq9kV khh6PFBwI5G7TwJlMIVY02PQfm4XCbdYXfGmJp7TU7RKItyQoSTuKfb9xbilgFEfipOe jXGui1aFN9ChhAGQKSVy+MvbA9TA+f6NfzcktaacqIXVbiLEhgQ6b/ARp1TZSzNmVNyz j9rA== X-Gm-Message-State: APjAAAUARpDI7LbSZPSlxQ3uSZ3/Ts9Ngqx94CRK7V77VuOujmzXisKk PrQHtovlNxoZRmOUNUJGrHzPdIMwCaWQ20Qeylk= X-Google-Smtp-Source: APXvYqy9f5VSr7ADcuDg0nwAhYo41PQ0pO1f65kMaKgR9dnLS7kD3PanCPGTktUEJG7HdVKYRwdqjrDKZpsiCjjEjfQ= X-Received: by 2002:aca:f40a:: with SMTP id s10mr10931124oih.51.1565016511577; Mon, 05 Aug 2019 07:48:31 -0700 (PDT) MIME-Version: 1.0 References: <155800082724.19580.16483563575859435866.idtracker@ietfa.amsl.com> <65737EA1-49AF-4EB9-AD1F-25157B3F010D@iii.ca> In-Reply-To: From: Richard Barnes Date: Mon, 5 Aug 2019 10:47:33 -0400 Message-ID: To: Magnus Westerlund Cc: "fluffy@iii.ca" , "iesg@ietf.org" , "perc-chairs@ietf.org" , "draft-ietf-perc-double@ietf.org" , "suhasietf@gmail.com" , "perc@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003d936f058f5fcd7b" 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, 05 Aug 2019 14:48:42 -0000 --0000000000003d936f058f5fcd7b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Magnus, Sorry, should have responded on Point 1. I think you're just mistaken on that point. Padding is included within the inner encryption. The double transform is an SRTP transform like any other; outside of the SRTP stack, there is no "inner" or "outer", just the same old protect and unprotect. So padding works the same as it does with any other SRTP transform. Was there some text in the document that gave you the impression that padding was not included under the inner encryption? The only mention of padding I see in the document is in the figure in Appendix A [1], where the padding is correctly shown to be within the inner encryption. Happy to clarify if you have some suggestions for how. --Richard [1] https://tools.ietf.org/html/draft-ietf-perc-double-11#appendix-A On Mon, Aug 5, 2019 at 2:32 AM Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > Sorry, I missed when this update was submitted, thanks for the reminder. > > The new version addresses most of my discuss, but missed to do anything > about point 1 below. > > Otherwise it appears to address my discuss points. How do you want to > resolve it? > > Cheers > > Magnus Westerlund > > > -----Original Message----- > > From: Cullen Jennings > > Sent: den 17 maj 2019 20:34 > > To: Magnus Westerlund > > Cc: The IESG ; perc-chairs@ietf.org; draft-ietf-perc- > > double@ietf.org; suhasietf@gmail.com; perc@ietf.org > > Subject: Re: [Perc] Magnus Westerlund's Discuss on > draft-ietf-perc-double- > > 10: (with DISCUSS and COMMENT) > > > > > > > > 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 leakag= e > > > 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. > > > > > > > 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 > > > > "* Payload: The RTP payload of the original packet=E2=80=9D > > > > to be > > > > "* Payload (including padding) The RTP payload (including passing) of t= he > > original packet=E2=80=9D > > > > > > > > > > --0000000000003d936f058f5fcd7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Magnus,

Sorry, should ha= ve responded on Point 1.=C2=A0 I think you're just mistaken on that poi= nt.=C2=A0 Padding is included within the inner encryption.=C2=A0 The double= transform is an SRTP transform like any other; outside of the SRTP stack, = there is no "inner" or "outer", just the same old prote= ct and unprotect.=C2=A0 So padding works the same as it does with any other= SRTP transform.

Was there some text in the docume= nt that gave you the impression that padding was not included under the inn= er encryption?=C2=A0 The only mention of padding I see in the document is i= n the figure in Appendix A [1], where the padding is correctly shown to be = within the inner encryption.=C2=A0 Happy to clarify if you have some sugges= tions for how.

--Richard

<= div>[1] https://tools.ietf.org/html/draft-ietf-perc-double-11#appendix-A<= /a>

On Mon, Aug 5, 2019 at 2:32 AM Magnus Westerlund <magnus.westerlund@ericsson.com> wrote= :
Hi,

Sorry, I missed when this update was submitted, thanks for the reminder.
The new version addresses most of my discuss, but missed to do anything abo= ut point 1 below.

Otherwise it appears to address my discuss points. How do you want to resol= ve it?

Cheers

Magnus Westerlund

> -----Original Message-----
> From: Cullen Jennings <fluffy@iii.ca>
> Sent: den 17 maj 2019 20:34
> To: Magnus Westerlund <magnus.westerlund@ericsson.com>
> Cc: The IESG <ie= sg@ietf.org>; perc-chairs@ietf.org; draft-ietf-perc-
> double@ietf.org; suhasietf@gmai= l.com; perc@ietf.org=
> Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc= -double-
> 10: (with DISCUSS and COMMENT)
>
> >
> > 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 pad= ding
> > is not included into the inner encrypted part. This prevents the<= br> > > application of RTP padding to prevent the potential privacy leaka= ge
> > that "Guidelines for the Use of Variable Bit Rate Audio with= Secure
> > RTP" (RFC 6562) documents. To prevent this type of informati= on leakage
> > and other privacy preserving operations based on applying RTP pad= ding
> > 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 i= s
> stripped from the=C2=A0 payload ?
>
> Perhaps to make it explicitly clear we should change
>
> "* Payload: The RTP payload of the original packet=E2=80=9D
>
> to be
>
> "* Payload (including padding) The RTP payload (including passing= ) of the
> original packet=E2=80=9D
>
>
>
>

--0000000000003d936f058f5fcd7b-- From nobody Fri Aug 16 07:45:02 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 C20E61201DE; Fri, 16 Aug 2019 07:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 H_QcG3LpENUd; Fri, 16 Aug 2019 07:44:56 -0700 (PDT) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 4BFDF1200A4; Fri, 16 Aug 2019 07:44:56 -0700 (PDT) Received: by mail-vs1-xe2a.google.com with SMTP id q188so3868118vsa.4; Fri, 16 Aug 2019 07:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wPUQjz3+NlNUKdYPnKe6V11eqC/RnO5RfbGvlM/GIsM=; b=S0Twk+2y33ptRRMabJ7613IvduZudMU8R5l09/yxD7TeSHsv1YFKP9Tfl5cnicMSX/ yquMmQYMgVHaDnnzvAMD/GVl7jf2P/YSaY5qKfjAExEtWVnKXMvf65OotL+ayVFyv7x5 EK6bPgkwRAsP4x3wfhz/sfmrDA37xM1zn7mAzZAl2WQ98vF16vGFExCqTbqqzlHsOHux vaj5gLXc61LeEFghLGdNwR0Iikl+8ZDamkG1qqAJZruFXKSnUHmcIJiqMtumiMU01r+l vRAw7eQh2hlhOwanzKLLIsvbs9f9EyL6gvFzrUKa0JfN4lh3UMmv30nMgIWDsq9zSQHC 1PrA== 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=wPUQjz3+NlNUKdYPnKe6V11eqC/RnO5RfbGvlM/GIsM=; b=d20WU6XKBit4H9uwuPZcEbYkjnMAQRGQSYekTylCGy45PZfpNqGUl7Q1QR4gLEXPgr A63Won36cl3NpQOqv4XC96qKzXEU7gAiGQb0ckSm/kibaoOkiMy/ssq0jFOIr0pEGA2p ie/ks7iidbHfd7NYmRyYd/AJVL3uS/FKB0rKAZnjMp+Rf877o0FxJ7AQgtxdK4MmlKUz cA7xXb+/qqLJqTpdzgtEFKDZHE5sZAM/hn6Cjnbn1AUS8jPZnbhVdga9A9wCrGASSdlh r+EqFrsalCGVtKsaBaJllEpZuWJyroWLkApncEJ/XkJOFxX4ZKTwYRiB5KuQIQ4+i+IU hSYw== X-Gm-Message-State: APjAAAX7FQs0v6buo2cMzZz14j6URoGpuqMFt/C0BJzDG8/1suyrHrf/ Gd8Wo6mEtGyKUuhs4I7SmGvlcqBmJLhftP3y3/Q= X-Google-Smtp-Source: APXvYqzEVbBLjD/0knbryh+wKD+yEkt04GPVKsD8YOKPRNzFwo7kzhFYdTyb4D9tqX9Qap2qppyIMXeFTTrx8IUWYiM= X-Received: by 2002:a67:ea44:: with SMTP id r4mr6407210vso.86.1565966695311; Fri, 16 Aug 2019 07:44:55 -0700 (PDT) MIME-Version: 1.0 References: <156339433620.25783.14611652111059201524.idtracker@ietfa.amsl.com> In-Reply-To: From: Suhas Nandakumar Date: Fri, 16 Aug 2019 07:44:42 -0700 Message-ID: To: Richard Barnes Cc: Benjamin Kaduk , The IESG , perc-chairs@ietf.org, perc@ietf.org, draft-ietf-perc-srtp-ekt-diet@ietf.org Content-Type: multipart/alternative; boundary="0000000000009aaf7305903d0818" Archived-At: Subject: Re: [Perc] Benjamin Kaduk's Discuss on draft-ietf-perc-srtp-ekt-diet-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, 16 Aug 2019 14:45:01 -0000 --0000000000009aaf7305903d0818 Content-Type: text/plain; charset="UTF-8" Hi Benjamin Curious to see if Richard's responses addresses your feedback. Thanks Suhas On Fri, Aug 2, 2019 at 11:48 AM Richard Barnes wrote: > On Wed, Jul 17, 2019 at 3:12 PM Benjamin Kaduk via Datatracker < > noreply@ietf.org> wrote: > >> Benjamin Kaduk has entered the following ballot position for >> draft-ietf-perc-srtp-ekt-diet-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-srtp-ekt-diet/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Thanks for the updates in the -10; we're making progress. I think there >> are still some issues left to resolve, though. >> >> My previous position had: >> >> """I think we need to discuss whether the mechanism described in Section >> 4.1 >> contains an EKT-specific extension mechanism or is in fact a more general >> mechanism for including extensions in SRTP packets outside the SRTP >> cryptographic protection. (If so, we would probably need to Update 3711 >> to >> indicate as much, and perhaps allow for multiple extension types to be >> present adjacently.) In particular, how would this EKT extension interact >> with any other future mechanism that needs to add data to SRTP packets >> outside the SRTP cryptographic wrapper?""" >> >> I think I remember having such a discussion, but cannot find any record of >> it. Does anyone have a pointer handy (or a corrective to my memory)? >> > > We may have had one in person, but I'm not seeing one in my email history > either. The short answer is that I don't think any generalization is > needed. > > The longer version is: RTP and SRTP packet formats are not intended to > self-describing. Instead, they rely heavily on external negotiation to > tell the endpoint how to parse the packet. For example, there is no > standard format for the RTP extension field; the format of the field (and > even the identifiers for individual extensions used therein) are negotiated > in SDP. > > In this context, that means that it's up to the application to make good > decisions about which extensions apply. Note that EKT is already > incompatible with the SRTP MKI mechanism (as noted in the document), as an > example of the types of incompatibilities that application need to navigate. > > > >> Similarly, I don't remember any discussion on: >> >> """I also think we need to discuss whether it is appropriate to set a >> precedent that any standards-track protocol can get a dedicated TLS >> HandshakeType (noting that this is a potentially scarce one-octet field. >> Would it be more appropriate to define a generic "key transport" container >> that can be generally applicable to many protocols, and have an internal >> extension point that allows for an SRTP+EKT-specific usage within the TLS >> HandshakeType?""" >> >> We are also still waiting on IANA, if I understand correctly. I do not >> see >> any indication that the needed expert review for TLS ExtensionType >> allocation has been requested (the authors should initiate this, per RFC >> 8447), and there may have been other matters that needed clarification. >> > > On the HandshakeType: The authors had a fairly extensive (but > unfortunately off-list) discussion with EKR about how to transmit the EKT > key. After evaluating the full range of options -- from > EncryptedExtensions all the way to the application layer -- the conclusion > of that discussion was that a HandshakeType fit best with the requirements > here. I'm not sure I understand your worry about the scarcity of > HandshakeType values. "Any standards-track protocol" is basically the > highest bar we have; what more would you ask? Practically speaking, we are > defining new HandshakeType values at a high enough rate that we seem likely > to exhaust the pool. > > On the ExtensionType: Thanks for calling that out; I have sent a request > to the mailing list. Is there a reason that IANA doesn't send those > emails, like they do with other approvals from designated experts? > > --Richard > > > >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> [original comment section unchanged; contents likely stale] >> >> There is no cryptographic binding between the EKTCiphertext and the main >> SRTP packet, nor is there an authentication tag on the EKTCiphertext that >> protects the SPI or length fields (or, for that matter, the message type). >> The consequences of this are probably minor, given that an attacker who >> can >> tamper with them could also tamper with the main plaintext, but there is >> perhaps potential for causing trouble later in the pipeline, especially >> since (as this document admits) there is the possibility of SRTP >> transforms >> that do not provide integrity protection. >> >> The EKT is a group shared symmetric key, with all the usual caveats that >> any group member can spoof a message "from" any other group member. >> (Reading the group's messages is of course a necessary feature.) >> The EKT is furthermore possessed by the central broker in the portrayed >> deployment scenario, allowing the broker access to the plaintext of media >> if it did not already have such access. >> >> It's probably worth mentioning somewhere what the master salt is used for >> so the reader not familiar with the details of RFC 3711 is not left >> wondering why we are conveying it. >> >> Section 1 >> >> This document defines Encrypted Key Transport (EKT) for SRTP and >> reduces the amount of external signaling control that is needed in a >> SRTP session with multiple receivers. EKT securely distributes the >> SRTP master key and other information for each SRTP source. With >> this method, SRTP entities are free to choose SSRC values as they see >> fit, and to start up new SRTP sources with new SRTP master keys >> within a session without coordinating with other entities via >> external signaling or other external means. >> >> I think you need an explanation and/or reference for previous systems that >> required central SSRC allocation (or otherwise why the "free to choose" is >> noteworthy here). >> >> EKT provides a way for an SRTP session participant, to securely >> transport its SRTP master key and current SRTP rollover counter to >> the other participants in the session. [...] >> >> nit: spurious comma. >> >> This reduces the amount of CPU time >> needed for encryption and can be used for some optimization to media >> sending that use source specific multicast. >> >> nit: I think there's a singular/plural mismatch here. >> >> Section 4 >> >> EKT MUST NOT be used in conjunction with SRTP's MKI (Master Key >> Identifier) or with SRTP's [RFC3711], as those SRTP >> features duplicate some of the functions of EKT. Senders MUST NOT >> include MKI when using EKT. Receivers SHOULD simply ignore any MKI >> field received if EKT is in use. >> >> It feels like we're specifically emphasizing the prohibition on EKT with >> MKI, and only saying once that EKT with is prohibited. Is >> there >> a reason to have a stronger prohibition of the one than the other? >> >> Section 4.1 >> >> The EKTField uses the format defined in Figure 1 for the FullEKTField >> and ShortEKTField. >> >> nit: the ShortEKTField is in Figure 2. >> >> SRTPMasterKeyLength = BYTE >> SRTPMasterKey = 1*256BYTE >> SSRC = 4BYTE; SSRC from RTP >> ROC = 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC >> >> nit: is it conventional to all-caps "FOR THE GIVEN"? >> >> EKTCiphertext: The data that is output from the EKT encryption >> operation, described in Section 4.4. This field is included in SRTP >> packets when EKT is in use. The length of EKTCiphertext can be >> larger than the length of the EKTPlaintext that was encrypted. >> >> Doesn't it *need* to be larger in order to provide the stated properties? >> (I.e., it "will be larger".) >> >> SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes. This >> depends on the cipher suite negotiated for SRTP using SDP Offer/ >> Answer [RFC3264] for the SRTP. >> >> This text would seem to forbid using EKT with any mechanism other than SDP >> Offer/Answer for central control. >> >> Do we want to say why a Message Type of 1 is not usable? >> >> Section 4.2.2 >> >> [Isn't there a step 0 to figure out whether any EKT/extensions are in >> use?] >> >> 5. If the SSRC in the EKTPlaintext does not match the SSRC of the >> SRTP packet received, then all the information from this >> EKTPlaintext MUST be discarded and the following steps in this >> list are skipped. >> >> Does this mean I just ignore EKT and attempt to process the SRTP packet >> with whatever non-EKT material I have on hand? >> >> * Unless the transform specifies other acceptable key lengths, >> the length of the SRTP Master Key MUST be the same as the >> >> This is the first usage of "transform" in this document; perhaps a >> reminder >> to the reader that this is a stock SRTP concept is in order. >> >> master key length for the SRTP transform in use. If this is >> not the case, then the receiver MUST abort EKT processing and >> SHOULD discared the whole UDP packet. >> >> nit: The "this" in "if this is not the case" should probably be spelled >> out >> more clearly, as it seems to require both that the master key length is >> different from the master key length for the SRTP transform in use and >> that >> the transform specifies other acceptable key lengths. (Presumably the >> master key still needs to match one of those other acceptable key lengths, >> though?) >> >> * If the length of the SRTP Master Key is less than the master >> key length for the SRTP transform in use, and the transform >> specifies that this length is acceptable, then the SRTP Master >> Key value is used to replace the first bytes in the existing >> master key. [...] >> >> Do we need to be more clear about what the "existing master key" is? (Are >> there reordering issues where we could operate on a different key than >> intended?) Also, what do I do if the length of the SRTP master key is >> larger than the master key length for the transform in use? >> >> Section 4.3 >> >> Section 4.2.1 recommends that SRTP senders continue using an old key >> for some time after sending a new key in an EKT tag. Receivers that >> wish to avoid packet loss due to decryption failures MAY perform >> trial decryption with both the old key and the new key, keeping the >> result of whichever decryption succeeds. Note that this approach is >> >> We have multiple types of key floating around; please be clear about which >> ones are which. >> >> only compatible with SRTP transforms that include integrity >> protection. >> >> What's the guidance for when that's not the case? >> >> 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 ). If >> >> Since we knowingly create EKTCiphertexts that are identical, do we count >> those as a single encryption or do we count each time we send them? >> (I guess Section 4.4 mostly answers this by way of example but a >> non-example statement is probably in order.) >> >> At this point implementation need to either use the >> call signaling to renegotiate a new session or need to terminate the >> >> nit: "call signaling" seems more SIP-specific than necessary. >> >> The encryption function returns a ciphertext value C whose length is >> N bytes, where N may be larger than M. [...] >> >> (same comment about "may be larger" as above) >> >> Section 4.4.2 >> >> An EKTCipher determines how the EKTCiphertext field is written, and >> how it is processed when it is read. This field is opaque to the >> other aspects of EKT processing. EKT ciphers are free to use this >> field in any way, but they SHOULD NOT use other EKT or SRTP fields as >> an input. [...] >> >> Why is this SHOULD NOT instead of MUST NOT? >> >> Section 4.5 >> >> Is it worth mentioning (or internally referencing) the 250ms delay before >> using the new key? >> >> Section 5.2.1 >> >> Given that you're using the DTLS 1.3 handshake structure, why is RFC 5246 >> the syntax reference? >> >> Section 5.2.2 >> >> If the server did not provide a supported_ekt_ciphers extension in >> its ServerHello, then EKTKey messages MUST NOT be sent by the client >> or the server. >> >> The general text and Figure 4 only show EKTKey being sent by the server. >> Is it ever allowed to be sent by the client? >> >> When an EKTKey is received and processed successfully, the recipient >> MUST respond with an Ack handshake message as described in Section 7 >> of [I-D.ietf-tls-dtls13]. The EKTKey message and Ack MUST be >> retransmitted following the rules in Section 4.2.4 of [RFC6347]. >> >> It is super-weird to cite draft-ietf-tls-dtls13 and RFC 6347 in adjacent >> sentences. >> >> Section 6 >> >> With EKT, each SRTP sender and receiver MUST generate distinct SRTP >> master keys. [...] >> >> Er, isn't this just senders? >> >> Note that the inputs of EKT are the same as for SRTP with key- >> >> "inputs" in terms of shared cryptographic material that is fed into the >> SRTP (plus EKT) protocol collection? >> >> sharing: a single key is provided to protect an entire SRTP session. >> However, EKT remains secure even when SSRC values collide. >> >> I think you need to say more about what "secure" is supposed to mean, >> here. >> >> The presence of the SSRC in the EKTPlaintext ensures that an attacker >> cannot substitute an EKTCiphertext from one SRTP stream into another >> SRTP stream. >> >> Depends on the attacker; if one of the call participants has the network >> positioning to do so, their knowledge of the EKT allows for generating an >> EKTCiphertext that matches the SSRC of an arbitrary message. (I guess >> technically that involves modifying and not straight substitution of the >> EKTCiphertext.) >> >> 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. >> >> I think this last sentence went a bit funky; presumably it's "any attacker >> that can modify the packets in transit can already cause the SRTP >> integrity >> check to fail even in the absence of EKT". >> >> An attacker could send packets containing a FullEKTField, in an >> attempt to consume additional CPU resources of the receiving system >> by causing the receiving system to decrypt the EKT ciphertext and >> detect an authentication failure. In some cases, caching the >> previous values of the Ciphertext as described in Section 4.3 helps >> mitigate this issue. >> >> I'm not really sure what cases those are supposed to be, since an attacker >> can send arbitrary junk and tweak it by a bit each time, and the recipient >> has to do the full decryption to validate the integrity IV. >> >> In a similar vein, EKT has no replay protection, so an attacker could >> implant improper keys in receivers by capturing EKTCiphertext values >> encrypted with a given EKTKey and replaying them in a different >> context, e.g., from a different sender. When the underlying SRTP >> >> Wouldn't the SSRC check block this particular replay? >> >> transform provides integrity protection, this attack will just result >> in packet loss. If it does not, then it will result in random data >> being fed to RTP payload processing. An attacker that is in a >> position to mount these attacks, however, could achieve the same >> effects more easily without attacking EKT. >> >> maybe add "by directly modifying the SRTP packet contents"? >> >> The confidentiality, integrity, and authentication of the EKT cipher >> MUST be at least as strong as the SRTP cipher and at least as strong >> as the DTLS-SRTP ciphers. >> >> EKT doesn't carry anything that's an input to DTLS, so shouldn't this >> restriction be that the DTLS cipher must be as stront as the EKT one? >> >> Section 7.1 >> >> All new EKT messages MUST be defined to have a length as second from >> the last element. >> >> "16-bit", right? >> >> section 7.4 >> >> IANA is requested to add ekt_key as a new entry in the "TLS >> HandshakeType Registry" table of the "Transport Layer Security (TLS) >> Parameters" registry with a reference to this specification, a DTLS- >> OK value of "Y", and allocate a value of TBD to for this content >> type. >> >> HandshakeType != content type >> >> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >> > --0000000000009aaf7305903d0818 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Benjamin

=C2=A0 Curious to see if Ri= chard's responses addresses your feedback.=C2=A0

Thanks
Suhas

On Fri, Aug 2, 2019 at 11:48 AM Richard Barn= es <rlb@ipv.sx> wrote:
On Wed, Jul 17, 2019 at 3:12= PM Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
Benjamin Kaduk= has entered the following ballot position for
draft-ietf-perc-srtp-ekt-diet-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/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:
----------------------------------------------------------------------

Thanks for the updates in the -10; we're=C2=A0 making progress.=C2=A0 I= think there
are still some issues left to resolve, though.

My previous position had:

"""I think we need to discuss whether the mechanism describe= d in Section 4.1
contains an EKT-specific extension mechanism or is in fact a more general mechanism for including extensions in SRTP packets outside the SRTP
cryptographic protection.=C2=A0 (If so, we would probably need to Update 37= 11 to
indicate as much, and perhaps allow for multiple extension types to be
present adjacently.)=C2=A0 In particular, how would this EKT extension inte= ract
with any other future mechanism that needs to add data to SRTP=C2=A0 packet= s
outside the SRTP cryptographic wrapper?"""

I think I remember having such a discussion, but cannot find any record of<= br> it.=C2=A0 Does anyone have a pointer handy (or a corrective to my memory)?<= br>

We may have had one in person, but I= 9;m not seeing one in my email history either.=C2=A0 The short answer is th= at I don't think any generalization is needed.

=
The longer version is: RTP and SRTP packet formats are not intended to= self-describing.=C2=A0 Instead, they rely heavily on external negotiation = to tell the endpoint how to parse the packet.=C2=A0 For example, there is n= o standard format for the RTP extension field; the format of the field (and= even the identifiers for individual extensions used therein) are negotiate= d in SDP.

In this context, that means that it'= s up to the application to make good decisions about which extensions apply= .=C2=A0 Note that EKT is already incompatible with the SRTP MKI mechanism (= as noted in the document), as an example of the types of incompatibilities = that application need to navigate.

=C2=A0
Similarly, I don't remember any discussion on:

"""I also think we need to discuss whether it is appropriate= to set a
precedent that any standards-track protocol can get a dedicated TLS
HandshakeType (noting that this is a potentially scarce one-octet field. Would it be more appropriate to define a generic "key transport" = container
that can be generally applicable to many protocols, and have an internal extension point that allows for an SRTP+EKT-specific usage within the TLS HandshakeType?"""

We are also still waiting on IANA, if I understand correctly.=C2=A0 I do no= t see
any indication that the needed expert review for TLS ExtensionType
allocation has been requested (the authors should initiate this, per RFC 8447), and there may have been other matters that needed clarification.
=

On the HandshakeType: The authors had a fa= irly extensive (but unfortunately off-list) discussion with EKR about how t= o transmit the EKT key.=C2=A0 After evaluating the full range of options --= from EncryptedExtensions all the way to the application layer -- the concl= usion of that discussion was that a HandshakeType fit best with the require= ments here.=C2=A0 I'm not sure I understand your worry about the scarci= ty of HandshakeType values. "Any standards-track protocol" is bas= ically the highest bar we have; what more would you ask?=C2=A0 Practically = speaking, we are defining new HandshakeType values at a high enough rate th= at we seem likely to exhaust the pool.

On the = ExtensionType: Thanks for calling that out; I have sent a request to the ma= iling list.=C2=A0 Is there a reason that IANA doesn't send those emails= , like they do with other approvals from designated experts?

=
--Richard

=C2=A0


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

[original comment section unchanged; contents likely stale]

There is no cryptographic binding between the EKTCiphertext and the main SRTP packet, nor is there an authentication tag on the EKTCiphertext that protects the SPI or length fields (or, for that matter, the message type).<= br> The consequences of this are probably minor, given that an attacker who can=
tamper with them could also tamper with the main plaintext, but there is perhaps potential for causing trouble later in the pipeline, especially
since (as this document admits) there is the possibility of SRTP transforms=
that do not provide integrity protection.

The EKT is a group shared symmetric key, with all the usual caveats that any group member can spoof a message "from" any other group membe= r.
(Reading the group's messages is of course a necessary feature.)
The EKT is furthermore possessed by the central broker in the portrayed
deployment scenario, allowing the broker access to the plaintext of media if it did not already have such access.

It's probably worth mentioning somewhere what the master salt is used f= or
so the reader not familiar with the details of RFC 3711 is not left
wondering why we are conveying it.

Section 1

=C2=A0 =C2=A0This document defines Encrypted Key Transport (EKT) for SRTP a= nd
=C2=A0 =C2=A0reduces the amount of external signaling control that is neede= d in a
=C2=A0 =C2=A0SRTP session with multiple receivers.=C2=A0 EKT securely distr= ibutes the
=C2=A0 =C2=A0SRTP master key and other information for each SRTP source.=C2= =A0 With
=C2=A0 =C2=A0this method, SRTP entities are free to choose SSRC values as t= hey see
=C2=A0 =C2=A0fit, and to start up new SRTP sources with new SRTP master key= s
=C2=A0 =C2=A0within a session without coordinating with other entities via<= br> =C2=A0 =C2=A0external signaling or other external means.

I think you need an explanation and/or reference for previous systems that<= br> required central SSRC allocation (or otherwise why the "free to choose= " is
noteworthy here).

=C2=A0 =C2=A0EKT provides a way for an SRTP session participant, to securel= y
=C2=A0 =C2=A0transport its SRTP master key and current SRTP rollover counte= r to
=C2=A0 =C2=A0the other participants in the session.=C2=A0 [...]

nit: spurious comma.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This reduces the amount of CP= U time
=C2=A0 =C2=A0needed for encryption and can be used for some optimization to= media
=C2=A0 =C2=A0sending that use source specific multicast.

nit: I think there's a singular/plural mismatch here.

Section 4

=C2=A0 =C2=A0EKT MUST NOT be used in conjunction with SRTP's MKI (Maste= r Key
=C2=A0 =C2=A0Identifier) or with SRTP's <From, To> [RFC3711], as = those SRTP
=C2=A0 =C2=A0features duplicate some of the functions of EKT.=C2=A0 Senders= MUST NOT
=C2=A0 =C2=A0include MKI when using EKT.=C2=A0 Receivers SHOULD simply igno= re any MKI
=C2=A0 =C2=A0field received if EKT is in use.

It feels like we're specifically emphasizing the prohibition on EKT wit= h
MKI, and only saying once that EKT with <From, To> is prohibited.=C2= =A0 Is there
a reason to have a stronger prohibition of the one than the other?

Section 4.1

=C2=A0 =C2=A0The EKTField uses the format defined in Figure 1 for the FullE= KTField
=C2=A0 =C2=A0and ShortEKTField.

nit: the ShortEKTField is in Figure 2.

=C2=A0 =C2=A0 SRTPMasterKeyLength =3D BYTE
=C2=A0 =C2=A0 SRTPMasterKey =3D 1*256BYTE
=C2=A0 =C2=A0 SSRC =3D 4BYTE; SSRC from RTP
=C2=A0 =C2=A0 ROC =3D 4BYTE ; ROC from SRTP FOR THE GIVEN SSRC

nit: is it conventional to all-caps "FOR THE GIVEN"?

=C2=A0 =C2=A0EKTCiphertext: The data that is output from the EKT encryption=
=C2=A0 =C2=A0operation, described in Section 4.4.=C2=A0 This field is inclu= ded in SRTP
=C2=A0 =C2=A0packets when EKT is in use.=C2=A0 The length of EKTCiphertext = can be
=C2=A0 =C2=A0larger than the length of the EKTPlaintext that was encrypted.=

Doesn't it *need* to be larger in order to provide the stated propertie= s?
(I.e., it "will be larger".)

=C2=A0 =C2=A0SRTPMasterKeyLength: The length of the SRTPMasterKey in bytes.= =C2=A0 This
=C2=A0 =C2=A0depends on the cipher suite negotiated for SRTP using SDP Offe= r/
=C2=A0 =C2=A0Answer [RFC3264] for the SRTP.

This text would seem to forbid using EKT with any mechanism other than SDP<= br> Offer/Answer for central control.

Do we want to say why a Message Type of 1 is not usable?

Section 4.2.2

[Isn't there a step 0 to figure out whether any EKT/extensions are in u= se?]

=C2=A0 =C2=A05.=C2=A0 If the SSRC in the EKTPlaintext does not match the SS= RC of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0SRTP packet received, then all the information f= rom this
=C2=A0 =C2=A0 =C2=A0 =C2=A0EKTPlaintext MUST be discarded and the following= steps in this
=C2=A0 =C2=A0 =C2=A0 =C2=A0list are skipped.

Does this mean I just ignore EKT and attempt to process the SRTP packet
with whatever non-EKT material I have on hand?

=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 Unless the transform specifies other acc= eptable key lengths,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the length of the SRTP Master Key MUST b= e the same as the

This is the first usage of "transform" in this document; perhaps = a reminder
to the reader that this is a stock SRTP concept is in order.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 master key length for the SRTP transform= in use.=C2=A0 If this is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 not the case, then the receiver MUST abo= rt EKT processing and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SHOULD discared the whole UDP packet.
nit: The "this" in "if this is not the case" should pro= bably be spelled out
more clearly, as it seems to require both that the master key length is
different from the master key length for the SRTP transform in use and that=
the transform specifies other acceptable key lengths.=C2=A0 (Presumably the=
master key still needs to match one of those other acceptable key lengths,<= br> though?)

=C2=A0 =C2=A0 =C2=A0 =C2=A0*=C2=A0 If the length of the SRTP Master Key is = less than the master
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 key length for the SRTP transform in use= , and the transform
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 specifies that this length is acceptable= , then the SRTP Master
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Key value is used to replace the first b= ytes in the existing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 master key.=C2=A0 [...]

Do we need to be more clear about what the "existing master key" = is?=C2=A0 (Are
there reordering issues where we could operate on a different key than
intended?)=C2=A0 Also, what do I do if the length of the SRTP master key is=
larger than the master key length for the transform in use?

Section 4.3

=C2=A0 =C2=A0Section 4.2.1 recommends that SRTP senders continue using an o= ld key
=C2=A0 =C2=A0for some time after sending a new key in an EKT tag.=C2=A0 Rec= eivers that
=C2=A0 =C2=A0wish to avoid packet loss due to decryption failures MAY perfo= rm
=C2=A0 =C2=A0trial decryption with both the old key and the new key, keepin= g the
=C2=A0 =C2=A0result of whichever decryption succeeds.=C2=A0 Note that this = approach is

We have multiple types of key floating around; please be clear about which<= br> ones are which.

=C2=A0 =C2=A0only compatible with SRTP transforms that include integrity =C2=A0 =C2=A0protection.

What's the guidance for when that's not the case?

=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 ).= =C2=A0 If

Since we knowingly create EKTCiphertexts that are identical, do we count those as a single encryption or do we count each time we send them?
(I guess Section 4.4 mostly answers this by way of example but a
non-example statement is probably in order.)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 At th= is point implementation need to either use the
=C2=A0 =C2=A0call signaling to renegotiate a new session or need to termina= te the

nit: "call signaling" seems more SIP-specific than necessary.

=C2=A0 =C2=A0The encryption function returns a ciphertext value C whose len= gth is
=C2=A0 =C2=A0N bytes, where N may be larger than M.=C2=A0 [...]

(same comment about "may be larger" as above)

Section 4.4.2

=C2=A0 =C2=A0An EKTCipher determines how the EKTCiphertext field is written= , and
=C2=A0 =C2=A0how it is processed when it is read.=C2=A0 This field is opaqu= e to the
=C2=A0 =C2=A0other aspects of EKT processing.=C2=A0 EKT ciphers are free to= use this
=C2=A0 =C2=A0field in any way, but they SHOULD NOT use other EKT or SRTP fi= elds as
=C2=A0 =C2=A0an input.=C2=A0 [...]

Why is this SHOULD NOT instead of MUST NOT?

Section 4.5

Is it worth mentioning (or internally referencing) the 250ms delay before using the new key?

Section 5.2.1

Given that you're using the DTLS 1.3 handshake structure, why is RFC 52= 46
the syntax reference?

Section 5.2.2

=C2=A0 =C2=A0If the server did not provide a supported_ekt_ciphers extensio= n in
=C2=A0 =C2=A0its ServerHello, then EKTKey messages MUST NOT be sent by the = client
=C2=A0 =C2=A0or the server.

The general text and Figure 4 only show EKTKey being sent by the server. Is it ever allowed to be sent by the client?

=C2=A0 =C2=A0When an EKTKey is received and processed successfully, the rec= ipient
=C2=A0 =C2=A0MUST respond with an Ack handshake message as described in Sec= tion 7
=C2=A0 =C2=A0of [I-D.ietf-tls-dtls13].=C2=A0 The EKTKey message and Ack MUS= T be
=C2=A0 =C2=A0retransmitted following the rules in Section 4.2.4 of [RFC6347= ].

It is super-weird to cite draft-ietf-tls-dtls13 and RFC 6347 in adjacent sentences.

Section 6

=C2=A0 =C2=A0With EKT, each SRTP sender and receiver MUST generate distinct= SRTP
=C2=A0 =C2=A0master keys.=C2=A0 [...]

Er, isn't this just senders?

=C2=A0 =C2=A0Note that the inputs of EKT are the same as for SRTP with key-=

"inputs" in terms of shared cryptographic material that is fed in= to the
SRTP (plus EKT) protocol collection?

=C2=A0 =C2=A0sharing: a single key is provided to protect an entire SRTP se= ssion.
=C2=A0 =C2=A0However, EKT remains secure even when SSRC values collide.

I think you need to say more about what "secure" is supposed to m= ean, here.

=C2=A0 =C2=A0The presence of the SSRC in the EKTPlaintext ensures that an a= ttacker
=C2=A0 =C2=A0cannot substitute an EKTCiphertext from one SRTP stream into a= nother
=C2=A0 =C2=A0SRTP stream.

Depends on the attacker; if one of the call participants has the network positioning to do so, their knowledge of the EKT allows for generating an EKTCiphertext that matches the SSRC of an arbitrary message.=C2=A0 (I guess=
technically that involves modifying and not straight substitution of the EKTCiphertext.)

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

I think this last sentence went a bit funky; presumably it's "any = attacker
that can modify the packets in transit can already cause the SRTP integrity=
check to fail even in the absence of EKT".

=C2=A0 =C2=A0An attacker could send packets containing a FullEKTField, in a= n
=C2=A0 =C2=A0attempt to consume additional CPU resources of the receiving s= ystem
=C2=A0 =C2=A0by causing the receiving system to decrypt the EKT ciphertext = and
=C2=A0 =C2=A0detect an authentication failure.=C2=A0 In some cases, caching= the
=C2=A0 =C2=A0previous values of the Ciphertext as described in Section 4.3 = helps
=C2=A0 =C2=A0mitigate this issue.

I'm not really sure what cases those are supposed to be, since an attac= ker
can send arbitrary junk and tweak it by a bit each time, and the recipient<= br> has to do the full decryption to validate the integrity IV.

=C2=A0 =C2=A0In a similar vein, EKT has no replay protection, so an attacke= r could
=C2=A0 =C2=A0implant improper keys in receivers by capturing EKTCiphertext = values
=C2=A0 =C2=A0encrypted with a given EKTKey and replaying them in a differen= t
=C2=A0 =C2=A0context, e.g., from a different sender.=C2=A0 When the underly= ing SRTP

Wouldn't the SSRC check block this particular replay?

=C2=A0 =C2=A0transform provides integrity protection, this attack will just= result
=C2=A0 =C2=A0in packet loss.=C2=A0 If it does not, then it will result in r= andom data
=C2=A0 =C2=A0being fed to RTP payload processing.=C2=A0 An attacker that is= in a
=C2=A0 =C2=A0position to mount these attacks, however, could achieve the sa= me
=C2=A0 =C2=A0effects more easily without attacking EKT.

maybe add "by directly modifying the SRTP packet contents"?

=C2=A0 =C2=A0The confidentiality, integrity, and authentication of the EKT = cipher
=C2=A0 =C2=A0MUST be at least as strong as the SRTP cipher and at least as = strong
=C2=A0 =C2=A0as the DTLS-SRTP ciphers.

EKT doesn't carry anything that's an input to DTLS, so shouldn'= t this
restriction be that the DTLS cipher must be as stront as the EKT one?

Section 7.1

=C2=A0 =C2=A0All new EKT messages MUST be defined to have a length as secon= d from
=C2=A0 =C2=A0the last element.

"16-bit", right?

section 7.4

=C2=A0 =C2=A0IANA is requested to add ekt_key as a new entry in the "T= LS
=C2=A0 =C2=A0HandshakeType Registry" table of the "Transport Laye= r Security (TLS)
=C2=A0 =C2=A0Parameters" registry with a reference to this specificati= on, a DTLS-
=C2=A0 =C2=A0OK value of "Y", and allocate a value of TBD to for = this content
=C2=A0 =C2=A0type.

HandshakeType !=3D content type


_______________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc
--0000000000009aaf7305903d0818-- From nobody Fri Aug 16 07:46:34 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 CA5F5120288; Fri, 16 Aug 2019 07:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 IP_BXQYv6yCd; Fri, 16 Aug 2019 07:46:23 -0700 (PDT) Received: from mail-vk1-xa34.google.com (mail-vk1-xa34.google.com [IPv6:2607:f8b0:4864:20::a34]) (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 0DD3B1201DE; Fri, 16 Aug 2019 07:46:23 -0700 (PDT) Received: by mail-vk1-xa34.google.com with SMTP id b184so1125839vkh.2; Fri, 16 Aug 2019 07:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d2z1HNbDjta8rsIMW/tCBn8YxV3pqiwfO3UfoYr0fI4=; b=JrluIUADJdwz6h2a6LP5jXJ34F5kXJg5w5dhBQA95ktBKNcbw0MCz2kH5zCsLKAZ/P q8Mbqo85PlbVwIySWiy588SqefZkep5+6qABG0ib69ycUR25if8MUJnEkA6XLellsehr zUa8GsJq+bs4RLiVq8WauhrXx5+lmdN7J9+T7lMQUUcFqK8DGcEEmv/TPf6DxKochs6g 5qjent2mRx5KwPUFEDbshZQ3TzgZr+QN30KGTB24YcU1Xt8mkKc/9fRodNhzD17TCYEF 3QRQHab9t61e3uUJ1dWxf2K2agOTQoZt0mz+4PJjBW5f2hfLZK3pIO4hU45dUpYSXSBA 1P5Q== 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=d2z1HNbDjta8rsIMW/tCBn8YxV3pqiwfO3UfoYr0fI4=; b=PbPXzfYvM0D8nRBenB5x6BYVsnX25brj++xs2apgIYiCWNh4crN3IZAdAooWqjy0zP dCmXXZXEHcaWDGT24YjYn3KKLSaGtg/QmPKckFo65hS/qQZmpndrtWR4+nPi/8ox4qQS 9N4X4C6OASmwTrVUo5lZ97mojMN7uPJPVzjPFvzQf02hjWJeWE6Fwq64P7fj6IYa7K6d d2VBsQwVnN/5C3vO1xsY2+8T8llLPW8gjQuy5IM05rSqYcVP8m4NueNedsSrPlup6Q8w VBd8aDs2jh4hQXvE0JA/4ASlM1ZKxmTTLH3xlJxkzwX9TeQPiHlxRspuOi30zzaUURNe t/ig== X-Gm-Message-State: APjAAAWJ4IsfmSzwmRfraw8MXgspCKSoGtli+dYU41cfU/Uv3QwS9rZi qSNwF0FtTL6BTpr5Yrk8JoX8ByjLWVg4mhXZNsFWKg== X-Google-Smtp-Source: APXvYqw4W9BJRU4iDzAcpwj+hHvRfyefas73f5TBnTq8nXemAOwNQxaYbg5cZUuM8vsrOWEbCGqE7p9QHJaw1sqkvYk= X-Received: by 2002:a1f:cac3:: with SMTP id a186mr4157776vkg.50.1565966782072; Fri, 16 Aug 2019 07:46:22 -0700 (PDT) MIME-Version: 1.0 References: <155800082724.19580.16483563575859435866.idtracker@ietfa.amsl.com> <65737EA1-49AF-4EB9-AD1F-25157B3F010D@iii.ca> In-Reply-To: From: Suhas Nandakumar Date: Fri, 16 Aug 2019 07:46:08 -0700 Message-ID: To: Richard Barnes Cc: Magnus Westerlund , "fluffy@iii.ca" , "iesg@ietf.org" , "perc-chairs@ietf.org" , "draft-ietf-perc-double@ietf.org" , "perc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c68b9405903d0d90" 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, 16 Aug 2019 14:46:26 -0000 --000000000000c68b9405903d0d90 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Magnus Wondering if Richard's response answers your question? Thanks Suhas On Mon, Aug 5, 2019 at 7:48 AM Richard Barnes wrote: > Hey Magnus, > > Sorry, should have responded on Point 1. I think you're just mistaken on > that point. Padding is included within the inner encryption. The double > transform is an SRTP transform like any other; outside of the SRTP stack, > there is no "inner" or "outer", just the same old protect and unprotect. > So padding works the same as it does with any other SRTP transform. > > Was there some text in the document that gave you the impression that > padding was not included under the inner encryption? The only mention of > padding I see in the document is in the figure in Appendix A [1], where t= he > padding is correctly shown to be within the inner encryption. Happy to > clarify if you have some suggestions for how. > > --Richard > > [1] https://tools.ietf.org/html/draft-ietf-perc-double-11#appendix-A > > On Mon, Aug 5, 2019 at 2:32 AM Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > >> Hi, >> >> Sorry, I missed when this update was submitted, thanks for the reminder. >> >> The new version addresses most of my discuss, but missed to do anything >> about point 1 below. >> >> Otherwise it appears to address my discuss points. How do you want to >> resolve it? >> >> Cheers >> >> Magnus Westerlund >> >> > -----Original Message----- >> > From: Cullen Jennings >> > Sent: den 17 maj 2019 20:34 >> > To: Magnus Westerlund >> > Cc: The IESG ; perc-chairs@ietf.org; draft-ietf-perc- >> > double@ietf.org; suhasietf@gmail.com; perc@ietf.org >> > Subject: Re: [Perc] Magnus Westerlund's Discuss on >> draft-ietf-perc-double- >> > 10: (with DISCUSS and COMMENT) >> > >> > > >> > > 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 paddin= g >> > > 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 leaka= ge >> > > and other privacy preserving operations based on applying RTP paddin= g >> > > it would be necessary to include the RTP padding into the inner >> > > encrypted envelope. Appendix A figure indicates that is the case, bu= t >> 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 i= s >> > stripped from the payload ? >> > >> > Perhaps to make it explicitly clear we should change >> > >> > "* Payload: The RTP payload of the original packet=E2=80=9D >> > >> > to be >> > >> > "* Payload (including padding) The RTP payload (including passing) of >> the >> > original packet=E2=80=9D >> > >> > >> > >> > >> >> --000000000000c68b9405903d0d90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Magnus

=C2=A0 =C2=A0Wondering if Ri= chard's response answers your question?

Thanks=
Suhas

On Mon, Aug 5, 2019 at 7:48 AM Richard Barnes <rlb= @ipv.sx> wrote:
Hey Magnus,

Sorry, should= have responded on Point 1.=C2=A0 I think you're just mistaken on that = point.=C2=A0 Padding is included within the inner encryption.=C2=A0 The dou= ble transform is an SRTP transform like any other; outside of the SRTP stac= k, there is no "inner" or "outer", just the same old pr= otect and unprotect.=C2=A0 So padding works the same as it does with any ot= her SRTP transform.

Was there some text in the doc= ument that gave you the impression that padding was not included under the = inner encryption?=C2=A0 The only mention of padding I see in the document i= s in the figure in Appendix A [1], where the padding is correctly shown to = be within the inner encryption.=C2=A0 Happy to clarify if you have some sug= gestions for how.

--Richard


On Mon, Aug 5, 2019 at 2:32 AM Magnus Westerlund &l= t;magnu= s.westerlund@ericsson.com> wrote:
Hi,

Sorry, I missed when this update was submitted, thanks for the reminder.
The new version addresses most of my discuss, but missed to do anything abo= ut point 1 below.

Otherwise it appears to address my discuss points. How do you want to resol= ve it?

Cheers

Magnus Westerlund

> -----Original Message-----
> From: Cullen Jennings <fluffy@iii.ca>
> Sent: den 17 maj 2019 20:34
> To: Magnus Westerlund <magnus.westerlund@ericsson.com>
> Cc: The IESG <ie= sg@ietf.org>; perc-chairs@ietf.org; draft-ietf-perc-
> double@ietf.org; suhasietf@gmai= l.com; perc@ietf.org=
> Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc= -double-
> 10: (with DISCUSS and COMMENT)
>
> >
> > 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 pad= ding
> > is not included into the inner encrypted part. This prevents the<= br> > > application of RTP padding to prevent the potential privacy leaka= ge
> > that "Guidelines for the Use of Variable Bit Rate Audio with= Secure
> > RTP" (RFC 6562) documents. To prevent this type of informati= on leakage
> > and other privacy preserving operations based on applying RTP pad= ding
> > 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 i= s
> stripped from the=C2=A0 payload ?
>
> Perhaps to make it explicitly clear we should change
>
> "* Payload: The RTP payload of the original packet=E2=80=9D
>
> to be
>
> "* Payload (including padding) The RTP payload (including passing= ) of the
> original packet=E2=80=9D
>
>
>
>

--000000000000c68b9405903d0d90-- From nobody Thu Aug 29 02:50: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 344CA120815; Thu, 29 Aug 2019 02:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 YzRY-ERrG569; Thu, 29 Aug 2019 02:50:04 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20087.outbound.protection.outlook.com [40.107.2.87]) (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 15E6D12003E; Thu, 29 Aug 2019 02:50:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y244SFUNiY8n6M9B37nsuWJWRngv4hGt/7J1B5NP8CCEE6zcSHrdOBDyCHZ1aD9RjS6/CuAEZW5zDCbewsGRVb5GRKW93hx4feAKfb67PYulf9OVc5DoJge7PbL1CMtybuUBjn8IuUqEt4lBOkgRyU8G7zHz/9TbwA6zOM3UJeVvu/Umq8+hPy4+kwoC6PNepBZCk6Bzjm3Z1pJpUJDfse8TXOQTmbV793tVZChYu+Cf5rvFrBQrv39s4v4/PEALFOo/a1dGkZ5qT9Jle86TugmKWao3BwK7AU+Tpc2kFxeep6bQ2jZCNvzpVxQa+cA81kU8eaDtlYWEnzFxvRNlCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EncChcNJVdRWzFsLeYm1voKMO2Aaco3hTWEGq6K+5Vs=; b=CCvY5+u8dbm6TbF1C16gds6PNHH14wCWaEQyMd5TKplNjuk6yWT6zzw9mlB4NwX9Ik5QOWlDVq7wnwQQcjogg5PTK22QKZiZhcHHJz/3G84jGfvnbgKSNJ4NqENNtNFQLXEl76+Y4WYURqaT3qHnLRr/63hFcK9sNLjrPNLSnL9/tWUPLvvsXYhVjssvrsKTnv/2bw3UNTbg0W7dF87zRO1FkMkThuKsQ8QJVpr49ix+uLHD1quAPzcr36MS9g+3Ko333FmCz6Pkpx8Av3TCdQuDaZVLjo21YlKCML3670OFPhBEAT8CnbBjG1IN/P/RK9bHGjtMLXarTjIY/V4OcA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=EncChcNJVdRWzFsLeYm1voKMO2Aaco3hTWEGq6K+5Vs=; b=KepYwjQ3l3m8wtPrQwSsYmcV8cl6evGVCjchCvx1kQS2uVg50OzwPNd+GGig4+8Fdbl0ORgpSpPqyEMXndRAdb7uQNbhu61CFF4RybEkEwYojwS91nG+C2gl5gVUuH8XqRNHzWz8lB+KSS0XI9j6rFhuGjjMqKiowpipdE99VXY= Received: from DB7PR07MB5736.eurprd07.prod.outlook.com (20.177.194.155) by DB7PR07MB5643.eurprd07.prod.outlook.com (20.178.44.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2241.5; Thu, 29 Aug 2019 09:50:01 +0000 Received: from DB7PR07MB5736.eurprd07.prod.outlook.com ([fe80::a935:4edd:29a2:9772]) by DB7PR07MB5736.eurprd07.prod.outlook.com ([fe80::a935:4edd:29a2:9772%6]) with mapi id 15.20.2241.000; Thu, 29 Aug 2019 09:50:01 +0000 From: Magnus Westerlund To: "suhasietf@gmail.com" , "rlb@ipv.sx" CC: "perc@ietf.org" , "perc-chairs@ietf.org" , "iesg@ietf.org" , "draft-ietf-perc-double@ietf.org" , "fluffy@iii.ca" Thread-Topic: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-double-10: (with DISCUSS and COMMENT) Thread-Index: AQHVC85uMqFQ5/RAl0Cyrib7XAHyUKZvpqsAgHzvMNCAAIv1gIARSUAAgBQbigA= Date: Thu, 29 Aug 2019 09:50:01 +0000 Message-ID: <5cec79c71d859aa95e352824320ad261f8525916.camel@ericsson.com> References: <155800082724.19580.16483563575859435866.idtracker@ietfa.amsl.com> <65737EA1-49AF-4EB9-AD1F-25157B3F010D@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: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 130c0862-8a11-42bc-af14-08d72c6642d6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:DB7PR07MB5643; x-ms-traffictypediagnostic: DB7PR07MB5643: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0144B30E41 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(4636009)(136003)(366004)(396003)(346002)(376002)(39860400002)(51914003)(13464003)(189003)(199004)(14454004)(4326008)(26005)(25786009)(99936001)(102836004)(256004)(186003)(14444005)(316002)(54906003)(110136005)(6506007)(53546011)(99286004)(76176011)(8676002)(2616005)(118296001)(66066001)(81156014)(81166006)(476003)(6486002)(3846002)(5660300002)(2501003)(229853002)(486006)(8936002)(36756003)(86362001)(6116002)(44832011)(6512007)(64756008)(66946007)(91956017)(478600001)(76116006)(6246003)(66446008)(66616009)(66476007)(53936002)(66556008)(71190400001)(305945005)(71200400001)(966005)(446003)(11346002)(7736002)(6306002)(6436002)(2906002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB5643; H:DB7PR07MB5736.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: wIKqfWPq4mqtxnXEz3RqeobtqbZLawa+SsS0bYanl3tOc45pI8OZkhekKuaQKgKzyjGCpWnFpMP/MkgfotITj7kI7NKIUsU6b+/fRZffbLEPMxss2k+0RVfcWrOstrFcA5phCWJ1KdJvMpxYoN9RcxWcj5vSHI64g6LHYpM1Up/f31OPbTlZzTssc4M0XbIvkzXwoxYvI9A9Pde2lf098yZDrhRGs4ftiQQf+uBMECmnaSipp2a12FcCRuaraKBtyRLpywTssfHz8akn4uCQ8gISocRfyYWX+2SGeH0l6uipgyBLIT1hIbQCvm+OfsXqF9L2z1jUT3QNhmx2huEENKyfH8NExuca4jIYY+65RDf22d7yeudOHaciRZBlDH/XaNq7SrgsOgPnIWE+ksNgDlAVtM0LU30WMrCjDgMhius= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-qJ82gbG+x8a4F2ra2C8X" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 130c0862-8a11-42bc-af14-08d72c6642d6 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2019 09:50:01.4767 (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: DkNMwFq7fOYIpvBzoJekOAYx8ESD36ifi4pXqQpmfgR+no7gcMfGKDkJgnrbayEN/VIrhRpQ2rGNpUHukSed2p1jM6+ztTtUnXE+O4dhBUM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5643 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: Thu, 29 Aug 2019 09:50:08 -0000 --=-qJ82gbG+x8a4F2ra2C8X Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Hi, Back from vacation.=20 No Richards explanation doesn't help. Section 5.1 contains a normative description of how to create a synthetic packet. That description is not expplicit that the padding shall be part of the information that is included. Thus, implicitly the described procedure forbidds padding. Per RFC 3550 the padding is not part of the payload thus the need for being explicit about that the padding is to be included here.=20 My suggestion is still that the following bullet:=20 * Payload: The RTP payload of the original packet Is changes to be explicit that padding is to be included: "* Payload: The RTP payload (including padding) of the original packet=E2=80=9D Any other way that makes it explcit that the origianl packets padding is to be included is fine by me. But it does need to be explcit. Cheers Magnus On Fri, 2019-08-16 at 07:46 -0700, Suhas Nandakumar wrote: > Hey Magnus >=20 > Wondering if Richard's response answers your question? >=20 > Thanks > Suhas >=20 > On Mon, Aug 5, 2019 at 7:48 AM Richard Barnes wrote: > > Hey Magnus, > >=20 > > Sorry, should have responded on Point 1. I think you're just > > mistaken on that point. Padding is included within the inner > > encryption. The double transform is an SRTP transform like any > > other; outside of the SRTP stack, there is no "inner" or "outer", > > just the same old protect and unprotect. So padding works the same > > as it does with any other SRTP transform. > >=20 > > Was there some text in the document that gave you the impression > > that padding was not included under the inner encryption? The only > > mention of padding I see in the document is in the figure in > > Appendix A [1], where the padding is correctly shown to be within > > the inner encryption. Happy to clarify if you have some > > suggestions for how. > >=20 > > --Richard > >=20 > > [1]=20 > > https://tools.ietf.org/html/draft-ietf-perc-double-11#appendix-A > >=20 > > On Mon, Aug 5, 2019 at 2:32 AM Magnus Westerlund < > > magnus.westerlund@ericsson.com> wrote: > > > Hi, > > >=20 > > > Sorry, I missed when this update was submitted, thanks for the > > > reminder.=20 > > >=20 > > > The new version addresses most of my discuss, but missed to do > > > anything about point 1 below.=20 > > >=20 > > > Otherwise it appears to address my discuss points. How do you > > > want to resolve it?=20 > > >=20 > > > Cheers > > >=20 > > > Magnus Westerlund > > >=20 > > > > -----Original Message----- > > > > From: Cullen Jennings > > > > Sent: den 17 maj 2019 20:34 > > > > To: Magnus Westerlund > > > > Cc: The IESG ; perc-chairs@ietf.org; draft-ietf- > > > perc- > > > > double@ietf.org; suhasietf@gmail.com; perc@ietf.org > > > > Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf- > > > perc-double- > > > > 10: (with DISCUSS and COMMENT) > > > >=20 > > > > > > > > > > 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. > > > > > > > > >=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 ? > > > >=20 > > > > Perhaps to make it explicitly clear we should change > > > >=20 > > > > "* Payload: The RTP payload of the original packet=E2=80=9D > > > >=20 > > > > to be > > > >=20 > > > > "* Payload (including padding) The RTP payload (including > > > passing) of the > > > > original packet=E2=80=9D > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > >=20 --=20 Cheers 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 ---------------------------------------------------------------------- --=-qJ82gbG+x8a4F2ra2C8X 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 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDgyOTA5NTAwMFowLwYJKoZIhvcN AQkEMSIEIL6QcCH3X8h7+N74OZbS8yy1T8S9wI0E0S8fFmJPjNwoMGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAHtx1x9DRZLgL aL003YGEV2ll8AzdGmMjvjVwej/D6+bGCiTaHBbX7yKdpdfH+fujioxB90EP2ke/Md6X6iZrQ/Da 4klTwPndEX6mCA17IbnUeQbE0b0c84oZ6L6XUJeyPrnUIfGEuYrwEi+5DiInUvtByiRp3rBY//3v gx6WbsO6owW4bibAg/AwTE1u8iYNK7lXqAbKVKaerQ8nPw4w47FnGZsZxVOWnoXHuT/KhZ9S9/si muGkRvLdq+7VwiOr5UdHjKWwh7/uhKgBUrmoyOTNRbPcKAdV6ugifWEwLRC2C0ouEesEH2/RdnDP EkM4afnu4wrKdj7q4dv1vIwYwQAAAAAAAA== --=-qJ82gbG+x8a4F2ra2C8X-- From nobody Thu Aug 29 06:50:48 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 9932212007C for ; Thu, 29 Aug 2019 06:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 Ox7Y9YQuEUjK for ; Thu, 29 Aug 2019 06:50:35 -0700 (PDT) Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (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 96371120071 for ; Thu, 29 Aug 2019 06:50:35 -0700 (PDT) Received: by mail-oi1-x230.google.com with SMTP id l2so2613034oil.0 for ; Thu, 29 Aug 2019 06:50:35 -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=Nkcf6IS4VPV5sPNELUmSN1B0RqgM+ar2wCELsMUb36E=; b=RiZjlDWtYCgZl2fDN59KmurOd1wpCSOMuYfBYXiYu+xB6uNl43lxMJbTAEtwsL25R4 PpFqoGf5gZouujp0aZSmb7s3GYk3QFHNmAwhVjmzt6M9cHqp4We5eu5q5+JvgVFldr1d 0nJs8lScbijb+iqPzpmvuUaVOZol2CPWGSerKbedEbxMAxzh/a8k62yJOeDWkp/ShnbH aUo55vMNHk8ckgFk08RZriMTmyMX31rJv7oFb9KSf8lQLNKLgrndQDtZ0hz7RepsPK26 cNZhT3+amoQDxfg6fm9FDp6e3pPQtjVOTxeampK4kEIXBJeLZC+ClmA3oWXR6iJU3nI5 hNqw== 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=Nkcf6IS4VPV5sPNELUmSN1B0RqgM+ar2wCELsMUb36E=; b=Y023u753RVNS3DmmSAhXAxFoD0gSUyKk4pGG3DKzxA8O1GMWQvHYaLHGEbF7iVNM1e gg+w7OwRbtZlmJZtOE899CqsUj0pTWc6kKrjziaHIhlhTf3gyINXVmZFa28hOZVvZynG uhZYp0AHvPBCo5+oqHWIYe1LCQIckVbKbZL5VXaRe/8z6yETI1f7yHJRTblZ7NEr5JvR raZdf+vWu5zIODoNIyswvad86CelnP4TiB/bhdI+FemgowY3lTdwzWmAhKIvd7FRUtYt sdbU2/CqUjlNKYpL6hKoBVpciTfZZvQBj2jtZX4eo/IdFtOSFsc/r+zx4Ex7iG8dmohI YiOA== X-Gm-Message-State: APjAAAU/JcvmpiN/31nFEx6aoAZ+XWpz3YkFBzCBqIcVAU6UfG0XLnCp aU7AM0AZwiduDFlNUCKBbVOXVCtXf4WvGZXfyWRZ9w== X-Google-Smtp-Source: APXvYqxMj9wgaSbQQDSd0hV7iaF7gQHtZo5iRpScRjQHHJYrnzzFNm03+zIhxOjltIIcW869ZpIeH8gAh3n5kbKyf8M= X-Received: by 2002:aca:4f15:: with SMTP id d21mr6352381oib.36.1567086634507; Thu, 29 Aug 2019 06:50:34 -0700 (PDT) MIME-Version: 1.0 References: <155800082724.19580.16483563575859435866.idtracker@ietfa.amsl.com> <65737EA1-49AF-4EB9-AD1F-25157B3F010D@iii.ca> <5cec79c71d859aa95e352824320ad261f8525916.camel@ericsson.com> In-Reply-To: <5cec79c71d859aa95e352824320ad261f8525916.camel@ericsson.com> From: Richard Barnes Date: Thu, 29 Aug 2019 09:50:13 -0400 Message-ID: To: Magnus Westerlund Cc: "suhasietf@gmail.com" , "perc@ietf.org" , "perc-chairs@ietf.org" , "iesg@ietf.org" , "draft-ietf-perc-double@ietf.org" , "fluffy@iii.ca" Content-Type: multipart/alternative; boundary="0000000000002eb91a059141ca5e" 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: Thu, 29 Aug 2019 13:50:39 -0000 --0000000000002eb91a059141ca5e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Easy enough. I think RFC 3711 is clear enough, but if you want it to be more explicit, so it shall be. I just copied over the language from 3711. https://github.com/ietf/perc-wg/pull/174 On Thu, Aug 29, 2019 at 5:50 AM Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > Hi, > > > Back from vacation. > > No Richards explanation doesn't help. Section 5.1 contains a normative > description of how to create a synthetic packet. That description is > not expplicit that the padding shall be part of the information that is > included. Thus, implicitly the described procedure forbidds padding. > Per RFC 3550 the padding is not part of the payload thus the need for > being explicit about that the padding is to be included here. > > My suggestion is still that the following bullet: > > * Payload: The RTP payload of the original packet > > Is changes to be explicit that padding is to be included: > > "* Payload: The RTP payload (including > padding) of the original packet=E2=80=9D > > Any other way that makes it explcit that the origianl packets padding > is to be included is fine by me. But it does need to be explcit. > > Cheers > > Magnus > > On Fri, 2019-08-16 at 07:46 -0700, Suhas Nandakumar wrote: > > Hey Magnus > > > > Wondering if Richard's response answers your question? > > > > Thanks > > Suhas > > > > On Mon, Aug 5, 2019 at 7:48 AM Richard Barnes wrote: > > > Hey Magnus, > > > > > > Sorry, should have responded on Point 1. I think you're just > > > mistaken on that point. Padding is included within the inner > > > encryption. The double transform is an SRTP transform like any > > > other; outside of the SRTP stack, there is no "inner" or "outer", > > > just the same old protect and unprotect. So padding works the same > > > as it does with any other SRTP transform. > > > > > > Was there some text in the document that gave you the impression > > > that padding was not included under the inner encryption? The only > > > mention of padding I see in the document is in the figure in > > > Appendix A [1], where the padding is correctly shown to be within > > > the inner encryption. Happy to clarify if you have some > > > suggestions for how. > > > > > > --Richard > > > > > > [1] > > > https://tools.ietf.org/html/draft-ietf-perc-double-11#appendix-A > > > > > > On Mon, Aug 5, 2019 at 2:32 AM Magnus Westerlund < > > > magnus.westerlund@ericsson.com> wrote: > > > > Hi, > > > > > > > > Sorry, I missed when this update was submitted, thanks for the > > > > reminder. > > > > > > > > The new version addresses most of my discuss, but missed to do > > > > anything about point 1 below. > > > > > > > > Otherwise it appears to address my discuss points. How do you > > > > want to resolve it? > > > > > > > > Cheers > > > > > > > > Magnus Westerlund > > > > > > > > > -----Original Message----- > > > > > From: Cullen Jennings > > > > > Sent: den 17 maj 2019 20:34 > > > > > To: Magnus Westerlund > > > > > Cc: The IESG ; perc-chairs@ietf.org; draft-ietf- > > > > perc- > > > > > double@ietf.org; suhasietf@gmail.com; perc@ietf.org > > > > > Subject: Re: [Perc] Magnus Westerlund's Discuss on draft-ietf- > > > > perc-double- > > > > > 10: (with DISCUSS and COMMENT) > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > 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 > > > > > > > > > > "* Payload: The RTP payload of the original packet=E2=80=9D > > > > > > > > > > to be > > > > > > > > > > "* Payload (including padding) The RTP payload (including > > > > passing) of the > > > > > original packet=E2=80=9D > > > > > > > > > > > > > > > > > > > > > > > > > -- > 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 > ---------------------------------------------------------------------- > > --0000000000002eb91a059141ca5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Easy enough.=C2=A0 I think RFC 3711 is clear enough, = but if you want it to be more explicit, so it shall be.=C2=A0 I just copied= over the language from 3711.




=
On Thu, Aug 29, 2019 at 5:50 AM Magnu= s Westerlund <magnus.w= esterlund@ericsson.com> wrote:
Hi,
Hi,


Back from vacation.

No Richards explanation doesn't help. Section 5.1 contains a normative<= br> description of how to create a synthetic packet. That description is
not expplicit that the padding shall be part of the information that is
included. Thus, implicitly the described procedure forbidds padding.
Per RFC 3550 the padding is not part of the payload thus the need for
being explicit about that the padding is to be included here.

My suggestion is still that the following bullet:

=C2=A0*=C2=A0 Payload: The RTP payload of the original packet

Is changes to be explicit that padding is to be included:

"* Payload: The RTP payload (including
=C2=A0 =C2=A0padding) of the original packet=E2=80=9D

Any other way that makes it explcit that the origianl packets padding
is to be included is fine by me. But it does need to be explcit.

Cheers

Magnus

On Fri, 2019-08-16 at 07:46 -0700, Suhas Nandakumar wrote:
> Hey Magnus
>
>=C2=A0 =C2=A0 Wondering if Richard's response answers your question= ?
>
> Thanks
> Suhas
>
> On Mon, Aug 5, 2019 at 7:48 AM Richard Barnes <rlb@ipv.sx> wrote= :
> > Hey Magnus,
> >
> > Sorry, should have responded on Point 1.=C2=A0 I think you're= just
> > mistaken on that point.=C2=A0 Padding is included within the inne= r
> > encryption.=C2=A0 The double transform is an SRTP transform like = any
> > other; outside of the SRTP stack, there is no "inner" o= r "outer",
> > just the same old protect and unprotect.=C2=A0 So padding works t= he same
> > as it does with any other SRTP transform.
> >
> > Was there some text in the document that gave you the impression<= br> > > that padding was not included under the inner encryption?=C2=A0 T= he only
> > mention of padding I see in the document is in the figure in
> > Appendix A [1], where the padding is correctly shown to be within=
> > the inner encryption.=C2=A0 Happy to clarify if you have some
> > suggestions for how.
> >
> > --Richard
> >
> > [1]
> > https://tools.ietf.org/htm= l/draft-ietf-perc-double-11#appendix-A
> >
> > On Mon, Aug 5, 2019 at 2:32 AM Magnus Westerlund <
> > magnus.westerlund@ericsson.com> wrote:
> > > Hi,
> > >
> > > Sorry, I missed when this update was submitted, thanks for t= he
> > > reminder.
> > >
> > > The new version addresses most of my discuss, but missed to = do
> > > anything about point 1 below.
> > >
> > > Otherwise it appears to address my discuss points. How do yo= u
> > > want to resolve it?
> > >
> > > Cheers
> > >
> > > Magnus Westerlund
> > >
> > > > -----Original Message-----
> > > > From: Cullen Jennings <fluffy@iii.ca>
> > > > Sent: den 17 maj 2019 20:34
> > > > To: Magnus Westerlund <magnus.westerlund@ericsson.com&g= t;
> > > > Cc: The IESG <iesg@ietf.org>; perc-chairs@ietf.org; draft-ietf-
> > > perc-
> > > > do= uble@ietf.org; suhasietf@gmail.com; perc@ietf.org
> > > > Subject: Re: [Perc] Magnus Westerlund's Discuss on = draft-ietf-
> > > perc-double-
> > > > 10: (with DISCUSS and COMMENT)
> > > >
> > > > >
> > > > > 1. Section 5.1:
> > > > >
> > > > > To me it appears that one fundamental security fla= w exists in
> > > the
> > > > > definition of the inner encryption. That is the fa= ct that RTP
> > > padding
> > > > > is not included into the inner encrypted part. Thi= s prevents
> > > the
> > > > > application of RTP padding to prevent the potentia= l privacy
> > > leakage
> > > > > that "Guidelines for the Use of Variable Bit = Rate Audio with
> > > Secure
> > > > > RTP" (RFC 6562) documents. To prevent this ty= pe of
> > > information leakage
> > > > > and other privacy preserving operations based on a= pplying RTP
> > > padding
> > > > > it would be necessary to include the RTP padding i= nto the
> > > inner
> > > > > encrypted envelope. Appendix A figure indicates th= at 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 thin= k the
> > > padding is
> > > > stripped from the=C2=A0 payload ?
> > > >
> > > > Perhaps to make it explicitly clear we should change > > > >
> > > > "* Payload: The RTP payload of the original packet= =E2=80=9D
> > > >
> > > > to be
> > > >
> > > > "* Payload (including padding) The RTP payload (in= cluding
> > > passing) of the
> > > > original packet=E2=80=9D
> > > >
> > > >
> > > >
> > > >
> > >
--
Cheers

Magnus Westerlund


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

--0000000000002eb91a059141ca5e-- From nobody Thu Aug 29 07:19: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 AD722120071; Thu, 29 Aug 2019 07:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 JX_5lJFnQgTS; Thu, 29 Aug 2019 07:19:23 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140080.outbound.protection.outlook.com [40.107.14.80]) (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 DE03812004A; Thu, 29 Aug 2019 07:19:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h5r1GZ8afE9eCVdCLwP0BuiqmgMMvfTti2wof9EKvxYk5NvQKNpEyDqEckG2qq9SdMo3T9vTgSv+2z+RN/6mOP0dOqW0nfNIujWZqp1MxFZg0UIHSJYOewxG4zV/4ZUy5rMjqAZhD0aEiyhacL1uYYx1F+bdWjgYPJBElXfmcYRatmu3f5Fh8xp+6dtrowtZOau2+gtMJdzTVYAPWjRWnkdFFcV6FvGUqRW7vg2WtI8rTHilatPWyjcYrGSZ9yetWg3Eb8Dk4O2Ayg1Pt7EryVFWCfU4c+LJS/ZnyfiHFmdg8gNKqG5T4IkG/awm5ephUxMaxX87oq1q95MyrbWnFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UI1YdICF1U8TACOPif1AoIY4PM6RETfcAPD8un9e8OM=; b=f4BEtwuJHo5fXcLi3yaDBi2xnFLqH7dm5FBeYsCQAbXKKliSwFJRdJuwNmL+43WZqsv2vUHGmEXCvolxQV+1f0uAPPyTm75wwDFQHsFj+o+/41sdgurXjHl9pLtzmfyHwYrS/GEOd4eQ9oKfHSBwAjMyvYeXkeIFabousEy/pNhXHNNLeXMXxkQax/SpvQv4Le+LmmwrWaee1C3ufN0aa75ihP/Lhg8s04PS//VJn4KVFpXwF0bxTx9I/lE/mAkbXwAx6t4qrXWkG+r2dksYviatYxhZKP92cGqaJbeQKJvrMEXEcHreo+K5tCuPP35ehJ7onoNXzf+VJSrp/NtEdg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none 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=UI1YdICF1U8TACOPif1AoIY4PM6RETfcAPD8un9e8OM=; b=USzP462+UK47sNCKpNl+Pa2ovbVSAdI6iS6NcGtp8Zn6aNSzKxm4u7fuFmfAgM1BYJljwDUEzum2eupLee0bSeIO7o0RPsXRklEfzgwRqqG+NC/OHkP92TMmgYM4F+2RFYTTowQ+a47cO/Lp4aVjIO3tePMaeJmg47CRSdi4OAc= Received: from DB7PR07MB5736.eurprd07.prod.outlook.com (20.177.194.155) by DB7PR07MB5564.eurprd07.prod.outlook.com (20.178.46.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.15; Thu, 29 Aug 2019 14:19:20 +0000 Received: from DB7PR07MB5736.eurprd07.prod.outlook.com ([fe80::a935:4edd:29a2:9772]) by DB7PR07MB5736.eurprd07.prod.outlook.com ([fe80::a935:4edd:29a2:9772%6]) with mapi id 15.20.2241.000; Thu, 29 Aug 2019 14:19:20 +0000 From: Magnus Westerlund To: "rlb@ipv.sx" CC: "fluffy@iii.ca" , "perc@ietf.org" , "suhasietf@gmail.com" , "iesg@ietf.org" , "perc-chairs@ietf.org" , "draft-ietf-perc-double@ietf.org" Thread-Topic: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-double-10: (with DISCUSS and COMMENT) Thread-Index: AQHVC85uMqFQ5/RAl0Cyrib7XAHyUKZvpqsAgHzvMNCAAIv1gIARSUAAgBQbigCAAEMlgIAACBkA Date: Thu, 29 Aug 2019 14:19:20 +0000 Message-ID: References: <155800082724.19580.16483563575859435866.idtracker@ietfa.amsl.com> <65737EA1-49AF-4EB9-AD1F-25157B3F010D@iii.ca> <5cec79c71d859aa95e352824320ad261f8525916.camel@ericsson.com> 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: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: afbb8f74-2f70-4777-b8a1-08d72c8be222 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:DB7PR07MB5564; x-ms-traffictypediagnostic: DB7PR07MB5564: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0144B30E41 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(346002)(396003)(376002)(366004)(199004)(189003)(13464003)(186003)(25786009)(81156014)(316002)(486006)(11346002)(3846002)(26005)(1730700003)(76116006)(66616009)(64756008)(66446008)(66476007)(14444005)(81166006)(14454004)(66556008)(66946007)(2906002)(71190400001)(8676002)(2616005)(256004)(6116002)(71200400001)(6246003)(478600001)(99936001)(305945005)(229853002)(4326008)(7736002)(6306002)(5640700003)(6512007)(6506007)(2351001)(76176011)(53936002)(6436002)(6916009)(66066001)(5660300002)(102836004)(2501003)(476003)(6486002)(446003)(36756003)(8936002)(118296001)(53546011)(99286004)(91956017)(966005)(54906003)(44832011)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB5564; H:DB7PR07MB5736.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: WFTKq+vZKp28YoDdXCu1g0Emzpq7bec3wzaq86bhclRJjYr22YA0lm4NzhIbuTW83EH8wZIr7ReGDmV4p8C26lCl49T4gozuRo/FqWJXNexG2KqOyBi4iEmZuDs1ww0v18OG77CHDI6cj4RQ+BxUwDGH9vQkGSnwUpxLjmkTK/fSMat69Dr87oT81eWIHpitrJbsjQ7rFaUtUlHOdxWiJwsMTiuRVqoaixi3m9mgADlYi6evLmc3DFaVn0QwieIWnQYkd569AcRLEtGb/DKgVah1aLQxyt/vsPxjRrCNckkttL8pVEGHzllxVvWmo4EgoxW59+Bp480AqJ+1joZpP3MVf59kJDgSakNZLYbFMukak94gyYNCu+8dYO4SMoybb+0FjgHzE6Ut7LFbYsLaGqhTX2USkl96Z6UPZ5WBSgw= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-cqTlAM2FBDeaNtMvBdY/" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: afbb8f74-2f70-4777-b8a1-08d72c8be222 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2019 14:19:20.1377 (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: sKksnWT4Nn9UcDOCWuuoJxtCSK7aocpCAgimtbir+CZ7nlv3halid4Hghg7yEMr87XNiTBqKoPEyFHMApYJCjgPbXRmT9e5/GuN7s9m8GjE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5564 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: Thu, 29 Aug 2019 14:19:27 -0000 --=-cqTlAM2FBDeaNtMvBdY/ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I will clear when the new version is available or an RFC-editor note to this affect has been included.=20 Cheers Magnus On Thu, 2019-08-29 at 09:50 -0400, Richard Barnes wrote: > Easy enough. I think RFC 3711 is clear enough, but if you want it to > be more explicit, so it shall be. I just copied over the language > from 3711. >=20 > https://github.com/ietf/perc-wg/pull/174 >=20 >=20 >=20 > On Thu, Aug 29, 2019 at 5:50 AM Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: > > Hi, > > Hi, > >=20 > >=20 > > Back from vacation.=20 > >=20 > > No Richards explanation doesn't help. Section 5.1 contains a > > normative > > description of how to create a synthetic packet. That description > > is > > not expplicit that the padding shall be part of the information > > that is > > included. Thus, implicitly the described procedure forbidds > > padding. > > Per RFC 3550 the padding is not part of the payload thus the need > > for > > being explicit about that the padding is to be included here.=20 > >=20 > > My suggestion is still that the following bullet:=20 > >=20 > > * Payload: The RTP payload of the original packet > >=20 > > Is changes to be explicit that padding is to be included: > >=20 > > "* Payload: The RTP payload (including > > padding) of the original packet=E2=80=9D > >=20 > > Any other way that makes it explcit that the origianl packets > > padding > > is to be included is fine by me. But it does need to be explcit. > >=20 > > Cheers > >=20 > > Magnus > >=20 > > On Fri, 2019-08-16 at 07:46 -0700, Suhas Nandakumar wrote: > > > Hey Magnus > > >=20 > > > Wondering if Richard's response answers your question? > > >=20 > > > Thanks > > > Suhas > > >=20 > > > On Mon, Aug 5, 2019 at 7:48 AM Richard Barnes wrote: > > > > Hey Magnus, > > > >=20 > > > > Sorry, should have responded on Point 1. I think you're just > > > > mistaken on that point. Padding is included within the inner > > > > encryption. The double transform is an SRTP transform like any > > > > other; outside of the SRTP stack, there is no "inner" or > > "outer", > > > > just the same old protect and unprotect. So padding works the > > same > > > > as it does with any other SRTP transform. > > > >=20 > > > > Was there some text in the document that gave you the > > impression > > > > that padding was not included under the inner encryption? The > > only > > > > mention of padding I see in the document is in the figure in > > > > Appendix A [1], where the padding is correctly shown to be > > within > > > > the inner encryption. Happy to clarify if you have some > > > > suggestions for how. > > > >=20 > > > > --Richard > > > >=20 > > > > [1]=20 > > > >=20 > > https://tools.ietf.org/html/draft-ietf-perc-double-11#appendix-A > > > >=20 > > > > On Mon, Aug 5, 2019 at 2:32 AM Magnus Westerlund < > > > > magnus.westerlund@ericsson.com> wrote: > > > > > Hi, > > > > >=20 > > > > > Sorry, I missed when this update was submitted, thanks for > > the > > > > > reminder.=20 > > > > >=20 > > > > > The new version addresses most of my discuss, but missed to > > do > > > > > anything about point 1 below.=20 > > > > >=20 > > > > > Otherwise it appears to address my discuss points. How do you > > > > > want to resolve it?=20 > > > > >=20 > > > > > Cheers > > > > >=20 > > > > > Magnus Westerlund > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Cullen Jennings > > > > > > Sent: den 17 maj 2019 20:34 > > > > > > To: Magnus Westerlund > > > > > > Cc: The IESG ; perc-chairs@ietf.org; draft- > > ietf- > > > > > perc- > > > > > > double@ietf.org; suhasietf@gmail.com; perc@ietf.org > > > > > > Subject: Re: [Perc] Magnus Westerlund's Discuss on draft- > > ietf- > > > > > perc-double- > > > > > > 10: (with DISCUSS and COMMENT) > > > > > >=20 > > > > > > > > > > > > > > 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. > > > > > > > > > > > > >=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 ? > > > > > >=20 > > > > > > Perhaps to make it explicitly clear we should change > > > > > >=20 > > > > > > "* Payload: The RTP payload of the original packet=E2=80=9D > > > > > >=20 > > > > > > to be > > > > > >=20 > > > > > > "* Payload (including padding) The RTP payload (including > > > > > passing) of the > > > > > > original packet=E2=80=9D > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > >=20 --=20 Cheers 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 ---------------------------------------------------------------------- --=-cqTlAM2FBDeaNtMvBdY/ 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 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDgyOTE0MTkxOVowLwYJKoZIhvcN AQkEMSIEIFLQU1bBBR4+3uCSVtL3b4vhFiy+QY7EOlf6VUCsfLdgMGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAbQvy/0swp453 fdAuK/K0RpVZAT6AsT5rhTHyX/eOPq3wjRHPSBjfk45V84Rdw9kFLzjsjT1BvCfrvSnB9w3MMloF aUYqvq/coURKuHL+Yr5Pd+4zSz1nRJEWlH9i7P/nHDh7wSyaOzDKucQwET2Cr0Og2j8TPMxWrGvH +CdE/hyRMInqWEKKB5elYLQ9AH8E0pNNgYbaPe/UjymTegtEilyfjcfrAP9oy70CV1X7DdWGTQpg GLqGrsj1cCjINu7RTO7Ceq83gaJSLLH9lbfTQyV1tRHriMhtiHlb+IXth7G8MY73xSTjOarjYQtS /xJ5rkF0tMMlnCNs2MuXMEAfBwAAAAAAAA== --=-cqTlAM2FBDeaNtMvBdY/-- From nobody Thu Aug 29 07:27:21 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 9D4241200C3; Thu, 29 Aug 2019 07:27:13 -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.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: perc@ietf.org Message-ID: <156708883360.21008.8686991910994190146@ietfa.amsl.com> Date: Thu, 29 Aug 2019 07:27:13 -0700 Archived-At: Subject: [Perc] I-D Action: draft-ietf-perc-double-12.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: Thu, 29 Aug 2019 14:27:14 -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 : SRTP Double Encryption Procedures Authors : Cullen Jennings Paul E. Jones Richard Barnes Adam Roach Filename : draft-ietf-perc-double-12.txt Pages : 18 Date : 2019-08-29 Abstract: In some conferencing scenarios, it is desirable for an intermediary to be able to manipulate some parameters in Real Time Protocol (RTP) packets, while still providing strong end-to-end security guarantees. This document defines a cryptographic transform for the Secure Real Time Protocol (SRTP) that uses two separate but related cryptographic operations to provide hop-by-hop and end-to-end security guarantees. Both the end-to-end and hop-by-hop cryptographic algorithms can utilize an authenticated encryption with associated data (AEAD) algorithm or take advantage of future SRTP transforms with different properties. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-perc-double/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-perc-double-12 https://datatracker.ietf.org/doc/html/draft-ietf-perc-double-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-double-12 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/ From nobody Thu Aug 29 07:30:10 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 7016A1200C3 for ; Thu, 29 Aug 2019 07:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 QGKV3vM1g2S3 for ; Thu, 29 Aug 2019 07:30:05 -0700 (PDT) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 B7C6D120025 for ; Thu, 29 Aug 2019 07:30:05 -0700 (PDT) Received: by mail-ot1-x330.google.com with SMTP id b1so3594972otp.6 for ; Thu, 29 Aug 2019 07:30:05 -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=eErlWzRtoK0GTjczWBW4leaP+g8UaHt63ReBCIxWzkw=; b=Gk1gbQpxC2yp+WqV24pZ+1ncQ10JhXgAR0yAbmxUmf7godbN4lQzUQs6gWgn163mhS dLtfmXBU2zVLdN+7xuhWB7g7yM02Ct+YaP1T4QNE/h0SJT9pt8fBMcOryfP6nEQgfViQ C0lY3HTKLYfCP3HuJXztPUEaHDUXKN0IrShq16wTTskr9hkehb+ZmcoV76luM4wBp54A gp2vYyPj6juWlOua5mkPfj/josb7O/ljpDGjPOalQ7hoOdDguKybT3vG7Inl8Q8NWLqi zygULRYqHINXbOJqNrakZpVDgP73p2dGCYBVOn5SlIqHa/Mxq/MF9fH7eg4iRgWnHasr ZmUA== 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=eErlWzRtoK0GTjczWBW4leaP+g8UaHt63ReBCIxWzkw=; b=Cbqdsh4P3rkwShbVC3Dt8udLJv4hH2IzOvuQA3HAWvxgsceYpB6MmsT32/yXRlsKRA 9EMNGkIsWxx2BoTNiRnGKZcRIaX3wr4B9dm2O3qzWaTG2yqvZlofze5FMuIh5bWRLv5x oIPMpVHf0VvdsTeCD6b0olzRXSnY2tvpzDncDYZgF8q/mHVcHDNoxcKJNnT9AmnXdK93 dsbJkze1TQq+VH0JlZp1vrFhSrIGXLR6SD0MuwvijkNO+sRL+whdXocQv6ety5H+o2nk yT7KcfjR6e8j1S8BnMmJWtojhRpghu9hBgGfVw6nTA9pAdSOQPGpUGwtZspZPeK96F+E TPQw== X-Gm-Message-State: APjAAAX+4lvWXkjrOj7Pl3dQHwrOMIHgD8iw10ZiKp7zhZK3kTrR1ZE0 OpdKevjrKCl0o/YBB7ZYIVBql1oWLR9cWStyWFoY1A== X-Google-Smtp-Source: APXvYqyKfDdF3j7XbBzMYMJyFYH3ouwkMEBai3/wFphcGhYNmrl775o5MRHRSUl/eto1FsCqtRFfXZp+CzTIqoiNwwQ= X-Received: by 2002:a05:6830:1bd4:: with SMTP id v20mr337422ota.159.1567089004813; Thu, 29 Aug 2019 07:30:04 -0700 (PDT) MIME-Version: 1.0 References: <155800082724.19580.16483563575859435866.idtracker@ietfa.amsl.com> <65737EA1-49AF-4EB9-AD1F-25157B3F010D@iii.ca> <5cec79c71d859aa95e352824320ad261f8525916.camel@ericsson.com> In-Reply-To: From: Richard Barnes Date: Thu, 29 Aug 2019 10:29:43 -0400 Message-ID: To: Magnus Westerlund Cc: "fluffy@iii.ca" , "perc@ietf.org" , "suhasietf@gmail.com" , "iesg@ietf.org" , "perc-chairs@ietf.org" , "draft-ietf-perc-double@ietf.org" Content-Type: multipart/alternative; boundary="00000000000076ab88059142579a" 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: Thu, 29 Aug 2019 14:30:09 -0000 --00000000000076ab88059142579a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable draft-12 just posted. https://datatracker.ietf.org/doc/draft-ietf-perc-double/ On Thu, Aug 29, 2019 at 10:19 AM Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > I will clear when the new version is available or an RFC-editor note to > this affect has been included. > > Cheers > > Magnus > > On Thu, 2019-08-29 at 09:50 -0400, Richard Barnes wrote: > > Easy enough. I think RFC 3711 is clear enough, but if you want it to > > be more explicit, so it shall be. I just copied over the language > > from 3711. > > > > https://github.com/ietf/perc-wg/pull/174 > > > > > > > > On Thu, Aug 29, 2019 at 5:50 AM Magnus Westerlund < > > magnus.westerlund@ericsson.com> wrote: > > > Hi, > > > Hi, > > > > > > > > > Back from vacation. > > > > > > No Richards explanation doesn't help. Section 5.1 contains a > > > normative > > > description of how to create a synthetic packet. That description > > > is > > > not expplicit that the padding shall be part of the information > > > that is > > > included. Thus, implicitly the described procedure forbidds > > > padding. > > > Per RFC 3550 the padding is not part of the payload thus the need > > > for > > > being explicit about that the padding is to be included here. > > > > > > My suggestion is still that the following bullet: > > > > > > * Payload: The RTP payload of the original packet > > > > > > Is changes to be explicit that padding is to be included: > > > > > > "* Payload: The RTP payload (including > > > padding) of the original packet=E2=80=9D > > > > > > Any other way that makes it explcit that the origianl packets > > > padding > > > is to be included is fine by me. But it does need to be explcit. > > > > > > Cheers > > > > > > Magnus > > > > > > On Fri, 2019-08-16 at 07:46 -0700, Suhas Nandakumar wrote: > > > > Hey Magnus > > > > > > > > Wondering if Richard's response answers your question? > > > > > > > > Thanks > > > > Suhas > > > > > > > > On Mon, Aug 5, 2019 at 7:48 AM Richard Barnes wrote: > > > > > Hey Magnus, > > > > > > > > > > Sorry, should have responded on Point 1. I think you're just > > > > > mistaken on that point. Padding is included within the inner > > > > > encryption. The double transform is an SRTP transform like any > > > > > other; outside of the SRTP stack, there is no "inner" or > > > "outer", > > > > > just the same old protect and unprotect. So padding works the > > > same > > > > > as it does with any other SRTP transform. > > > > > > > > > > Was there some text in the document that gave you the > > > impression > > > > > that padding was not included under the inner encryption? The > > > only > > > > > mention of padding I see in the document is in the figure in > > > > > Appendix A [1], where the padding is correctly shown to be > > > within > > > > > the inner encryption. Happy to clarify if you have some > > > > > suggestions for how. > > > > > > > > > > --Richard > > > > > > > > > > [1] > > > > > > > > https://tools.ietf.org/html/draft-ietf-perc-double-11#appendix-A > > > > > > > > > > On Mon, Aug 5, 2019 at 2:32 AM Magnus Westerlund < > > > > > magnus.westerlund@ericsson.com> wrote: > > > > > > Hi, > > > > > > > > > > > > Sorry, I missed when this update was submitted, thanks for > > > the > > > > > > reminder. > > > > > > > > > > > > The new version addresses most of my discuss, but missed to > > > do > > > > > > anything about point 1 below. > > > > > > > > > > > > Otherwise it appears to address my discuss points. How do you > > > > > > want to resolve it? > > > > > > > > > > > > Cheers > > > > > > > > > > > > Magnus Westerlund > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Cullen Jennings > > > > > > > Sent: den 17 maj 2019 20:34 > > > > > > > To: Magnus Westerlund > > > > > > > Cc: The IESG ; perc-chairs@ietf.org; draft- > > > ietf- > > > > > > perc- > > > > > > > double@ietf.org; suhasietf@gmail.com; perc@ietf.org > > > > > > > Subject: Re: [Perc] Magnus Westerlund's Discuss on draft- > > > ietf- > > > > > > perc-double- > > > > > > > 10: (with DISCUSS and COMMENT) > > > > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > "* Payload: The RTP payload of the original packet=E2=80=9D > > > > > > > > > > > > > > to be > > > > > > > > > > > > > > "* Payload (including padding) The RTP payload (including > > > > > > passing) of the > > > > > > > original packet=E2=80=9D > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > 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 > ---------------------------------------------------------------------- > > > --00000000000076ab88059142579a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Aug 29, 2019= at 10:19 AM Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
Hi,

I will clear when the new version is available or an RFC-editor note to
this affect has been included.

Cheers

Magnus

On Thu, 2019-08-29 at 09:50 -0400, Richard Barnes wrote:
> Easy enough.=C2=A0 I think RFC 3711 is clear enough, but if you want i= t to
> be more explicit, so it shall be.=C2=A0 I just copied over the languag= e
> from 3711.
>
> https://github.com/ietf/perc-wg/pull/174
>
>
>
> On Thu, Aug 29, 2019 at 5:50 AM Magnus Westerlund <
> ma= gnus.westerlund@ericsson.com> wrote:
> > Hi,
> > Hi,
> >
> >
> > Back from vacation.
> >
> > No Richards explanation doesn't help. Section 5.1 contains a<= br> > > normative
> > description of how to create a synthetic packet. That description=
> > is
> > not expplicit that the padding shall be part of the information > > that is
> > included. Thus, implicitly the described procedure forbidds
> > padding.
> > Per RFC 3550 the padding is not part of the payload thus the need=
> > for
> > being explicit about that the padding is to be included here. > >
> > My suggestion is still that the following bullet:
> >
> >=C2=A0 *=C2=A0 Payload: The RTP payload of the original packet
> >
> > Is changes to be explicit that padding is to be included:
> >
> > "* Payload: The RTP payload (including
> >=C2=A0 =C2=A0 padding) of the original packet=E2=80=9D
> >
> > Any other way that makes it explcit that the origianl packets
> > padding
> > is to be included is fine by me. But it does need to be explcit.<= br> > >
> > Cheers
> >
> > Magnus
> >
> > On Fri, 2019-08-16 at 07:46 -0700, Suhas Nandakumar wrote:
> > > Hey Magnus
> > >
> > >=C2=A0 =C2=A0 Wondering if Richard's response answers you= r question?
> > >
> > > Thanks
> > > Suhas
> > >
> > > On Mon, Aug 5, 2019 at 7:48 AM Richard Barnes <rlb@ipv.sx= > wrote:
> > > > Hey Magnus,
> > > >
> > > > Sorry, should have responded on Point 1.=C2=A0 I think = you're just
> > > > mistaken on that point.=C2=A0 Padding is included withi= n the inner
> > > > encryption.=C2=A0 The double transform is an SRTP trans= form like any
> > > > other; outside of the SRTP stack, there is no "inn= er" or
> > "outer",
> > > > just the same old protect and unprotect.=C2=A0 So paddi= ng works the
> > same
> > > > as it does with any other SRTP transform.
> > > >
> > > > Was there some text in the document that gave you the > > impression
> > > > that padding was not included under the inner encryptio= n?=C2=A0 The
> > only
> > > > mention of padding I see in the document is in the figu= re in
> > > > Appendix A [1], where the padding is correctly shown to= be
> > within
> > > > the inner encryption.=C2=A0 Happy to clarify if you hav= e some
> > > > suggestions for how.
> > > >
> > > > --Richard
> > > >
> > > > [1]
> > > >
> > https://tools.ietf.org/htm= l/draft-ietf-perc-double-11#appendix-A
> > > >
> > > > On Mon, Aug 5, 2019 at 2:32 AM Magnus Westerlund < > > > > magnus.westerlund@ericsson.com> wrote:
> > > > > Hi,
> > > > >
> > > > > Sorry, I missed when this update was submitted, th= anks for
> > the
> > > > > reminder.
> > > > >
> > > > > The new version addresses most of my discuss, but = missed to
> > do
> > > > > anything about point 1 below.
> > > > >
> > > > > Otherwise it appears to address my discuss points.= How do you
> > > > > want to resolve it?
> > > > >
> > > > > Cheers
> > > > >
> > > > > Magnus Westerlund
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Cullen Jennings <fluffy@iii.ca>
> > > > > > Sent: den 17 maj 2019 20:34
> > > > > > To: Magnus Westerlund <magnus.westerlund@ericsson= .com>
> > > > > > Cc: The IESG <iesg@ietf.org>; perc-chairs@ietf.org; draft-
> > ietf-
> > > > > perc-
> > > > > > double@ietf.org; suhasietf@gmail.com; perc@ietf.org
> > > > > > Subject: Re: [Perc] Magnus Westerlund's D= iscuss on draft-
> > ietf-
> > > > > perc-double-
> > > > > > 10: (with DISCUSS and COMMENT)
> > > > > >
> > > > > > >
> > > > > > > 1. Section 5.1:
> > > > > > >
> > > > > > > To me it appears that one fundamental se= curity 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 th= e potential
> > privacy
> > > > > leakage
> > > > > > > that "Guidelines for the Use of Var= iable Bit Rate Audio
> > with
> > > > > Secure
> > > > > > > RTP" (RFC 6562) documents. To preve= nt 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 in= dicates that is
> > the
> > > > > case, but the
> > > > > > process description in 5.1 is not matching th= at.
> > > > > > >
> > > > > >
> > > > > > 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 make= s you think
> > the
> > > > > padding is
> > > > > > stripped from the=C2=A0 payload ?
> > > > > >
> > > > > > Perhaps to make it explicitly clear we should= change
> > > > > >
> > > > > > "* Payload: The RTP payload of the origi= nal packet=E2=80=9D
> > > > > >
> > > > > > to be
> > > > > >
> > > > > > "* Payload (including padding) The RTP p= ayload (including
> > > > > passing) of the
> > > > > > original packet=E2=80=9D
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
--
Cheers

Magnus Westerlund


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


--00000000000076ab88059142579a-- From nobody Thu Aug 29 08:20:54 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 7E6BA1208E5; Thu, 29 Aug 2019 08:20:52 -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.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <156709205250.1007.2506634901199730438.idtracker@ietfa.amsl.com> Date: Thu, 29 Aug 2019 08:20:52 -0700 Archived-At: Subject: [Perc] Magnus Westerlund's Yes on draft-ietf-perc-double-12: (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, 29 Aug 2019 15:20:53 -0000 Magnus Westerlund has entered the following ballot position for draft-ietf-perc-double-12: 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: ---------------------------------------------------------------------- Thanks for resolving the issues. From nobody Thu Aug 29 12:26:41 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 DA949120BF0; Thu, 29 Aug 2019 12:26:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , draft-ietf-perc-double@ietf.org, suhasietf@gmail.com, perc@ietf.org, Suhas Nandakumar , perc-chairs@ietf.org, alexey.melnikov@isode.com, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156710679188.1114.18007292636977916354.idtracker@ietfa.amsl.com> Date: Thu, 29 Aug 2019 12:26:31 -0700 Archived-At: Subject: [Perc] Protocol Action: 'SRTP Double Encryption Procedures' to Proposed Standard (draft-ietf-perc-double-12.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: Thu, 29 Aug 2019 19:26:32 -0000 The IESG has approved the following document: - 'SRTP Double Encryption Procedures' (draft-ietf-perc-double-12.txt) as Proposed Standard This document is the product of the Privacy Enhanced RTP Conferencing Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-perc-double/ Technical Summary This document define SRTP procedures for enabling end to end media confidentiality and integrity for end-points in a Multimedia conferences. It does so by defining 2 types of SRTP transforms - outer and inner. The inner transform is responsible for ensuring end-to-end integrity and encryption. The outer transform covers integrity and encryption hop-by-hop (between endpoints and the media distributor or between the media distributors). Working Group Summary This document has been discussed and reviewed several times by the WG. There were few individuals with concerns regarding the following areas 1. Allow Media distributor (MD) to modify the SSRC field in the RTP header. However they weren't able to propose solutions that can mitigate the SSRC splicing attack identified by the WG. Also to note, the WG had previously reached consensus on non-modifiability of the SSRC by the media distributor. However, the discussion was re-opened to help the concerned individual to put forward the proposals. But as aforementioned, there was no proposal submitted that satisfactorily addressed the splicing attack. Hence the WG decided to go forward with previously reached consensus to not allow MD to modify the SSRC. 2. Mechanisms to carry the end to end scoped payload header information: Originally the proposal was to carry such information as an RTP header extension. However, there was a proposal to carry similar information as the payload header. The authors of the document made accommodations to work out a solution that addressed the concern. This involved moving the OHB from header extension to payload header as part of the endpoint procedures. Additionally there were complaints about complexity and bits on the wire. However, no one brought alternative proposals to the WG that met the security objectives. The chairs called for consensus - in-room and on-list -, there was support to go with the procedures defined in the current version of the specification. Even though there are few individuals who aren't totally happy, the WG had consensus on the proposals. Also there were discussions on solution approaches for dealing with the repair packets. Two possible solutions were discussed. One was related to applying the hop-by-hop transform for the repair packet on the single encrypted packet vs double encrypted packet. The former implying a split in SRTP transform context states (E2E, RTX, HBH) and the latter implying a simple canonical way of doing classic SRTP (But just with a new transform called double). Hence the latter approach was chosen given its simplicity of implementing on plethora of end-points versus acceptable extra processing needed on relatively lower number of MD implementations. Some objections were raised in the working group, and re-raised during the first IETF LC, proposing that the encryption applied by PERC should be split so that in the WebRTC case, E2E keys could be supplied by someone other than the browser. It became clear in both WG discussions and post-LC discussions involving the ADs that this would be counter to the WebRTC security model, which is required in the PERC charter. So any work to address these concerns would be future work, and not blocking on the current documents. Document Quality libsrtp, a widely used SRTP library in commercial and open source SIP and Webrtc products, has a branch with the implementation for double encryption procedures as defined in this specification. This document did not require expert review of the types noted. Personnel The document shepherd is Suhas Nandakumar; the responsible Area Director is Alexey Melnikov. From nobody Fri Aug 30 15:07: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 9040E120077; Fri, 30 Aug 2019 15:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 aRua-Yw8Gd2F; Fri, 30 Aug 2019 15:07:35 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 B1E82120803; Fri, 30 Aug 2019 15:07:35 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7UM7S3W026395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Aug 2019 18:07:31 -0400 Date: Fri, 30 Aug 2019 17:07:27 -0500 From: Benjamin Kaduk To: Richard Barnes Cc: The IESG , perc-chairs@ietf.org, Suhas Nandakumar , perc@ietf.org, draft-ietf-perc-srtp-ekt-diet@ietf.org Message-ID: <20190830220727.GO84368@kduck.mit.edu> References: <156339433620.25783.14611652111059201524.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Perc] Benjamin Kaduk's Discuss on draft-ietf-perc-srtp-ekt-diet-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, 30 Aug 2019 22:07:39 -0000 Hi Richard, Sorry I effectively missed this when it came in, and needed reminding. On Fri, Aug 02, 2019 at 01:48:11PM -0500, Richard Barnes wrote: > On Wed, Jul 17, 2019 at 3:12 PM Benjamin Kaduk via Datatracker < > noreply@ietf.org> wrote: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-perc-srtp-ekt-diet-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-srtp-ekt-diet/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Thanks for the updates in the -10; we're making progress. I think there > > are still some issues left to resolve, though. > > > > My previous position had: > > > > """I think we need to discuss whether the mechanism described in Section > > 4.1 > > contains an EKT-specific extension mechanism or is in fact a more general > > mechanism for including extensions in SRTP packets outside the SRTP > > cryptographic protection. (If so, we would probably need to Update 3711 to > > indicate as much, and perhaps allow for multiple extension types to be > > present adjacently.) In particular, how would this EKT extension interact > > with any other future mechanism that needs to add data to SRTP packets > > outside the SRTP cryptographic wrapper?""" > > > > I think I remember having such a discussion, but cannot find any record of > > it. Does anyone have a pointer handy (or a corrective to my memory)? > > > > We may have had one in person, but I'm not seeing one in my email history > either. The short answer is that I don't think any generalization is > needed. > > The longer version is: RTP and SRTP packet formats are not intended to > self-describing. Instead, they rely heavily on external negotiation to > tell the endpoint how to parse the packet. For example, there is no > standard format for the RTP extension field; the format of the field (and > even the identifiers for individual extensions used therein) are negotiated > in SDP. > > In this context, that means that it's up to the application to make good > decisions about which extensions apply. Note that EKT is already > incompatible with the SRTP MKI mechanism (as noted in the document), as an > example of the types of incompatibilities that application need to navigate. I can accept that it's up to the application to make good decisions, but I think we can try to help the application make informed decisions. Based just on what's in the document right now, I can't really decide whether EKT needs all of the stuff between the end of SRTP and the end of UDP, or just needs to be at the absolute end, or needs to be identifiable based on cleartext framing [starting from the end], or something else. We note that EKT is incompatible with MKI because they offer largely the same functionality, not because their wire encodings are incompatible; I'd like to see some text that gives more explicit treatment of the ways in which this extension behaves that are at risk of being incompatible with other common extension patterns. (I'm not quite sure yet whether I'd insist on such text in the document, though, and am open to further discussion.) > > > > Similarly, I don't remember any discussion on: > > > > """I also think we need to discuss whether it is appropriate to set a > > precedent that any standards-track protocol can get a dedicated TLS > > HandshakeType (noting that this is a potentially scarce one-octet field. > > Would it be more appropriate to define a generic "key transport" container > > that can be generally applicable to many protocols, and have an internal > > extension point that allows for an SRTP+EKT-specific usage within the TLS > > HandshakeType?""" > > > > We are also still waiting on IANA, if I understand correctly. I do not see > > any indication that the needed expert review for TLS ExtensionType > > allocation has been requested (the authors should initiate this, per RFC > > 8447), and there may have been other matters that needed clarification. > > > > On the HandshakeType: The authors had a fairly extensive (but unfortunately > off-list) discussion with EKR about how to transmit the EKT key. After > evaluating the full range of options -- from EncryptedExtensions all the > way to the application layer -- the conclusion of that discussion was that > a HandshakeType fit best with the requirements here. I'm not sure I > understand your worry about the scarcity of HandshakeType values. "Any > standards-track protocol" is basically the highest bar we have; what more > would you ask? Practically speaking, we are defining new HandshakeType > values at a high enough rate that we seem likely to exhaust the pool. My comment about "any standards-track protocol" was trying to indicate that there's not a strict hierarchy of what bar we apply to registrations -- effectively, the IETF-wide review that we want for standards-track documents does not encompass everyone at the IETF for all documents, and there may be case where some reviews (e.g., those of the registry's DEs) may be particularly important to solicit. That said, we've definitely had some high-powered TLS Experts thinking hard about this issue, so it's not clear how much real benefit there'd be to adding delay to do a formal call for review on the TLS WG. (Though it would have been nice if we could have done that in parallel at an earlier stage of the document's lifecycle.) I did get a chance to think harder about the range of options, and don't have a fundamental objection to using a TLS handshake type to carry EKTKeys, since in the RFC 5764/7983 world we're in some sense treating DTLS and SRTP as a single combined protocol, with DTLS providing key material for the SRTP "application data" (among other things) -- in that mindset we are naturally using a DTLS handshake message to provide cryptographic input to the other protocol layer, which is exactly what the handshake protocol is for! That said, I do have a new(?) concern about this document, since it refers to the "Ack handshake message as described in Section 7 of [I-D.ietf-tls-dtls13]"; chasing the reference, we find that Ack is a new content-type, not a handshake type, to avoid having to include them in the transcript. There is not a fundamental reason why the Ack being a dedicated content-type means that the EKTkey being ack'd should be a dedicated content-type, too, though -- after all, the original purpose of the ack is to acknowledge ... handshake records. > On the ExtensionType: Thanks for calling that out; I have sent a request to > the mailing list. Is there a reason that IANA doesn't send those emails, > like they do with other approvals from designated experts? And it only got one expert to reply; I guess I should try to ping that thread. I think we are still figuring out what the best workflow for this sort of thing is, and were definitely lacking on specific guidance/procedures in the document that established the registry/list. But, I believe the intent for doing it this way is that the requestor can engage directly with the experts, and the requestor is presumed to have a better understanding of what exactly they need than the fine folks at IANA do. That is, this way IANA doesn't have to keep relaying messages back and forth, if there is any clarification needed. Thanks, Ben