From nobody Thu Aug 5 14:31:03 2021 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 789893A0B9C; Thu, 5 Aug 2021 14:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pd9p1Eft83tf; Thu, 5 Aug 2021 14:30:41 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B663A0AF9; Thu, 5 Aug 2021 14:30:20 -0700 (PDT) Received: from authuser (localhost [127.0.0.1]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1628199012; bh=+MAEPIpQBplYI0ej6uFyRrHtlFjQ1hF7kWqFxMoDseo=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=EYIBAds6STxEnPmzRkzcsonkbrN8SvVJ4H7XacckV+coyj5bygpsdIGUfSyUTrVUk yT4J6XlsK9JzsWklJ24GrEwdl7AC7qg8E0PF1rvPFtqldMdbDdNtrBYWVdxneya6e4 CcJF0TfcR+MO7RAeTjLPH5YL2mqW3YaAY02cnZvo= From: "Paul E. Jones" To: =?utf-8?q?=c3=89ric=20Vyncke?= , "The IESG" Cc: draft-ietf-perc-dtls-tunnel@ietf.org, perc-chairs@ietf.org, perc@ietf.org, suhasietf@gmail.com, suhasietf@gmail.com Date: Thu, 05 Aug 2021 21:30:09 +0000 Message-Id: In-Reply-To: <162506995115.9936.13343964913929243021@ietfa.amsl.com> References: <162506995115.9936.13343964913929243021@ietfa.amsl.com> Reply-To: "Paul E. Jones" User-Agent: eM_Client/8.2.1473.0 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Perc] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-perc-dtls-tunnel-09=3A_=28with_COMMENT=29?= X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 21:30:55 -0000 Eric, >=3D=3D COMMENTS =3D=3D > >I was about to raise a DISCUSS on this but I am trusting the security AD o= n >this topic. But, I really wonder why TLS 1.2 is used rather than TLS 1.3. > >There is no operational consideration around the resiliency of the Key >Distributor (load balancing, fail-over, etc.). Should there be some operat= ional >considerations ? DTLS 1.2 was referenced since it is the current RFC. However, it=20 doesn't really matter that it's 1.2 or 1.3, modulo the order of message=20 issue that Benjamin noted about message order. That said, there really=20 is no need to have that strict language, so I'll change it. >-- Abstract -- >While I agree that this document could be informational, why does the abst= ract >use words like "defines" "the protocol is designed" as those words are mor= e >normative than descriptive. Strongly suggest to rephrase the abstract. The document does define a protocol that is designed for a specific=20 purpose. If I change that wording, it doesn't change that fact. >-- Section 1 -- >Knowledgeable people will understand the E2E and HBH concepts but a figure >would be welcome for beginners (really just a suggestion). While you're right, this protocol is intended to be implemented as a=20 part of RFC 8871. I do not want to redefine anything or introduce=20 language that might appear to conflict that RFC. >Later and in the same vein "simply forwarding packets" for me (INT AD) pac= kets >are layer-3 and it is really unclear in the introduction what is actually >forwarded. I.e., 'packets' should be qualified, perhaps in "DTLS messages" = or >using the same vocabulary of section 5.3 ? I agree with the "DTLS messages" suggestion and removed "simply". I'll=20 try to improve the wording here. >-- Section 2 -- >As usual, I am not comfortable when an informational document relies on BC= P 14, >which should (IMHO) be reserved for BCP/standards track documents. Just a >comment, feel free to ignore. I try to not ignore anything, albeit I'm very late getting around to=20 responding, for which I can only apologize to you and the others; I've=20 been rather busy. This document was originally intended to be standards track and it=20 defines one possible way of filling the void left by RFC 8871. That RFC=20 describes a tunnel between the MD and KD. This document represents one=20 way to do it, but other approaches could be implemented. Maybe=20 experimental is a better classification? I'm still open to this being=20 Standards Track as it was originally intended :) >-- Section 5.2 -- >"which tunnel or tunnels to use to send messages for a given conference is >outside the scope of this document." is really a lot of hand waving as I w= onder >how the document could be used without knowing which tunnels is to be used= . I wanted to make it clear that the MD may create a plurality of tunnels=20 to different physical KDs in order to improve resiliency and=20 performance. The concern with going into any detail here is that I do=20 not want to prescribe how traffic might be load balanced or what=20 resiliency mechanisms might be employed. Those things are=20 implementation detail that is outside the scope the document. I could=20 just remove the entire paragraph, as I think that's the only place where=20 it talks about the possibility of more than one tunnel, but then more=20 questions would be raised about resiliency, I think. >=3D=3D NITS =3D=3D > >There are several occurrences of "an message"... probably a replace all, w= hich >went wrong ;-) I do not see those. Maybe I'm overlooking them? Can you point them=20 out? >-- Section 1 -- >s/on behalf of the endpoint/on behalf of the endpointS/ ? Endpoints is good, but I'll remove "the". The rest of the paragraph is=20 intended to describe the interaction between an endpoint and KD, so at=20 least one other article should change. I do that; hopefully it reads=20 better. Paul From nobody Thu Aug 5 15:05:03 2021 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 EEDF03A0C7E; Thu, 5 Aug 2021 15:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJOWPRanpHAO; Thu, 5 Aug 2021 15:04:57 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 387BF3A0C57; Thu, 5 Aug 2021 15:04:57 -0700 (PDT) Received: from authuser (localhost [127.0.0.1]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1628201087; bh=vk3bjR8/V4MCyd/s5l3rxHIuyZfyODws0Y/ABRtgahQ=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=hUJN7A0q3qu61En4evp36/dwgDddDGiEz+bYn/DWYK/zP9012w88GcSnh10ltIyDL UXKXGO+HghQIfB6Wba7guqJVhkv2TZm0cYa5j293CZjYyNDEjFZnfPF7hPNT8I3hVg cOz5YyR4+zal0zFXn7XPCiMVaOZRY/EQEiAODgj0= From: "Paul E. Jones" To: "Roman Danyliw" , "The IESG" Cc: draft-ietf-perc-dtls-tunnel@ietf.org, perc-chairs@ietf.org, perc@ietf.org, suhasietf@gmail.com, suhasietf@gmail.com Date: Thu, 05 Aug 2021 22:04:41 +0000 Message-Id: In-Reply-To: <162508387766.24113.5015964775533185016@ietfa.amsl.com> References: <162508387766.24113.5015964775533185016@ietfa.amsl.com> Reply-To: "Paul E. Jones" User-Agent: eM_Client/8.2.1473.0 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Perc] Roman Danyliw's No Objection on draft-ietf-perc-dtls-tunnel-09: (with COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2021 22:05:02 -0000 Roman, >Thank you to Shawn Emery for the SECDIR review, and to Russ Housley for th= e >security related feedback in the GENART review. > >** Section 5.4. > The Key Distributor MUST match the certificate fingerprint and > "external_session_id" received from endpoint's "ClientHello" message > with the values received from the SDP transmitted by the endpoint. > >Consider adding a reference to RFC8122 to point to the guidance on the SDP >fingerprint attribute. Will add. >** On the topic of relying on the RFC8122 defined hashes, Section 5 allows = for >the possibility of SHA-1 which is now past its prime. The text there alre= ady >says =E2=80=9CImplementations compliant with this specification MUST NOT u= se the MD2 >and MD5 hash functions to calculate fingerprints or to verify received >fingerprints that have been calculated using them.=E2=80=9D Likewise, Sec= tion 5.1 also >notes the requirement of at least one of the hashes being SHA-256. Consid= er >saying sometime along the lines of =E2=80=9CImplementations using this tun= neling >approach SHOULD NOT use SHA-1 hash functions to calculate or verify >fingerprints =E2=80=A6=E2=80=9D While you're correct that SHA-1 is aging, I would prefer that this=20 document not overrule RFC 8122. Maybe we should update 8122? The=20 reality is, though, SHA-1 is still used. It's also still widely used in=20 SRTP deployments. Paul From nobody Thu Aug 5 18:17:58 2021 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 C0C2A3A1566; Thu, 5 Aug 2021 18:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z52-Y9M0L-5f; Thu, 5 Aug 2021 18:17:46 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877143A1563; Thu, 5 Aug 2021 18:17:46 -0700 (PDT) Received: from authuser (localhost [127.0.0.1]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1628212660; bh=lXdojjSY5G0KGz+1PmJ5XtiBYILP0yhtPZ1+ryqkzyk=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=Fd2U3lpzOvLA92yurP4eOKlxBN5atm5Z5xZ8qffv8DxgVucgBypM1N3Ud97sakeBC glAzOL11unlG4PbbV/4UMPbuepx8ZbVd5+8SftXGElrq5NWfDp9gmxtHTSuBJJPouJ eM68zbiS/89jx49szR4XqQ1f45O9aXBqqOaVrwQw= From: "Paul E. Jones" To: "Benjamin Kaduk" , "The IESG" Cc: draft-ietf-perc-dtls-tunnel@ietf.org, perc-chairs@ietf.org, perc@ietf.org, suhasietf@gmail.com, suhasietf@gmail.com Date: Fri, 06 Aug 2021 01:17:35 +0000 Message-Id: In-Reply-To: <162510321507.13724.12968550804927630403@ietfa.amsl.com> References: <162510321507.13724.12968550804927630403@ietfa.amsl.com> Reply-To: "Paul E. Jones" User-Agent: eM_Client/8.2.1473.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBD73DD5F9-8EAA-4CF4-95C4-21894D7A6B7B" Archived-At: Subject: Re: [Perc] Benjamin Kaduk's Discuss on draft-ietf-perc-dtls-tunnel-09: (with DISCUSS and COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2021 01:17:52 -0000 --------=_MBD73DD5F9-8EAA-4CF4-95C4-21894D7A6B7B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Benjamin, >(1) I want to check on the DTLS version compatibility of this protocol. I= f >there is a DTLS version dependency, as I suspect, then we need to >document it more clearly or remove it. > >In particular, the current specification has the Key Distributor sending >the MediaKeys message before it sends the DTLS (server) Finished >message (=C2=A75.4), which requires that the HBH keys are available at tha= t >point. While the TLS exporter interface used by RFC 5764 to output keys >is an interface that DTLS 1.3 also supports, that may not be the whole >story. In particular, in (D)TLS 1.3 the order of client and server >Finished messages is reversed, so that the server Finished is sent >before the client has authenticated. When combined with the fact that >the TLS 1.3 exporter interface does not incorporate the transcript hash >of the client's authentication messages, this seems to imply that the >key distributor would be releasing HBH keys prior to the client's >authentication and prior to the completion of the DTLS 1.3 handshake. >The behavior of the TLS 1.3 exporter was considered safe for regular >TLS+TCP since the server will abort the connection and not pass any >application data if the client's Finished or authentication is invalid, >but it poses problems for applications that use only the TLS handshake >and do not use the TLS record protection to cover application data. >(EAP-TLS is a notable recent example where the protocol had to be >modified in order to be secure when used with TLS 1.3.) DTLS-SRTP is >also an application that uses only the (D)TLS handshake, and I am >worried that releasing HBH keys prior to authenticating the client will >also prove problematic in this situation. There was no intention to rely on a particular version of DTLS. This=20 exists only because that's how it worked oh-so-many-years-ago when this=20 document was originally written. :) I removed the language about the Finished message. The desire was only=20 to ensure the KD provides the MD with media keys before is replies to=20 the endpoint. That's only so that the MD can be prepared for the first=20 media packet to arrive. However, if the keys arrive late, it's not the=20 end of the world. I think changing the language to this will suffice: "The Key Distributor **MUST** send a `MediaKeys` message to the Media Distributor as soon as a HBH encryption key is computed." This still expresses urgency, but removes the dependency on the Finished=20 message. There are other messages mentioned in that section (namely ClientHello=20 and ServerHello). Those appear to still be valid statement, but please=20 correct me if I'm wrong. I could remove the references to messages, but=20 I find that useful (when it's correct). >(2) I'll also mention here so that the IESG can talk about it during our >telechat (but with no intent to insist on a change): this document >specifies a versioned protocol and creates a registry. Are we happy >with the current Informational status, as opposed to Proposed Standard? >I do see that the topic was touched on in the shepherd writeup, but the >treatment there did not feel especially compelling to me. Hopefully that got resolved. I'll await instructions on any requested=20 changes here. >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >I have a few general remarks before diving into the section-by-section >commentary (with nits split off into a final section). > >It seems like one of the key security-relevant aspects of this setup is >how the information in (unauthenticated) incoming DTLS messages at the >key distributor are mapped up to the existing (or in the process of >establishment?) SDP sessions that describe the expected DTLS >session construction (and the media to be carried over DTLS-SRTP). It >seems that in the general case, a given Key Distributor will be engaged >in many active and pending sessions, and thus will need to be able to >look up across many clients and sessions which SDP state might be a >match for a given DTLS ClientHello, while avoiding DoS attacks and not >committing any given SDP session to a DTLS association prior to the >completion of the DTLS handshake. My preference would be to see a lot >more discussion in the document about this type of considerations, >though for an Informational protocol I won't insist on it (this is a >non-blocking comment). With or without this protocol, that's a valid concern. Many=20 architectures divorce the SDP processing from media processing and have=20 for a very long time (e.g., MEGACO / RFC 3015 and SIGTRAN / RFC 2719 /=20 RFC 4960). That said, I will add a paragraph to the security=20 considerations section highlighting this issue; I just cannot offer a=20 mitigation since that's well beyond the scope of this document. How about this addition: "While the Security Considerations section of [@RFC8871] describes=20 various attacks one needs to consider with respect to the Key Distributor and denial-of-service, use of this protocol introduces another possible attack vector. Consider the case where a rogue sends unsolicited=20 DTLS-SRTP messages to a Media Distributor. The Media Distributor will normally=20 forward those messages to the Key Distributor and, if found invalid, such=20 messages only serve to consume resources on both the Media Distributor and Key Distributor." >With the media distributor acting as an intermediary that is partially >trusted, the situation is more complicated than usual, and the key >distributor cannot use transport coordinates to identify DTLS >associations, and instead the only index available is the UUID assigned >by the media distributor. To some extent we rely on the media >distributor to properly map DTLS packets to the UUID identifier, but >AFAICT if the media distributor fails to do so, the DTLS cryptographic >mechanisms will detect such errors and either abort the handshake or >(post-handshake) reject invalid messages. It might be worth reiterating >that DTLS does provide this form of protection. DTLS will serve to identify an invalid endpoint, but I think that's=20 already clear from the fact that the KD is required to authenticate the=20 endpoint. I'm not sure what I should add where, but if you can suggest a=20 specific addition, I'm happy to add it. >Since the UUID is the only index that the key distributor has for DTLS >associations, there does not seem to be any risk of having the media >distributor trick the key distributor into releasing HBH keys from the >"wrong" association -- keys should only be released if the DTLS >handshake will complete successfully (but see the Discuss point #1!), >and the completion of the handshake authenticates the overall exchange >so that it's safe to release keys via the channel that identifies the >handshake (i.e., the UUID). There does seem to only be very >coarsed-grained "trusted or not" authorization for media servers to >receive keys at all, though -- a malicious-but-trusted media distributor >that had on-path access for some other DTLS flows could relay them to >the key distributor and have the DTLS handshake succeed along that path, >even if it was not the intended path, and would get the HBH keys as a >result. The HBH key are unique per endpoint, so having the HBH keys for Endpoint=20 1 is useless with respect to Endpoint 2. The PERC Framework (RFC 8871)=20 describes a number of bad things the MD can do. It's really only=20 trusted insofar as to relay media. >Does it only make sense to use this tunneling protocol with a "DOUBLE" >DTLS-SRTP profile? If so, that might be worth mentioning somewhere more >explicitly. This protocol is not dependent on DOUBLE, though the PERC system=20 prescribes its use by endpoints. Implementers of this protocol really=20 do not need to know how the HBH keys are created. As such, I'd prefer=20 to not introduce that here. For the purposes of this protocol,=20 implementers only need to know that there is a message containing HBH=20 keys that comes from the KD. >Section 3 > > The Key Distributor is a logical function that might be co-resident > with a key management server operated by an enterprise, reside in one > of the endpoints participating in the conference, or elsewhere that > is trusted with E2E keying material. > >Do we want to say something about the Key Distributor acting at a higher >level of trust than the Media Distributor? (Is that even always true?) Per the PERC Framework (RFC 8871), the KD is a trusted entity. >Section 4 > >Figure 2 seems to show the MediaKeys being delivered to the Media >Distributor after only a single message from the Endpoint (i.e., prior >to the completion of the DTLS handshake). I don't think that is >accurate, and it seems like that arrow should be moved later in the time >sequence. The problem is when there are a plurality of ways to do the DTLS setup,=20 it means there are a plurality of places where that MediaKeys message=20 might go. I am confused about one point: why would the KD not be able=20 to verify the endpoint on the initial DTLS message? If it can, then it=20 seems like this would still be a valid exchange. If it cannot, then=20 what would be the alternative flow? And do we really want to enumerate=20 several? I am happy to add whatever clarification we need, but would=20 prefer to not to show several exchanges (that might be different in DTLS=20 1.4). >Section 5.4 > > When processing an incoming endpoint association, the Key Distributor > MUST extract the "external_session_id" value transmitted in the > "ClientHello" message and match that against "tls-id" value the > endpoint transmitted via SDP. If the values in SDP and the > "ClientHello" do not match, the DTLS association MUST be rejected. > >The Key Distributor might have multiple pending associations, and >potentially only weak bindings to endpoint identities prior to DTLS >establishment, so it's not clear that "match [external_session_id] >against 'tls-id' value the endpoint transmitted via SDP" is entirely >accurate. I'm implicitly inserting a "the" before "tls-id" to make it >parse, but the implicit "the" is not a good fit since the definite >article implies there is a single one identified but there may be >multiple pending associations. AFAICT at this point in processing the >only real identifier that the key distributor has for the pending DTLS >association is the UUID from the media distributor and there is no tight >association betwen that identifier and the "tld-id" value that (per the >following paragraph) is conveyed to the key distributor in some >unspecified manner. The UUID is introduced in this protocol only to facilitate routing=20 messages to the right endpoint. "The" should have been in that sentence. The KD will have the tls-id values advertised in SDP from the endpoint. =20 How that happens is deliberately not specified, as there was no effort=20 (or desire, I think) to define the mechanism of getting those values=20 from the endpoint to the KD. There might be a quasi-trusted SIP UA that=20 hands the info to the KD, or it might be an entirely proprietary=20 WebRTC-based server that delivers that information to the KD. The WG=20 did not want to nail that down. In any case, the assumption is that the=20 KD will have these values. So when the DTLS message arrives, it should=20 be able to match the DTLS sessions with media lines in the SDP. Perhaps we need a statement stating the KD receives the tls-id via some=20 unspecified means? Or am I missing the issue entirely? > The Key Distributor MUST match the certificate fingerprint and > "external_session_id" received from endpoint's "ClientHello" message > with the values received from the SDP transmitted by the endpoint. > >This sentence is rather confusing to me, since I don't know of a >certificate fingerprint conveyed in the ClientHello itself (as opposed >to the fingerprint of the certificate contained in the Certificate >message presented during the handshake). This refers to the fingerprint of the certificate. I didn't create that=20 language. RFC 4572: "It provides for endpoints to include a secure hash of their certificate, known as the "certificate fingerprint", within the session description." I'll add a reference to that RFC since it is a dependency. > It is through this process that the Key Distributor can be sure to > deliver the correct conference key to the endpoint. > >Do we need to say anything about how the Key Distributor gets the >fingerprint and external_session_id values from SDP? (I mean, I assume >that it's the same way that it gets the "tls-id", but the previous >paragraph just talked about "tls-id" and not the other stuff, so >formally it's ambiguous.) The "external_session_id" comes via DTLS. The "tls-id" comes via SDP. =20 It is a little confusing, but as I noted above, the WG did not want to=20 prescribe how the KD go the tls-id value. > When sending the "ServerHello" message, the Key Distributor MUST > insert its own unique identifier in the "external_session_id" > extension. This value MUST also be conveyed back to the client via > SDP as a "tls-id" attribute. > >It's not really clear that the binding between the endpoint that is >supposedly presenting the DTLS data and the SDP data has been >established at all here, so the selection of what "tls-id" to use here >feels rather speculative. I think we should discuss the security >considerations for what is leaked if the key distributor sends the >"wrong" values here... Yeah, same issues as above. We do not have a protocol that defines how=20 this exchange happens with the KD. >I'm also not sure if the sequencing of events is properly described >here. Does the SDP need to complete before the DTLS handshake begins, >or can they proceed in parallel as described here? SDP has to be exchanged first, as otherwise the endpoint would not know=20 where to send the DTLS message. (And then there's potentially ICE=20 before DTLS, but let's not go there.) >Section 6 > > Tunnel > messages are specified using the format described in [RFC5246] > section 4. [...] > >I think that =C2=A73 of RFC 8446 is probably a better reference for TLS >presentation language at this point. OK, I changed that. Now DTLS? I'm still referencing DTLS1.2. I'll add=20 a note for the RFC editor to consider updating those references, unless=20 you'd suggest I change it to reference the IETF draft. >Section 6.5 > >I'm not sure what purpose sending an empty dtls_message would serve. > > * "dtls_message": the content of the DTLS message received by the > endpoint or to be sent to the endpoint. > >I recommend saying something about "including record-layer framing" to >reiterate where the boundary is. I need help with that language. In my mind, it was whatever was in the=20 UDP payload, but I'm happy to write something more prescriptive. I just=20 do not know what to write. >Section 9 > >I strongly recommend upgrading the TLS version between media distributor >and key distributor to be TLS 1.3. Whether or not to use DTLS 1.2 or >1.3 for the tunneled traffic between endpoint and key distributor is an >orthogonal topic. I think I've updated all references to 1.3 now in my local copy. >I'd also reiterate that the media distributor has access to metadata >about the endpoint/key distributor communications, even though the main >content and key information is encrypted. What metadata, exactly? With or without this protocol, I think what=20 you're saying would be true and it would likely be more suited for the=20 Framework (that's already an RFC). I'm happy to add something here, but=20 I'm not sure what. >I'd also consider calling out that the media distributor could generate >false EndpointDisconnect messages, but that this is essentially the same >capability afforded by just not forwarding media anymore. Yeah, it could. The MD is definitely in a position to break things. =20 I'll note this possibility. > A requirement in this document is that a TLS connection between the > Media Distributor and the Key Distributor be mutually authenticated. > The reason for this requirement is to ensure that only an authorized > Media Distributor receives the HBH keying material. [...] > >Can we say anything about what the Key Distributor's authorization >policy might be, using the authenticated identity of the TLS peer as >input? "Any authenticated identity is granted all access" is not a >great authorization policy :) The only thing possible here are messages sent over the tunnel that's=20 established. the scope is limited to just this protocol. >NITS > >Abstract > > This document defines a DTLS tunneling protocol for use in multimedia > >I think the hyphenated "DTLS-tunneling" would clarify that DTLS is being >tunneled (as opposed to the mechanism used to tunnel other things). >A slightly more intrusive change would be "protocol for tunneling DTLS >traffic" but that might be confusing in the terse setting of the >Abstract. I like the more verbose form, actually. I do this (until you tell me to=20 change it): "This document defines a protocol for tunneling DTLS traffic in=20 multimedia conferences that enables a Media Distributor to..." >Section 1 > > By establishing this TLS tunnel between the Media Distributor and Key > Distributor and implementing the protocol defined in this document, > it is possible for the Media Distributor to facilitate the > establishment of a secure DTLS association between an endpoint and > the Key Distributor in order for the endpoint to receive E2E and HBH > keying material. [...] > >I think "receive" might not be the best word here, since the key >material should incorporate contributions from both parties; the "arrive >at" language used in the previous paragraph was good. How about "compute" or "generate"? The endpoint does, in fact, generate=20 the keys. You're right that it doesn't just receive them. > > >Section 4 > > As DTLS messages are received from the endpoint by the Media > Distributor, they are forwarded to the Key Distributor encapsulated > inside a "TunneledDtls" message. Likewise, as "TunneledDtls" > messages are received by the Media Distributor from the Mey > Distributor, the encapsulated DTLS packet is forwarded to the > endpoint. > >s/Mey/Key/ Got it! >Section 5.1 > > The endpoint MUST include a unique identifier in the "tls-id" SDP > [RFC4566] attribute sent by the endpoint in both offer and answer > [RFC3264] messages as per [RFC8842]. Further, the endpoint MUST > include this same unique identifier in the "external_session_id" > extension [RFC8844] in the "ClientHello" message when establishing a > DTLS association. > >Since this is the section about the endpoint procedures (the key >distributor's behavior is discussed later), I think we might avoid >phrasing that implies a linked offer/answer pair, and instead say >something like "in all offer and answer messages that it generates". OK, changed it. >Section 5.4 > > The Key Distributor MUST encapsulate any DTLS message it sends to an > endpoint inside a "TunneledDtls" message (see Section 6). The Key > Distributor is not required to transmit all messages a given DTLS > association through the same tunnel if more than one tunnel has been > established between it and a Media Distributor. > >I suggest "a given Media Distributor", since the current phrasing seems >to allow sending to a different media distributor entirely, which seems >unlikely to work since the UUID identifying the DTLS association will >not be recognized there. I suggest this, but feel free to suggest something else: "The Key Distributor is not required to transmit all messages for a given DTLS association through the same tunnel if=20 more than one tunnel has been established between it and the Media=20 Distributor." There might be n tunnels between the KD and MD, but the messages MUST=20 be sent to the solitary MD that is communicating with the endpoint. If=20 the KD just sends those messages out any tunnel, that's not going to=20 work. It has to be a tunnel to a specific MD. > The Key Distributor MUST select a cipher that is supported by both > the endpoint and the Media Distributor to ensure proper HBH > operations. > >(It also has to pick a cipher that it itself supports...) Indeed. I'll change that. >Section 5.5 > > "UnsupportedVersion". The Media Distributor can determine from the > first two octets received what the version number is and that the > message is "UnsupportedVersion". The rest of the data received, if > >I think that the "two" should be either "one" or "four", as the actual >message structure has two octets of length between the message type and >the unsupported_version structure. One octet is needed to determine >that it is an unsupported-version message, and four to determine the >highest supported version number. Indeed. I changed it to 4. >Section 6.2 > > struct { > uint8 version; > SRTPProtectionProfile protection_profiles<0..2^16-1>; > } SupportedProfiles; > >The presentation language allows an empty list of profiles; is that >intended to be allowed? (What happens if an empty list is sent?) That's an error. This should be at least two octets in length. I'll=20 change it to 2..2^16-1. The call will fail if nothing is offered. The=20 call might fail if something is offered, but offering something gives a=20 fighting chance :) This should align with RFC 5764. I believe it does. This should just be=20 a vector of two-octet values. > * "version": indicates the version of the protocol to use (0x00). > >I suggest "this document specifies version 0x00" rather than the >parenthetical. Changed it as you suggest. Paul --------=_MBD73DD5F9-8EAA-4CF4-95C4-21894D7A6B7B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Benja= min,

(1) I want to check= on the DTLS version compatibility of this protocol. If
there is a DTLS version dependency, as I suspect, = then we need to
document it more clearly or remove it.
=C2=A0
In particular, the current specification has the= Key Distributor sending
the MediaKeys message before it sends the DTLS (s= erver) Finished
message (=C2=A75.4), which requires that the HBH= keys are available at that
point. While the TLS exporter interface used by= RFC 5764 to output keys
is an interface that DTLS 1.3 also supports, that = may not be the whole
story. In particular, in (D)TLS 1.3 the order of = client and server
Finished messages is reversed, so that the server = Finished is sent
before the client has authenticated. When combin= ed with the fact that
the TLS 1.3 exporter interface does not incorpora= te the transcript hash
of the client's authentication messages, this see= ms to imply that the
key distributor would be releasing HBH keys prior = to the client's
authentication and prior to the completion of the = DTLS 1.3 handshake.
The behavior of the TLS 1.3 exporter was consider= ed safe for regular
TLS+TCP since the server will abort the connectio= n and not pass any
application data if the client's Finished or auth= entication is invalid,
but it poses problems for applications that use o= nly the TLS handshake
and do not use the TLS record protection to cover = application data.
(EAP-TLS is a notable recent example where the pr= otocol had to be
modified in order to be secure when used with TLS = 1.3.) DTLS-SRTP is
also an application that uses only the (D)TLS han= dshake, and I am
worried that releasing HBH keys prior to authenti= cating the client will
also prove problematic in this situation.

There was no intention to rely on a particular ver= sion of DTLS.=C2=A0 This exists only because that's how it worked oh-so-man= y-years-ago when this document was originally written. :)

I removed the language about the Finished message.=C2=A0 The desir= e was only to ensure the KD provides the MD with media keys before is repli= es to the endpoint.=C2=A0 That's only so that the MD can be prepared for th= e first media packet to arrive.=C2=A0 However, if the keys arrive late, it'= s not the end of the world.=C2=A0 I think changing the language to this wil= l suffice:

"The Key Distributor **MUST** send a `MediaK= eys` message to the Media
Distributor as soon as a HBH encry= ption key is computed."
This still expresses urge= ncy, but removes the dependency on the Finished message.

There are other messages mentioned in that section (namely ClientHe= llo and ServerHello).=C2=A0 Those appear to still be valid statement, but p= lease correct me if I'm wrong. I could remove the references to messages, b= ut I find that useful (when it's correct).


