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

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 06 Aug 2021 01:17:35 +0000

Benjamin,

>(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.
>
>In particular, the current specification has the Key Distributor sending
>the MediaKeys message before it sends the DTLS (server) Finished
>message (§5.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 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 
exists only because that's how it worked oh-so-many-years-ago when this 
document was originally written. :)

I removed the language about the Finished message.  The desire was only 
to ensure the KD provides the MD with media keys before is replies to 
the endpoint.  That's only so that the MD can be prepared for the first 
media packet to arrive.  However, if the keys arrive late, it's not the 
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 
message.

There are other messages mentioned in that section (namely ClientHello 
and ServerHello).  Those appear to still be valid statement, but please 
correct me if I'm wrong. I could remove the references to messages, but 
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 
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 
architectures 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).  That said, I will add a paragraph to the security 
considerations section highlighting this issue; I just cannot offer a 
mitigation since that's well beyond the scope of this document.

How about this addition:

"While the Security Considerations section of [@RFC8871] describes 
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 
DTLS-SRTP
messages to a Media Distributor.  The Media Distributor will normally 
forward
those messages to the Key Distributor and, if found invalid, such 
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 
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 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 
1 is useless with respect to Endpoint 2.  The PERC Framework (RFC 8871) 
describes a number of bad things the MD can do.  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 mentioning somewhere more
>explicitly.

This protocol is not dependent on DOUBLE, though the PERC system 
prescribes its use by endpoints.  Implementers of this protocol really 
do not need to know how the HBH keys are created.  As such, I'd prefer 
to not introduce that here.  For the purposes of this protocol, 
implementers only need to know that there is a message containing HBH 
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, 
it means there are a plurality of places where that MediaKeys message 
might go.  I am confused about one point: why would the KD not be able 
to verify the endpoint on the initial DTLS message?  If it can, then it 
seems like this would still be a valid exchange.  If it cannot, then 
what would be the alternative flow? And do we really want to enumerate 
several?  I am happy to add whatever clarification we need, but would 
prefer to not to show several exchanges (that might be different in DTLS 
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 
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.  
How that happens is deliberately 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.  There might be a quasi-trusted SIP UA that 
hands the info to the KD, or it might be an entirely proprietary 
WebRTC-based server that delivers that information to the KD.  The WG 
did not want to nail that down.  In any case, the assumption is that the 
KD will have these values.  So when the DTLS message arrives, it should 
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 
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 
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.  
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 "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 
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 
where to send the DTLS message.  (And then there's potentially ICE 
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 §3 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 
a note for the RFC editor to consider updating those references, unless 
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 
UDP payload, but I'm happy to write something more prescriptive. I just 
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 
you're saying would be true and it would likely be more suited for the 
Framework (that's already an RFC).  I'm happy to add something here, but 
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.  
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 
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 
change it):

"This document defines a protocol for tunneling DTLS traffic in 
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 
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 
more
than one tunnel has been established between it and the Media 
Distributor."

  There might be n tunnels between the KD and MD, but the messages MUST 
be sent to the solitary MD that is communicating with the endpoint.  If 
the KD just sends those messages out any tunnel, that's not going to 
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 
change it to 2..2^16-1. The call will fail if nothing is offered.  The 
call might fail if something is offered, but offering something gives a 
fighting chance :)

This should align with RFC 5764. I believe it does.  This should just be 
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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 20 Aug 2021 21:39:15 -0700

> Hopefully that got resolved.  I'll await instructions on any requested

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 31 Aug 2021 14:02:10 -0700

> 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