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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Thu, 14 Oct 2021 12:16:36 -0700

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.

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 21 Oct 2021 04:11:50 +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

Thank you.  I made the changes as you suggest.

>     MediaKeys message as is used in the TunneledDtls messages for the given

Good point.  Change made as suggested.

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.

>putting together a "protocol invariants" section.

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

>though for an Informational protocol I won't insist on it (this is a

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.

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

>even if it was not the intended path, and would get the HBH keys as a

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.

>DTLS-SRTP profile?  If so, that might be worth mentioning somewhere more

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.

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

>accurate, and it seems like that arrow should be moved later in the time

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.

>following paragraph) is conveyed to the key distributor in some

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.

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

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

>considerations for what is leaked if the key distributor sends the

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.

>or can they proceed in parallel as described here?

SDP must happen first.

>presentation language at this point.

This was updated in draft -10.

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

>1.3 for the tunneled traffic between endpoint and key distributor is an

I've upgraded all references to the latest drafts and RFCs, I think.  No 
point referring to old stuff.

>content and key information is encrypted.

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

>capability afforded by just not forwarding media anymore.

I'll add something about that, too.

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 25 Oct 2021 16:40:42 +0000

Ben, Murray, et al,

I published version 11 for consideration:
https://datatracker.ietf.org/doc/html/draft-ietf-perc-dtls-tunnel-11

Paul

------ Original Message ------
From: "Paul E. Jones" <paulej=[email-masked]>
To: "Benjamin Kaduk" <[email-masked]>; "The IESG" <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; 
[email-masked]
Sent: 10/21/2021 12:11:50 AM
Subject: Re: [Perc] Benjamin Kaduk's Discuss on 
draft-ietf-perc-dtls-tunnel-10: (with DISCUSS and COMMENT)

>  If you'd prefer, I can publish draft -11 now or we can further revise this PR.
>
>Thanks!
>Paul
>
>
>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:
>
>     `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
>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
>>
>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.
>
>
>Indeed, this could be another attack vector the KD implementations should consider.  I'll add a paragraph on that.
>
>
>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.
>
>
>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:
>
>     `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
>     length advertised in the `MediaKeys` message is half the length of the key
>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
>>
>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
>>
>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.
>
>
>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.
>
>
>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.
>
>
>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.
>
>
>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've upgraded all references to the latest drafts and RFCs, I think.  No point referring to old stuff.
>
>
>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
>>
>_______________________________________________
>Perc mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/perc

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 28 Oct 2021 16:22:13 -0700

Hi Paul,

Thanks for going ahead and publishing the -11 while I was heads-down on
other things.

I've updated my ballot position in the datatracker to "No Objection", so
Murray should be able to go ahead and mark this as approved (assuming
nothing comes out of the below).

Just a couple further notes inline.

> expected values received via SDP.

Hmm, okay.  I admite that I do not have all of WebRTC in my head, so I may
well just be wrong, but I had thought that the "tls-id" values from SDP
were themselves sent in a TLS extension per RFC 8844, as a way to
authenticate the binding between the SDP exchange and the TLS handshake.

> the "fingerprint" SDP value described in RFC 8122.

This helps in that it removes mention of the ClientHello (if the
fingerprint isn't in an extension, it's not available from just the
ClientHello).  This formulation is still not very satisfying for me (in a
rather pedantic way that probably doesn't bother many people), since the
certificate is what's received via DTLS, and the fingerprint is computed
from the certificate.  If you're up for more changes, I would propose "MUST
match the fingerprint of the certificate, and the "external_session_id"
[RFC8844], received from the endpoint via DTLS".

> now in the body of the text now, though.

That makes sense to me, thanks.

> change the syntax so that DTLS messages cannot be 0 octets in length (as 

Okay.  (If I remember correctly I did not even try to figure out which of
these bits had changed in the -10.)

Many thanks for all the discussion above, and the updates to the document
-- I really appreciate having the extra background.

-Ben

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 31 Oct 2021 17:41:36 +0000

Ben,

>authenticate the binding between the SDP exchange and the TLS handshake.

The "tls-id" is first sent in SDP from the endpoint as it tries to 
establish a call or join a conference.  The endpoint will receive an 
answer to that SDP containing, among other things, the transport 
address(es) to which DTLS packets should be sent.  The initiating 
endpoint then initiates a DTLS handshake and includes the "TLS ID" value 
in the "external_session_id" extension.  This is how the Key Distributor 
is able to differentiate between a plurality of "calls" that might be 
initiated at or about the same time from the same endpoint.  (There are 
perhaps other security benefits described in the associated RFCs, but 
this is the primary benefit for the tunnel draft).  I think this is all 
correct, but if you or others see a glaring hole or error, I'm happy to 
correct it.  Maybe the language still is not clear enough.

>[RFC8844], received from the endpoint via DTLS".

I'm always open to improvements.  How is this?

     The Key Distributor **MUST** match the fingerprint of the 
certificate and

Paul