(2) I'll also= mention here so that the IESG can talk about it during our
telechat (but with no intent to insist on a chang= e): this document
specifies a versioned protocol and creates a regi= stry. Are we happy
with the current Informational status, as opposed = to Proposed Standard?
I do see that the topic was touched on in the she= pherd writeup, but the
treatment there did not feel especially compellin= g to me.

=
Hopefully that got resolved.=C2=A0 = I'll await instructions on any requested changes here.


-----------------------= -----------------------------------------------
COMMENT:
-------------------------------------------------= ---------------------
=C2=A0
I have a few general remarks before diving into t= he section-by-section
commentary (with nits split off into a final sect= ion).
=C2=A0
It seems like one of the key security-relevant as= pects of this setup is
how the information in (unauthenticated) incoming = DTLS messages at the
key distributor are mapped up to the existing (or = in the process of
establishment?) SDP sessions that describe the ex= pected DTLS
session construction (and the media to be carried = over DTLS-SRTP). It
seems that in the general case, a given Key Distr= ibutor will be engaged
in many active and pending sessions, and thus wil= l need to be able to
look up across many clients and sessions which SD= P state might be a
match for a given DTLS ClientHello, while avoidin= g DoS attacks and not
committing any given SDP session to a DTLS associ= ation prior to the
completion of the DTLS handshake. My preference= would be to see a lot
more discussion in the document about this type o= f considerations,
though for an Informational protocol I won't insi= st on it (this is a
non-blocking comment).

