[Perc] Benjamin Kaduk's Discuss on draft-ietf-perc-dtls-tunnel-10: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 14 October 2021 19:16 UTC
Return-Path: <noreply@ietf.org>
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 7BEC73A17BF; Thu, 14 Oct 2021 12:16:36 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-perc-dtls-tunnel@ietf.org, perc-chairs@ietf.org, perc@ietf.org, suhasietf@gmail.com, suhasietf@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.39.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <163423899560.11624.17767066695024804386@ietfa.amsl.com>
Date: Thu, 14 Oct 2021 12:16:36 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/perc/ueQh-hbi6i1hw46Y4UqpSTKo5ko>
Subject: [Perc] Benjamin Kaduk's Discuss on draft-ietf-perc-dtls-tunnel-10: (with DISCUSS and COMMENT)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Privacy Enhanced RTP Conferencing <perc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perc>, <mailto:perc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/perc/>
List-Post: <mailto:perc@ietf.org>
List-Help: <mailto:perc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perc>, <mailto:perc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Oct 2021 19:16:37 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-perc-dtls-tunnel-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/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-perc-dtls-tunnel/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for the updates in the -10; they are improvements. I also see that we had enough discussion of Informational vs Standards-Track for this document, with no one really wanting to push for it to be a Proposed Standard. Unfortunately, I think there are still a couple places remaining that aren't quite compatible with DTLS 1.3, and so an additional revision will be required. Section 5.4 (1) 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. In (D)TLS 1.3, the external_session_id extension goes in the EncryptedExtensions message, not the ServerHello. One way to handle this scenario in a DTLS-version-agnostic manner would be NEW: The Key Distributor MUST report its own unique identifier in the "external_session_id" extension. This extension is sent in the EncryptedExtensions message in DTLS 1.3, and the ServerHello in previous DTLS versions. This value MUST also be conveyed back to the client via SDP as a tls-id attribute. (2) The Key Distributor MUST send a MediaKeys message to the Media Distributor as soon as a HBH encryption key is computed. The MediaKeys message includes the selected cipher (i.e. protection profile), MKI [RFC3711] value (if any), SRTP master keys, and SRTP master salt values. The Key Distributor MUST use the same association identifier in the MediaKeys message as is used in the TunneledDtls messages for the given endpoint. "As soon as a HBH encryption key is computed" is too soon. The key is available before the endpoint is authenticated, and a properly operating DTLS-SRTP session should not send media before the mutual authentication has completed; sending the HBH encryption key "when available" would allow the media distributor (which has no visibility into when the DTLS handshake is completed) to send media even though the authentication is not complete. I think it would be more appropriate to say that the MediaKeys message is sent when the DTLS handshake is complete, which is unambiguous and a condition that is universally applicable to all DTLS versions. That might be written as something like NEW: The Key Distributor MUST send a MediaKeys message to the Media Distributor immediately after the DTLS handshake completes. The MediaKeys message includes the selected cipher (i.e. protection profile), MKI [RFC3711] value (if any), SRTP master keys, and SRTP master salt values. The Key Distributor MUST use the same association identifier in the MediaKeys message as is used in the TunneledDtls messages for the given endpoint. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A couple remarks on the -10: Section 5.4 The Key Distributor MUST match the certificate fingerprint [RFC4572] and external_session_id received from endpoint's ClientHello message with the values received from the SDP transmitted by the endpoint [RFC8122]. As far as I can tell, the certificate fingerprint is in the "external_id_hash" TLS extension in the ClientHello, but this document does not mention that extension name in any location. I strongly suggest noting somewhere (possibly earlier) that the fingerprint hash used here is conveyed in the "external_id_hash" extension. (Also, 4752 is obsoleted by 8122, and does not cover the TLS conveyance of the fingerprint at all.) One way to do that would be NEW: The Key Distributor MUST match the certificate fingerprint [RFC8122] and unique session identifier received in the "external_id_hash" [RFC8844] and "external_session_id" [RFC8844] TLS extensions (respectively) of the endpoint's ClientHello message with the values received from the SDP transmitted by the endpoint [RFC8122]. Section 5.5 Note that it is not necessary for the Media Distributor to understand the newer version of the protocol to understand that the first message received is UnsupportedVersion. The Media Distributor can determine from the first four octets received what the version number is and that the message is UnsupportedVersion. This would be great content for a "protocol invariants" section, though given the lack of interest in changing the target status of this document to Standards-Track I do not expect there to be much interest in putting together a "protocol invariants" section. =============== Ballot Comments from the -09 preserved below for posterity =========== 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 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. 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. 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. 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?) 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. 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 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). 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.) 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... 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? Section 6 Tunnel messages are specified using the format described in [RFC5246] section 4. [...] I think that §3 of RFC 8446 is probably a better reference for TLS presentation language at this point. 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. 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'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. 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. 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 :) 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. 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. 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/ 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". 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. 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...) 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. 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?) * "version": indicates the version of the protocol to use (0x00). I suggest "this document specifies version 0x00" rather than the parenthetical.
- [Perc] Benjamin Kaduk's Discuss on draft-ietf-per… Benjamin Kaduk via Datatracker
- Re: [Perc] Benjamin Kaduk's Discuss on draft-ietf… Paul E. Jones
- Re: [Perc] Benjamin Kaduk's Discuss on draft-ietf… Paul E. Jones
- Re: [Perc] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Perc] Benjamin Kaduk's Discuss on draft-ietf… Paul E. Jones