Re: [Perc] Benjamin Kaduk's Discuss on draft-ietf-perc-dtls-tunnel-10: (with DISCUSS and COMMENT)

"Paul E. Jones" <paulej@packetizer.com> Thu, 21 October 2021 04:12 UTC

Return-Path: <paulej@packetizer.com>
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 759763A11DD; Wed, 20 Oct 2021 21:12:06 -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 Cn0jR_UE8YsV; Wed, 20 Oct 2021 21:12:00 -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 F02CC3A1229; Wed, 20 Oct 2021 21:11:58 -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=1634789514; bh=+rKS7DVUXH05cIeBrzL8KKk+Z9Kg1M/nrlcuOb7bJVk=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=IvapnijgrpZoPbH7NCdVFtyx9WdwUU4fBRh5peMPZhzM1/NsPZr7SSZJ+FeJ/4YJK 6FTslA/sONgJyIarc6FCdkFmQEuyeJOBMZJXjCULSwuBMBHzGvOx3uXHIMDsnZ0ay0 Aa7CLO2qB+DRIRcUvCwlkppzbvgP3mfXTB1rQvBc=
From: "Paul E. Jones" <paulej@packetizer.com>
To: Benjamin Kaduk <kaduk@mit.edu>, 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
Date: Thu, 21 Oct 2021 04:11:50 +0000
Message-Id: <em3d81a846-2e4d-49b9-92d7-a4d651eff2e9@sydney>
In-Reply-To: <163423899560.11624.17767066695024804386@ietfa.amsl.com>
References: <163423899560.11624.17767066695024804386@ietfa.amsl.com>
Reply-To: "Paul E. Jones" <paulej@packetizer.com>
User-Agent: eM_Client/8.2.1659.0
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/perc/qeRNJRkh_YcUbRqab_4Gyc2cW74>
Subject: Re: [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
Precedence: list
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, 21 Oct 2021 04:12:07 -0000

Ben,

I responded to points below, but to see the changes I've made, see this:
https://github.com/percwg/perc-wg/pull/185

  If you'd prefer, I can publish draft -11 now or we can further revise 
this PR.

Thanks!
Paul


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

Thank you.  I made the changes as you suggest.


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

Good point.  Change made as suggested.


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

Actually, that was not the intended behavior. The intent was for the Key 
Distributor to match what it sees from the endpoint via DTLS with the 
expected values received via SDP.

I modified the text as follows, including repeated references to 
hopefully make this clearer:

     The Key Distributor **MUST** match the certificate fingerprint and
     `external_session_id` [@!RFC8844] received from endpoint via DTLS 
with the
     expected fingerprint [@!RFC8122] and `tls-id` [@!RFC8842] values 
received via
     SDP.  It is through this process that the Key Distributor can be 
sure to
     deliver the correct conference key to the endpoint.

Hopefully this helps.  The certificate fingerprint is computed by the 
KD, but using the same method as would have been performed in generating 
the "fingerprint" SDP value described in RFC 8122.


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

If we ever see a second version, maybe. :)


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

I can appreciate that, though I know this would lead to a lot of debate 
on architecture that I don't think we have the luxury to do at this 
point.


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

Indeed, this could be another attack vector the KD implementations 
should consider.  I'll add a paragraph on that.


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

I do not think this would be possible since the Key Distributor would 
not accept a connection if it could not match the certificate and 
tls_id.  That information would have been conveyed to the key 
distributor via SDP and, if the key distributor could not perform that 
match, the DTLS session would be rejected.


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

I wish you were in the group when reviewing the entirety of the system, 
because this is a better catch than this short paragraph suggests.  
Indeed, only DOUBLE protection profiles are defined for PERC.  I did not 
see any text that actually explains that the MediaKeys message only 
contains the portion of the key used for HBH encryption/decryption.  if 
you saw this stated elsewhere, let me know.  I propose fixing this 
oversight with this text in the Key Distributor section:

     There are presently two SRTP protection profiles defined for PERC,
     namely `DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM` and
     `DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM` [!@RFC8723].  As 
[!@RFC8723]
     explains in Section 5.2, the Media Distributor is only given the 
SRTP
     master key for HBH operations.  As such, the SRTP master key
     length advertised in the `MediaKeys` message is half the length of 
the key
     normally associated with selected "double" protection profile.


>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?)

This is always true and explained in the PERC framework document (RFC 
8871).  We could add more text here, but I would personally prefer to 
not add more than is strictly necessary for this piece of the larger 
architecture.


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

It was accurate, until you changed it in this email exchange. :)

I updated the diagram to put that at the bottom.  However, there is 
nothing in the diagram that explicitly says the handshake completes in 
the diagram, but I think it is hinted at now. It is explicitly stated 
now in the body of the text now, though.


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

Before the DTLS session is initiated, an SDP exchange would have 
occurred.  After all, the endpoint would not even know where to send a 
DTLS message otherwise. That is something outside the scope of this 
document, though.  The Key Distributor would already have something to 
pin this DTLS session against.


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

Hopefully this is less confusing in the next draft given the changes I 
mentioned above.  The fingerprint and "external_session_id" are both 
discussed in RFC 8122.  The text should be clearer than before, but 
perhaps another pass is needed to ensure that's true.


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

That is one aspect of the solution that the WG explicitly did not want 
to define.  The reason was that there is more than one possible protocol 
that might be used depending on where the KD is situated and how the KD 
interfaces with call control.  In cases where the KD is integrated with 
an endpoint that is part of a decentralized model, for example, it would 
be quite different than how this might work in a more complex, 
centralized solution.  Maybe this might get addressed one day, but I 
doubt it.  There seems to be a tendency these days to standardize the 
least possible.  Even this draft is just _a_ solution to the MD/KD 
interface problem.


>    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 think this gets back to the issue of the call control / KD interface 
that is not defined.  The KD _will_ get SDP from the endpoint before 
DTLS happens.  It cannot work any other way.  The endpoint needs to 
receive and SDP response with the address of the MD in order to initiate 
DTLS.  In between these steps, somehow through magic not defined, yet 
definitely outside the scope of this document, the KD will have been 
party to this SDP exchange and have this data.

If the wrong values are transmitted, the DTLS session should fail since 
either the KD or endpoint would detect a mismatch with SDP.


>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 must happen first.


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

This was updated in draft -10.

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

OK. I've added "This includes one or more complete  DTLS records."  I'm 
happy to adjust the language as you suggest.


>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've upgraded all references to the latest drafts and RFCs, I think.  No 
point referring to old stuff.


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

OK, I added a sentence to the security considerations section on that.

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

I'll add something about that, too.


>    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 :)

I think this gets into the "what is between the KD and the endpoint" 
problem.  I do not know what the policy might be, how the KD decides who 
is and is not allowed in a conference, etc.  Those things are outside 
the scope of this document and never settled.


>NITS

I think all of these below were addressed already in draft -10.  I did 
change the syntax so that DTLS messages cannot be 0 octets in length (as 
you suggested above).




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