With or without this protocol, that's a valid concern.=C2=A0 Many ar= chitectures divorce the SDP processing from media processing and have for a = very long time (e.g., MEGACO / RFC 3015 and SIGTRAN / RFC 2719 / RFC 4960)= .=C2=A0 That said, I will add a paragraph to the security considerations se= ction highlighting this issue; I just cannot offer a mitigation since that'= s well beyond the scope of this document.

How abo= ut this addition:

"While the Security Considerati= ons section of [@RFC8871] describes various
attacks one needs to consid= er with respect to the Key Distributor and
denial-of-service, use of t= his protocol introduces another possible
attack vector.=C2=A0 Consid= er the case where a rogue sends unsolicited DTLS-SRTP
messages to a Media Distrib= utor.=C2=A0 The Media Distributor will normally forward
those messages to the Key D= istributor and, if found invalid, such messages
only serve to consume resou= rces on both the Media Distributor and
Key Distributor."


With the media distributor acting as an intermediary= that is partially
trusted, the situation is more complicated than u= sual, and the key
distributor cannot use transport coordinates to i= dentify DTLS
associations, and instead the only index availabl= e is the UUID assigned
by the media distributor. To some extent we rely = on the media
distributor to properly map DTLS packets to the U= UID identifier, but
AFAICT if the media distributor fails to do so, t= he DTLS cryptographic
mechanisms will detect such errors and either abo= rt the handshake or
(post-handshake) reject invalid messages. It mig= ht be worth reiterating
that DTLS does provide this form of protection.

DTLS will serve to identify an invalid endpo= int, but I think that's already clear from the fact that the KD is required = to authenticate the endpoint. I'm not sure what I should add where, but if = you can suggest a specific addition, I'm happy to add it.


Since the UUID is the only index that the key distributor ha= s for DTLS
associations, there does not seem to be any risk= of having the media
distributor trick the key distributor into releas= ing HBH keys from the
"wrong" association -- keys should only be releas= ed if the DTLS
handshake will complete successfully (but see the = Discuss point #1!),
and the completion of the handshake authenticates = the overall exchange
so that it's safe to release keys via the channel = that identifies the
handshake (i.e., the UUID). There does seem to o= nly be very
coarsed-grained "trusted or not" authorization fo= r media servers to
receive keys at all, though -- a malicious-but-tr= usted media distributor
that had on-path access for some other DTLS flows = could relay them to
the key distributor and have the DTLS handshake s= ucceed along that path,
even if it was not the intended path, and would g= et the HBH keys as a
result.

The HBH key are = unique per endpoint, so having the HBH keys for Endpoint 1 is useless with = respect to Endpoint 2.=C2=A0 The PERC Framework (RFC 8871) describes a num= ber of bad things the MD can do.=C2=A0 It's really only trusted insofar as= to relay media.

=

Does it only make sense to use this = tunneling protocol with a "DOUBLE"
DTLS-SRTP profile? If so, that might be worth me= ntioning somewhere more
explicitly.

This= protocol is not dependent on DOUBLE, though the PERC system prescribes its= use by endpoints.=C2=A0 Implementers of this protocol really do not need to = know how the HBH keys are created.=C2=A0 As such, I'd prefer to not introd= uce that here.=C2=A0 For the purposes of this protocol, implementers only n= eed to know that there is a message containing HBH keys that comes from the = KD.

Section 3
=C2=A0
The Key Distributor is a logical function that = might be co-resident
with a key management server operated by an en= terprise, reside in one
of the endpoints participating in the conferen= ce, or elsewhere that
is trusted with E2E keying material.
=C2=A0
Do we want to say something about the Key Distrib= utor acting at a higher
level of trust than the Media Distributor? (Is t= hat even always true?)

Per the PERC Framework (RF= C 8871), the KD is a trusted entity.


Section 4
=C2=A0
Figure 2 seems to show the MediaKeys being delive= red to the Media
Distributor after only a single message from the= Endpoint (i.e., prior
to the completion of the DTLS handshake). I don'= t think that is
accurate, and it seems like that arrow should be= moved later in the time
sequence.

The problem is when there= are a plurality of ways to do the DTLS setup, it means there are a pluralit= y of places where that MediaKeys message might go.=C2=A0=C2=A0I am confused about one point: why would the KD not b= e able to verify the endpoint on the initial DTLS message?=C2=A0 If it can, = then it seems like this would still be a valid exchange.=C2=A0 If it canno= t, then what would be the alternative flow? And do we really want to enumer= ate several?=C2=A0 I am happy to add whatever clarification we need, but wo= uld prefer to not to show several exchanges (that might be different in DTL= S 1.4).


Section 5.4
=C2=A0
When processing an incoming endpoint associati= on, the Key Distributor
MUST extract the "external_session_id" value t= ransmitted in the
"ClientHello" message and match that against "= tls-id" value the
endpoint transmitted via SDP. If the values i= n SDP and the
"ClientHello" do not match, the DTLS associati= on MUST be rejected.
=C2=A0
The Key Distributor might have multiple pending a= ssociations, and
potentially only weak bindings to endpoint identi= ties prior to DTLS
establishment, so it's not clear that "match [ext= ernal_session_id]
against 'tls-id' value the endpoint transmitted v= ia SDP" is entirely
accurate. I'm implicitly inserting a "the" befor= e "tls-id" to make it
parse, but the implicit "the" is not a good fit s= ince the definite
article implies there is a single one identified= but there may be
multiple pending associations. AFAICT at this po= int in processing the
only real identifier that the key distributor has = for the pending DTLS
association is the UUID from the media distributo= r and there is no tight
association betwen that identifier and the "tld-i= d" value that (per the
following paragraph) is conveyed to the key distr= ibutor in some
unspecified manner.

The UUID is introduced in this protocol only to facilitate routing messa= ges to the right endpoint.
<= br />
"The" should have been = in that sentence.

The KD will have the tls-id va= lues advertised in SDP from the endpoint.=C2=A0 How that happens is deliber= ately not specified, as there was no effort (or desire, I think) to define= the mechanism of getting those values from the endpoint to the KD.=C2=A0 Th= ere might be a quasi-trusted SIP UA that hands the info to the KD, or it mi= ght be an entirely proprietary WebRTC-based server that delivers that infor= mation to the KD.=C2=A0 The WG did not want to nail that down.=C2=A0 In any = case, the assumption is that the KD will have these values.= =C2=A0 So when the DTLS message arrives, it should be able to match the DTL= S sessions with media lines in the SDP.

Perhaps w= e need a statement stating the KD receives the tls-id via some unspecified= means?=C2=A0 Or am I missing the issue entirely?=C2=A0


=
= The Key Distributor MUST match the certificate fingerprint and
"external_session_id" received from endpoint's = "ClientHello" message
with the values received from the SDP transmit= ted by the endpoint.
=C2=A0
This sentence is rather confusing to me, since I= don't know of a
certificate fingerprint conveyed in the ClientHel= lo itself (as opposed
to the fingerprint of the certificate contained i= n the Certificate
message presented during the handshake).

This refers to the fingerprint of the certificate.= =C2=A0 I didn't create that language.=C2=A0 RFC 4572:

"It provides for endpoints to include a secure hash of their
certificate, known as the "= certificate fingerprint", within the
session description."

I'll add a reference to that RFC since it is a depende= ncy.


It is through this process that the= Key Distributor can be sure to
deliver the correct conference key to the endp= oint.
=C2=A0
Do we need to say anything about how the Key Dist= ributor gets the
fingerprint and external_session_id values from S= DP? (I mean, I assume
that it's the same way that it gets the "tls-id", = but the previous
paragraph just talked about "tls-id" and not the= other stuff, so
formally it's ambiguous.)

The "external_session_id" comes via DTLS.=C2=A0 The "tls-id" comes = via SDP.=C2=A0 It is a little confusing, but as I noted above, the WG did= not want to prescribe how the KD go the tls-id value.


When sending the "Se= rverHello" message, the Key Distributor MUST
insert its own unique identifier in the "exter= nal_session_id"
extension. This value MUST also be conveyed b= ack to the client via
SDP as a "tls-id" attribute.
=C2=A0
It's not really clear that the binding between th= e endpoint that is
supposedly presenting the DTLS data and the SDP d= ata has been
established at all here, so the selection of what = "tls-id" to use here
feels rather speculative. I think we should disc= uss the security
considerations for what is leaked if the key dist= ributor sends the
"wrong" values here...

Yeah, same issues as above.=C2=A0 We do not have a protocol that def= ines how this exchange happens with the KD.


I'm also not sure if the sequencing of events is = properly described
here. Does the SDP need to complete before the D= TLS handshake begins,
or can they proceed in parallel as described here= ?

<= div id=3D"x6d3d9c140b644bc">SDP has to be exchanged first, as otherwi= se the endpoint would not know where to send the DTLS message.=C2=A0 (And t= hen there's potentially ICE before DTLS, but let's not go there.)


Section 6
=C2=A0
= Tunnel
messages are specified using the format descri= bed in [RFC5246]
section 4. [...]
=C2=A0
I think that =C2=A73 of RFC 8446 is probably a be= tter reference for TLS
presentation language at this point.

OK, I changed that.=C2=A0 Now DTLS?=C2=A0 I'm still referenci= ng DTLS1.2.=C2=A0 I'll add a note for the RFC editor to consider updating t= hose references, unless you'd suggest I change it to reference the IETF dra= ft.


Section = 6.5
=C2=A0
I'm not sure what purpose sending an empty dtls_m= essage would serve.
=C2=A0
* "dtls_message": the content of the DTLS mes= sage received by the
endpoint or to be sent to the endpoint.
=C2=A0
I recommend saying something about "including rec= ord-layer framing" to
reiterate where the boundary is.

I need help with that language. In my mind, it was whatever = was in the UDP payload, but I'm happy to write something more prescriptive= . I just do not know what to write.


Section= 9
=C2=A0
I strongly recommend upgrading the TLS version be= tween media distributor
and key distributor to be TLS 1.3. Whether or no= t to use DTLS 1.2 or
1.3 for the tunneled traffic between endpoint and = key distributor is an
orthogonal topic.

I think I've updated all references to 1.3 now in my local copy.


I'd also reit= erate that the media distributor has access to metadata
about the endpoint/key distributor communications= , even though the main
content and key information is encrypted.

What metadata, exactly? With or without this proto= col, I think what you're saying would be true and it would likely be more s= uited for the Framework (that's already an RFC).=C2=A0 I'm happy to add som= ething here, but I'm not sure what.


=
I'd also consider calling out that the medi= a distributor could generate
false EndpointDisconnect messages, but that this= is essentially the same
capability afforded by just not forwarding media= anymore.

Yeah, it could.=C2=A0 The MD is definitely in a posit= ion to break things.=C2=A0 I'll note this possibility.


<= div class=3D"plain_line"> A requirement in this document is that a= TLS connection between the
Media Distributor and the Key Distributor be m= utually authenticated.
The reason for this requirement is to ensure t= hat only an authorized
Media Distributor receives the HBH keying mate= rial. [...]
=C2=A0
Can we say anything about what the Key Distributo= r's authorization
policy might be, using the authenticated identity = of the TLS peer as
input? "Any authenticated identity is granted al= l access" is not a
great authorization policy :)
<= div id=3D"x6d3d9c140b644bc">
The only thing possible here are messages sent over the tunnel = that's established.=C2=A0 the scope is limited to just this protocol.


NITS
=C2=A0
Abstract
=C2=A0
This document defines a DTLS tunneling protoco= l for use in multimedia
=C2=A0
I think the hyphenated "DTLS-tunneling" would cla= rify that DTLS is being
tunneled (as opposed to the mechanism used to tun= nel other things).
A slightly more intrusive change would be "protoc= ol for tunneling DTLS
traffic" but that might be confusing in the terse = setting of the
Abstract.

I like= the more verbose form, actually.=C2=A0 I do this (until you tell me to chan= ge it):

<= div id=3D"x6d3d9c140b644bc">"This document defines a protocol for tun= neling DTLS traffic in multimedia
conferences that enables a= Media Distributor to..."
=C2= =A0

Section 1<= /div>
=C2=A0
By establishing this TLS tunnel between the Me= dia Distributor and Key
Distributor and implementing the protocol defi= ned in this document,
it is possible for the Media Distributor to fa= cilitate the
establishment of a secure DTLS association bet= ween an endpoint and
the Key Distributor in order for the endpoint= to receive E2E and HBH
keying material. [...]
=C2=A0
I think "receive" might not be the best word here= , since the key
material should incorporate contributions from bo= th parties; the "arrive
at" language used in the previous paragraph was g= ood.

How about "compute" or "generate"?=C2= =A0 The endpoint does, in fact, generate the keys. You're right that it doe= sn't just receive them.


=C2=A0
Section 4
=C2=A0
As DTLS messages are received from the endpoin= t by the Media
Distributor, they are forwarded to the Key Dis= tributor encapsulated
inside a "TunneledDtls" message. Likewise, as = "TunneledDtls"
messages are received by the Media Distributor = from the Mey
Distributor, the encapsulated DTLS packet is f= orwarded to the
endpoint.
=C2=A0
s/Mey/Key/

Got it= !


<= blockquote type=3D"cite" class=3D"cite2">
Se= ction 5.1
=C2=A0
The endpoint MUST include a unique identifier= in the "tls-id" SDP
[RFC4566] attribute sent by the endpoint in bo= th offer and answer
[RFC3264] messages as per [RFC8842]. Further, = the endpoint MUST
include this same unique identifier in the "ex= ternal_session_id"
extension [RFC8844] in the "ClientHello" messa= ge when establishing a
DTLS association.
=C2=A0
Since this is the section about the endpoint proc= edures (the key
distributor's behavior is discussed later), I thi= nk we might avoid
phrasing that implies a linked offer/answer pair, = and instead say
something like "in all offer and answer messages= that it generates".
OK, changed it.<= /div>


Section 5.4=
=C2=A0
The Key Distributor MUST encapsulate any DTLS= message it sends to an
endpoint inside a "TunneledDtls" message (see= Section 6). The Key
Distributor is not required to transmit all me= ssages a given DTLS
association through the same tunnel if more th= an one tunnel has been
established between it and a Media Distributor= .
=C2=A0
I suggest "a given Media Distributor", since the= current phrasing seems
to allow sending to a different media distributor = entirely, which seems
unlikely to work since the UUID identifying the D= TLS association will
not be recognized there.

I suggest this, but feel free to suggest something else:

"The Key Distrib= utor is not required to transmit
all messages for a given DTLS associatio= n through the same tunnel if more
than one tunnel has been established bet= ween it and the Media Distributor."
=C2= =A0
=C2=A0There might be n=C2=A0tu= nnels between the KD and MD, but the messages MUST be sent to the solitary= MD that is communicating with the endpoint.=C2=A0 If the KD just sends thos= e messages out any tunnel, that's not going to work.=C2=A0 It has to be a t= unnel to a specific MD.


= The Key Distributor MUST select a cipher that is supported by both
the endpoint and the Media Distributor to ensu= re proper HBH
operations.
=C2=A0
(It also has to pick a cipher that it itself supp= orts...)

<= /span>
Indeed. I'll change that.

Section 5.5
=C2=A0
"UnsupportedVersion". The Media Distributor c= an determine from the
first two octets received what the version num= ber is and that the
message is "UnsupportedVersion". The rest of= the data received, if
=C2=A0
I think that the "two" should be either "one" or= "four", as the actual
message structure has two octets of length betwee= n the message type and
the unsupported_version structure. One octet is= needed to determine
that it is an unsupported-version message, and fo= ur to determine the
highest supported version number.

Indeed. I changed it to 4.=C2=A0


Section 6.2
=C2=A0
struct {
uint8 version;
SRTPProtectionProfile protection_profiles&= lt;0..2^16-1>;
} SupportedProfiles;
=C2=A0
The presentation language allows an empty list of = profiles; is that
intended to be allowed? (What happens if an empt= y list is sent?)

That's an error.=C2=A0 Thi= s should be at least two octets in length.=C2=A0 I'll change it to 2..2^16-= 1. The call will fail if nothing is offered.=C2=A0 The call might fail if s= omething is offered, but offering something gives a fighting chance :)

This = should align with RFC 5764. I believe it does.=C2=A0 This should just be a = vector of two-octet values.

=

* "version": indicates t= he version of the protocol to use (0x00).
=C2=A0
I suggest "this document specifies version 0x00"= rather than the
parenthetical.
Changed it as you suggest.

Paul

<= /span>
--------=_MBD73DD5F9-8EAA-4CF4-95C4-21894D7A6B7B-- From nobody Fri Aug 20 21:39:36 2021 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 789D73A0AC5; Fri, 20 Aug 2021 21:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 vEtOna6Q7qB2; Fri, 20 Aug 2021 21:39:28 -0700 (PDT) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (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 55CAE3A0AC3; Fri, 20 Aug 2021 21:39:28 -0700 (PDT) Received: by mail-vk1-xa2f.google.com with SMTP id j12so931951vka.6; Fri, 20 Aug 2021 21:39:28 -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=B/aeDtpQUPrjXu5EPdz69s8fs+8ItT036JxI+MYH6IQ=; b=Uo4kPBrMrZnrgC0S2UaUZOrLvtTt3oZ9mWaw/q3Z49rJJRIQfOh1hvK0Z0TjzdeMYD Iz7Litj1q8TLIp4/Sh88s5ORXRsoUX7JrCAPE5hAPC/64mYkokPdX2U+dyNinR+8Ja20 LV+Ez6jzFJ6fmhu8upH2vZrKu19qL8PSVMCFg1WP965IV6QsHwVWxKUutqGFKNpgQrEM bPBZOPjUCdI24YkpG0ooG0YRabSJ+W/K5nOC0rU7qSoEt2IlrdAaM1OgfrM3HXgQ520c nWFLFj+d9AmPcSygoWVSC40FVMZsfAKzs5PF2NgWH+58jJKSfvqp7Jzhb1nXfSjg3ej+ 3coQ== 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=B/aeDtpQUPrjXu5EPdz69s8fs+8ItT036JxI+MYH6IQ=; b=i4RF4a+nDxvTxDSaJq5tA2WTG2GEWJJaXTN7xALuDAxudq/A2JlPrnEooz+S4gHDZw CgmE+JuUWQA6TgSbVcqgoOXv1mSMO+eN9S9RQxtuwj9ouAWmSuwTTsd7Qr4c/d3zLee0 tzdb5q0+6+HUlTceRjZQyFGlL1v9QZWLk086nHb92Y3dQjG4kLRPujgMz8IjrVckLn09 AKNgPk1ywrJxbrE1DJ/NQbgvThph6xZYX/O89/YqYfR09B8c3rZrYYJ2YmyUMXbKjw2q ZdSKF3dV3cWUt1IqkCDqATNLNTExH7OzSbc4/MafJmt1lQVzCC5+ax//X0H3WM3RcP64 OzPA== X-Gm-Message-State: AOAM533Tn7uYQVHgCKBdfQB3PGC6gWXWWI9gWyPTgcek9E1jt4O2RPpS ObGOMES95bPZ1/5yvKt03tP/OwMw+2vsuhEosjQ= X-Google-Smtp-Source: ABdhPJz0PmKZ7kdRTaD/5feyAmMvLbuTBAGMH/Jejn3MJ2xUPEjRSLldmMDeD0Y0sv5VAF+SmyhbiZzUxsuhmWYVyOA= X-Received: by 2002:a1f:2582:: with SMTP id l124mr18460701vkl.20.1629520766705; Fri, 20 Aug 2021 21:39:26 -0700 (PDT) MIME-Version: 1.0 References: <162510321507.13724.12968550804927630403@ietfa.amsl.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Fri, 20 Aug 2021 21:39:15 -0700 Message-ID: To: "Paul E. Jones" Cc: Benjamin Kaduk , The IESG , perc-chairs@ietf.org, Suhas Nandakumar , perc@ietf.org, draft-ietf-perc-dtls-tunnel@ietf.org Content-Type: multipart/alternative; boundary="00000000000074258905ca0a5e89" Archived-At: Subject: Re: [Perc] Benjamin Kaduk's Discuss on draft-ietf-perc-dtls-tunnel-09: (with DISCUSS and COMMENT) X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2021 04:39:34 -0000 --00000000000074258905ca0a5e89 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 5, 2021 at 6:17 PM Paul E. Jones wrote: > > (2) I'll also mention here so that the IESG can talk about it during our > telechat (but with no intent to insist on a change): this document > specifies a versioned protocol and creates a registry. Are we happy > with the current Informational status, as opposed to Proposed Standard? > I do see that the topic was touched on in the shepherd writeup, but the > treatment there did not feel especially compelling to me. > > > Hopefully that got resolved. I'll await instructions on any requested > changes here. > I'm not aware of a resolution. I never got a reply after my message of July 1, where I suggested some possible paths by the working group. -MSK --00000000000074258905ca0a5e89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Aug 5, 2021 at 6:17 PM Paul E. Jo= nes <paulej=3D40packe= tizer.com@dmarc.ietf.org> wrote:

(2)= I'll also mention here so that the IESG can talk about it during our
telechat (but with no intent to insist on a change): this document
specifies a versioned protocol and creates a registry. Are we happy
with the current Informational status, as opposed to Proposed Standard= ?
I do see that the topic was touched on in the shepherd writeup, but th= e
treatment there did not feel especially compelling to me.

H= opefully that got resolved.=C2=A0 I'll await instructions on any reques= ted changes here.

= I'm not aware of a resolution.=C2=A0 I never got a reply after my messa= ge of July 1, where I suggested some possible paths by the working group.

-MSK

--00000000000074258905ca0a5e89-- From nobody Tue Aug 31 14:02:37 2021 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 8AD0C3A0D75; Tue, 31 Aug 2021 14:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 lE9HeoG61dEl; Tue, 31 Aug 2021 14:02:23 -0700 (PDT) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 7FF663A0D71; Tue, 31 Aug 2021 14:02:23 -0700 (PDT) Received: by mail-vs1-xe30.google.com with SMTP id f6so708507vsr.3; Tue, 31 Aug 2021 14:02: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=6bc3dG72xs1OqNn/cnRMJ0rD5QF7msJQEVVm6N2dleE=; b=AquP2GXDgzW7XdL3vQv0/KlLIzYS4HqAKNRhz3SAXOp0tVS1VogGIpt5aPBKH2Leq9 wFwjYbYcdInBrhuYpGvtaAwHBmz3m+fHGdyRk3G5RS6dGhSJmqlbXjB+jXeDyjfSmqlC QtTfTHLI0Uv0cW+MEWL635AVHlWohfMfm3x3ygor5nAYb/tMYxS29JL8hhMqo3CJCpA6 9SSEFPtnoTK3LFgDo+p9njgPMqtuyYpvjt85XqU7I84b2fQ/eEoSkjgRdtnip3e/GoB6 3xwEPw5GxMwiC95aN9HTc+kHMsLvJUnaKh71vrwqk9ULz339e4aqNXyjxkCozq3AgCBB mS7Q== 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=6bc3dG72xs1OqNn/cnRMJ0rD5QF7msJQEVVm6N2dleE=; b=Yo/4sMfRro8eiNzOYIld/9kKIS7qnhndMkHt9F55n0wm61PKqFomMOQEAw4OeeRs1j 8nyFk5WfoabCCCFhlJFY5jwf+XR3/Yn22sxZ0jucdW4XbcpwdsLtEQM+CXkuo2IsVX46 nYf0kxf/BGAYkx4W3L6fXc7928e5jkdew6Yp1ZY2AdE0UwMQmivTmyL9ybWRmzKoxv+6 Yq5P5/OsfBDCDiRID/OkvXrdpKdruHPKhJN49jkguFlc1WzRDHKx1Mhk8o9FnjrCkAON Ag1/DZcHfHoV22rRcAYhf0fWTbVORXBQSh+zjlkaLSuzIxja4+f7JrPVND0iIj9pC3bK M7ng== X-Gm-Message-State: AOAM533/0C4AE8M2wDUQZv9MHrk+C2txrGbl6SqgWz9BKRhy2sh4cN/0 Rdo/4drvz2niGMwRBQRASU7FrtjvdNexzEEiowI75uV3 X-Google-Smtp-Source: ABdhPJxjwHEjmgTf7+ddQJae+UmqpbRta0ZEdNY5/nKCacxkOcuOl+Cpv89xa66OIBfCHcoHOnU2WTPa2hBVDku/XWQ= X-Received: by 2002:a05:6102:3f4f:: with SMTP id l15mr20069600vsv.33.1630443741433; Tue, 31 Aug 2021 14:02:21 -0700 (PDT) MIME-Version: 1.0 References: <162510321507.13724.12968550804927630403@ietfa.amsl.com> In-Reply-To: From: "Murray S. Kucherawy" Date: Tue, 31 Aug 2021 14:02:10 -0700 Message-ID: To: "Paul E. Jones" Cc: Benjamin Kaduk , The IESG , perc-chairs@ietf.org, Suhas Nandakumar , perc@ietf.org, draft-ietf-perc-dtls-tunnel@ietf.org Content-Type: multipart/alternative; boundary="00000000000008d42805cae144f5" Archived-At: Subject: [Perc] draft-ietf-perc-dtls-tunnel-09 follow-up X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 21:02:29 -0000 --00000000000008d42805cae144f5 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 20, 2021 at 9:39 PM Murray S. Kucherawy wrote: > On Thu, Aug 5, 2021 at 6:17 PM Paul E. Jones 40packetizer.com@dmarc.ietf.org> wrote: > >> >> (2) I'll also mention here so that the IESG can talk about it during our >> telechat (but with no intent to insist on a change): this document >> specifies a versioned protocol and creates a registry. Are we happy >> with the current Informational status, as opposed to Proposed Standard? >> I do see that the topic was touched on in the shepherd writeup, but the >> treatment there did not feel especially compelling to me. >> >> >> Hopefully that got resolved. I'll await instructions on any requested >> changes here. >> > > I'm not aware of a resolution. I never got a reply after my message of > July 1, where I suggested some possible paths by the working group. > Suhas, as both co-chair and document shepherd, please drive the resolution of these points so we can finally put this document to bed. Alternatively, if we should just abandon this, please let me know so I can press the appropriate buttons. -MSK --00000000000008d42805cae144f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Aug 20, 2021 at 9:39 PM Murray S.= Kucherawy <superuser@gmail.com> wrote:

(2) I'll also m= ention here so that the IESG can talk about it during our
telechat (but with no intent to insist on a change): this document
specifies a versioned protocol and creates a registry. Are we happy
with the current Informational status, as opposed to Proposed Standard= ?
I do see that the topic was touched on in the shepherd writeup, but th= e
treatment there did not feel especially compelling to me.

Hopefully that got r= esolved.=C2=A0 I'll await instructions on any requested changes here.

I'm not aware o= f a resolution.=C2=A0 I never got a reply after my message of July 1, where= I suggested some possible paths by the working group.

Suhas, as both co-chair and document shepherd= , please drive the resolution of these points so we can finally put this do= cument to bed.

Alternatively, if we should just abandon t= his, please let me know so I can press the appropriate buttons.
<= br>
-MSK
--00000000000008d42805cae144f5--