DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange
draft-ietf-perc-dtls-tunnel-12

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

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

[Ballot comment]
Thank you for the work on this document.

I agree with Ben's and Eric's comments: the document seems to me to be written as a standard track doc, which defines a new protocol, rather than informational or even experimental. I just wanted to add that this to me is not only about the creation of the IANA registry, but the whole text (my comment is somewhat related to Eric's comment about using BCP 14 terminology).

Francesca

[Ballot comment]
[Fixing a cut&paste error]

Thank you for the work put into this document. It is indeed a very valuable set-up.

Special thanks for Suhas Nandakumar's shepherd write-up about the WG process / consensus.

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric


== COMMENTS ==

I was about to raise a DISCUSS on this but I am trusting the security AD on this topic. But, I really wonder why TLS 1.2 is used rather than TLS 1.3.

There is no operational consideration around the resiliency of the Key Distributor (load balancing, fail-over, etc.). Should there be some operational considerations ?

-- Abstract --
While I agree that this document could be informational, why does the abstract use words like "defines" "the protocol is designed" as those words are more normative than descriptive. Strongly suggest to rephrase the abstract.

-- Section 1 --
Knowledgeable people will understand the E2E and HBH concepts but a figure would be welcome for beginners (really just a suggestion).

Later and in the same vein "simply forwarding packets" for me (INT AD) packets are layer-3 and it is really unclear in the introduction what is actually forwarded. I.e., 'packets' should be qualified, perhaps in "DTLS messages" or using the same vocabulary of section 5.3 ?

-- Section 2 --
As usual, I am not comfortable when an informational document relies on BCP 14, which should (IMHO) be reserved for BCP/standards track documents. Just a comment, feel free to ignore.

-- Section 5.2 --
"which tunnel or tunnels to use to send messages for a given conference is outside the scope of this document." is really a lot of hand waving as I wonder how the document could be used without knowing which tunnels is to be used.


== NITS ==

There are several occurrences of "an message"... probably a replace all, which went wrong ;-)

-- Section 1 --
s/on behalf of the endpoint/on behalf of the endpointS/ ?

[Ballot discuss]
(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.

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

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

[Ballot comment]
Thank you to Shawn Emery for the SECDIR review, and to Russ Housley for the security related feedback in the GENART review.

** Section 5.4.
  The Key Distributor MUST match the certificate fingerprint and
  "external_session_id" received from endpoint's "ClientHello" message
  with the values received from the SDP transmitted by the endpoint.

Consider adding a reference to RFC8122 to point to the guidance on the SDP fingerprint attribute.

** On the topic of relying on the RFC8122 defined hashes, Section 5 allows for the possibility of SHA-1 which is now past its prime.  The text there already says “Implementations compliant with this specification MUST NOT use the MD2 and MD5 hash functions to calculate fingerprints or to verify received fingerprints that have been calculated using them.”  Likewise, Section 5.1 also notes the requirement of at least one of the hashes being SHA-256.  Consider saying sometime along the lines of “Implementations using this tunneling approach SHOULD NOT use SHA-1 hash functions to calculate or verify fingerprints …”

[Ballot comment]
Thank you to Shawn Emery for the SECDIR review, and to Russ Housley for the security related feedback in the GENART review.

** Section 5.4.
  The Key Distributor MUST match the certificate fingerprint and
  "external_session_id" received from endpoint's "ClientHello" message
  with the values received from the SDP transmitted by the endpoint.

Consider adding a reference to RFC8122 to point to the guidance on SDP fingerprint attribute.

** On the topic of relying on the RFC8122 defined hashes, Section 5 allows for the possibility of SHA-1 which is now past its prime.  The text there already says “Implementations compliant with this specification MUST NOT use the MD2 and MD5 hash functions to calculate fingerprints or to verify received fingerprints that have been calculated using them.”  Likewise, Section 5.1 also notes the requirement of at least one of the hashes being SHA-256.  Consider saying sometime along the lines of “Implementations using this tunneling approach SHOULD NOT use SHA-1 hash functions to calculate or verify fingerprints …”

[Ballot comment]
Thank you for the work put into this document. It is indeed a very valuable set-up.

Special thanks for Suhas Nandakumar's shepherd write-up about the WG process / consensus.

Please find below one blocking DISCUSS point, some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric


== DISCUSS ==

-- Sections 3.3, 3.4, and 4.3 --

== COMMENTS ==

I was about to raise a DISCUSS on this but I am trusting the security AD on this topic. But, I really wonder why TLS 1.2 is used rather than TLS 1.3.

There is no operational consideration around the resiliency of the Key Distributor (load balancing, fail-over, etc.). Should there be some operational considerations ?

-- Abstract --
While I agree that this document could be informational, why does the abstract use words like "defines" "the protocol is designed" as those words are more normative than descriptive. Strongly suggest to rephrase the abstract.

-- Section 1 --
Knowledgeable people will understand the E2E and HBH concepts but a figure would be welcome for beginners (really just a suggestion).

Later and in the same vein "simply forwarding packets" for me (INT AD) packets are layer-3 and it is really unclear in the introduction what is actually forwarded. I.e., 'packets' should be qualified, perhaps in "DTLS messages" or using the same vocabulary of section 5.3 ?

-- Section 2 --
As usual, I am not comfortable when an informational document relies on BCP 14, which should (IMHO) be reserved for BCP/standards track documents. Just a comment, feel free to ignore.

-- Section 5.2 --
"which tunnel or tunnels to use to send messages for a given conference is outside the scope of this document." is really a lot of hand waving as I wonder how the document could be used without knowing which tunnels is to be used.


== NITS ==

There are several occurrences of "an message"... probably a replace all, which went wrong ;-)

-- Section 1 --
s/on behalf of the endpoint/on behalf of the endpointS/ ?

[Ballot comment]
Thank you for the work put into this document. It is indeed a very valuable set-up.

Special thanks for Suhas Nandakumar' shepherd write-up about the WG process / consensus.

Please find below one blocking DISCUSS point, some non-blocking COMMENT points (but replies would be appreciated), and some nits.

I hope that this helps to improve the document,

Regards,

-éric


== DISCUSS ==

-- Sections 3.3, 3.4, and 4.3 --

== COMMENTS ==

I was about to raise a DISCUSS on this but I am trusting the security AD on this topic. But, I really wonder why TLS 1.2 is used rather than TLS 1.3.

There is no operational consideration around the resiliency of the Key Distributor (load balancing, fail-over, etc.). Should there be some operational considerations ?

-- Abstract --
While I agree that this document could be informational, why does the abstract use words like "defines" "the protocol is designed" as those words are more normative than descriptive. Strongly suggest to rephrase the abstract.

-- Section 1 --
Knowledgeable people will understand the E2E and HBH concepts but a figure would be welcome for beginners (really just a suggestion).

Later and in the same vein "simply forwarding packets" for me (INT AD) packets are layer-3 and it is really unclear in the introduction what is actually forwarded. I.e., 'packets' should be qualified, perhaps in "DTLS messages" or using the same vocabulary of section 5.3 ?

-- Section 2 --
As usual, I am not comfortable when an informational document relies on BCP 14, which should (IMHO) be reserved for BCP/standards track documents. Just a comment, feel free to ignore.

-- Section 5.2 --
"which tunnel or tunnels to use to send messages for a given conference is outside the scope of this document." is really a lot of hand waving as I wonder how the document could be used without knowing which tunnels is to be used.


== NITS ==

There are several occurrences of "an message"... probably a replace all, which went wrong ;-)

-- Section 1 --
s/on behalf of the endpoint/on behalf of the endpointS/ ?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-perc-dtls-tunnel-08. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

A new registry is to be created called the Datagram Transport Layer Security (DTLS) Tunnel Protocol Data Types for Privacy Enhanced Conferencing registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If it needs a new page, does it also need a new category at http://www.iana.org/protocols (and if so, should the page and the category have the same name)?

The registration policy for the new registry is IETF Review as defined in RFC8126.

There are initial registrations in the new registry as follows:

+=========+====================================+===============+
| MsgType | Description | Reference |
+=========+====================================+===============+
| 0x01 | Supported SRTP Protection Profiles | [ RFC-to-be ] |
+---------+------------------------------------+---------------+
| 0x02 | Unsupported Version | [ RFC-to-be ] |
+---------+------------------------------------+---------------+
| 0x03 | Media Keys | [ RFC-to-be ] |
+---------+------------------------------------+---------------+
| 0x04 | Tunneled DTLS | [ RFC-to-be ] |
+---------+------------------------------------+---------------+
| 0x05 | Endpoint Disconnect | [ RFC-to-be ] |
+---------+------------------------------------+---------------+

IANA Question --> Section 8 of the current draft indicates that "The value 0x00 and all values in the range 0x06 to 0xFF are reserved." Should these values be reserved or simply unassigned?

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-06-07):

From: The IESG
To: IETF-Announce
CC: draft-ietf-perc-dtls-tunnel@ietf.org, perc-chairs@ietf.org, perc@ietf.org, suhasietf@gmail.com, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DTLS Tunnel between a Media Distributor and Key Distributor to Facilitate Key Exchange) to Informational RFC


The IESG has received a request from the Privacy Enhanced RTP Conferencing WG
(perc) to consider the following document: - 'DTLS Tunnel between a Media
Distributor and Key Distributor to
  Facilitate Key Exchange'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-06-07. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines a DTLS tunneling protocol for use in multimedia
  conferences that enables a Media Distributor to facilitate key
  exchange between an endpoint in a conference and the Key Distributor.
  The protocol is designed to ensure that the keying material used for
  hop-by-hop encryption and authentication is accessible to the media
  distributor, while the keying material used for end-to-end encryption
  and authentication is inaccessible to the media distributor.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-perc-dtls-tunnel/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3586/
  https://datatracker.ietf.org/ipr/3580/

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

draft-ietf-perc-dtls-tunnel is targeted as Informational status document,
and this write­up is for the same. Informational is appropriate because this document
simply presents an example of the Key Distributor and Media Distributor to be
connected.This is reflected on the title page
and in the data tracker.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document defines a DTLS tunneling protocol for use in multimedia
conferences that enables a Media Distributor to facilitate key
exchange between an endpoint in a conference and the Key Distributor.
The protocol is designed to ensure that the keying material used for
hop-by-hop encryption and authentication is accessible to the media
distributor, while the keying material used for end-to-end encryption
and authentication is inaccessible to the media distributor.

Working Group Summary

This document has been discussed and reviewed several times by the
WG. Given the nature of work proposed by this document as defining
one of the ways to setup protocol machinery between
a key distributor and the end points for providing keying material
needed for PERC double encryption procedures,  there was a general
consensus to move forward with this document in the WG.


Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

An earlier version of the draft was implemented along with
PERC double and EKT implementations to realize the protocol
workings for end to end encryption.
This document did not require expert review of the types noted.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

The document shepherd is Suhas Nandakumar; the responsible Area Director is Murray S. Kucherawy.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

This document has been reviewed and discussed several times with in
the WG. It has been reviewed by personnel from Security Area.
(Special thanks to Russ Housley)

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

I do not have any concerns about the working group reviews to date.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

It has been reviewed by Russ Housley from Security Area.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns that I am aware of.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are IPR declaration at https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-perc-dtls-tunnel

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The working group as a whole concurs with this approach as one of the
ways to achieve the goal for setting up keying for end to end encryption.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No threats of appeal or otherwise.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No nits were found when verified on the version
draft-ietf-perc-dtls-tunnel-07.txt

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

This document does not present the need for these reviews.

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

Not applicable.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

There are no requests for downward references.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

This document does not change the status of any existing RFC.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This document establishes a new registry to contain message type
values used in the DTLS Tunnel protocol. The name for this registry is
"Datagram Transport Layer Security (DTLS) Tunnel Protocol Data Types for
Privacy Enhanced Conferencing" The update is not controversial within
the working group. 

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

This document establishes a new registry to contain message type
values used in the DTLS Tunnel protocol. The name for this registry is
"Datagram Transport Layer Security (DTLS) Tunnel Protocol Data Types for
Privacy Enhanced Conferencing" The update is not controversial within
the working group.  Future allocations needs a specification to update
the registry.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

ABNF content in the document was validated with
https://tools.ietf.org/tools/bap/abnf.cgi

 
(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
Not Applicable

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

draft-ietf-perc-dtls-tunnel is targeted as Informational status document,
and this write­up is for the same. Informational is appropriate because this document
simply presents an example of the Key Distributor and Media Distributor to be
connected.This is reflected on the title page
and in the data tracker.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document defines a DTLS tunneling protocol for use in multimedia
conferences that enables a Media Distributor to facilitate key
exchange between an endpoint in a conference and the Key Distributor.
The protocol is designed to ensure that the keying material used for
hop-by-hop encryption and authentication is accessible to the media
distributor, while the keying material used for end-to-end encryption
and authentication is inaccessible to the media distributor.

Working Group Summary

This document has been discussed and reviewed several times by the
WG. Given the nature of work proposed by this document as defining
one of the ways to setup protocol machinery between
a key distributor and the end points for providing keying material
needed for PERC double encryption procedures,  there was a general
consensus to move forward with this document in the WG.


Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

An earlier version of the draft was implemented along with
PERC double and EKT implementations to realize the protocol
workings for end to end encryption.
This document did not require expert review of the types noted.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

The document shepherd is Suhas Nandakumar; the responsible Area Director is Murray S. Kucherawy.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

This document has been reviewed and discussed several times with in
the WG. It has been reviewed by personnel from Security Area.
(Special thanks to Russ Housley)

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

I do not have any concerns about the working group reviews to date.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

It has been reviewed by Russ Housley from Security Area.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns that I am aware of.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are IPR declaration at https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-perc-dtls-tunnel

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The working group as a whole concurs with this approach as one of the
ways to achieve the goal for setting up keying for end to end encryption.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No threats of appeal or otherwise.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No nits were found when verified on the version
draft-ietf-perc-dtls-tunnel-07.txt

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

This document does not present the need for these reviews.

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

Not applicable.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

There are no requests for downward references.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

This document does not change the status of any existing RFC.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This document establishes a new registry to contain message type
values used in the DTLS Tunnel protocol. The name for this registry is
"Datagram Transport Layer Security (DTLS) Tunnel Protocol Data Types for
Privacy Enhanced Conferencing" The update is not controversial within
the working group. 

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

This document establishes a new registry to contain message type
values used in the DTLS Tunnel protocol. The name for this registry is
"Datagram Transport Layer Security (DTLS) Tunnel Protocol Data Types for
Privacy Enhanced Conferencing" The update is not controversial within
the working group.  Future allocations needs a specification to update
the registry.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

ABNF content in the document was validated with
https://tools.ietf.org/tools/bap/abnf.cgi

 
(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
Not Applicable

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

draft-ietf-perc-dtls-tunnel is targeted as Informational status document,
and this write­up is for the same. This is reflected on the title page
and in the data tracker.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document defines a DTLS tunneling protocol for use in multimedia
conferences that enables a Media Distributor to facilitate key
exchange between an endpoint in a conference and the Key Distributor.
The protocol is designed to ensure that the keying material used for
hop-by-hop encryption and authentication is accessible to the media
distributor, while the keying material used for end-to-end encryption
and authentication is inaccessible to the media distributor.

Working Group Summary

This document has been discussed and reviewed several times by the
WG. Given the nature of work proposed by this document as defining
one of the ways (recommendations) to setup protocol machinery between
a key distributor and the end points for providing keying material
needed for PERCdouble encryption procedures,  there was a general
consensus to move forward with this documet in the WG.


Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

An earlier version of the draft was implemented along with
PERC double and EKT implementations to realize the protocol
workings for end to end encryption.
This document did not require expert review of the types noted.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

The document shepherd is Suhas Nandakumar; the responsible Area Director is Murray S. Kucherawy.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

This document has been reviewed and discussed several times with in
the WG. It has been reviewed by personnel from Security Area.
(Special thanks to Russ Housley)

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

I do not have any concerns about the working group reviews to date.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

It has been reviewed by Russ Housley from Security Area.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns that I am aware of.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are IPR declaration at https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-perc-dtls-tunnel

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The working group as a whole concurs with this approach as one of the
ways to achieve the goal for setting up keying for end to end encryption.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No threats of appeal or otherwise.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No nits were found when verified on the version
draft-ietf-perc-dtls-tunnel-07.txt

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

This document does not present the need for these reviews.

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

Not applicable.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

There are no requests for downward references.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

This document does not change the status of any existing RFC.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This document establishes a new registry to contain message type
values used in the DTLS Tunnel protocol. The name for this registry is
"Datagram Transport Layer Security (DTLS) Tunnel Protocol Data Types for
Privacy Enhanced Conferencing" The update is not controversial within
the working group. 

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

This document establishes a new registry to contain message type
values used in the DTLS Tunnel protocol. The name for this registry is
"Datagram Transport Layer Security (DTLS) Tunnel Protocol Data Types for
Privacy Enhanced Conferencing" The update is not controversial within
the working group.  Future allocations needs a specification to update
the registry.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

ABNF content in the document was validated with
https://tools.ietf.org/tools/bap/abnf.cgi

 
(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
Not Applicable

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

draft-ietf-perc-dtls-tunnel is targeted as Informational status document,
and this write­up is for the same. This is reflected on the title page
and in the data tracker.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document defines a DTLS tunneling protocol for use in multimedia
conferences that enables a Media Distributor to facilitate key
exchange between an endpoint in a conference and the Key Distributor.
The protocol is designed to ensure that the keying material used for
hop-by-hop encryption and authentication is accessible to the media
distributor, while the keying material used for end-to-end encryption
and authentication is inaccessible to the media distributor.

Working Group Summary

This document has been discussed and reviewed several times by the
WG. Given the nature of work proposed by this document as defining
one of the ways (recommendations) to setup protocol machinery between
a key distributor and the end points for providing keying material
needed for PERCdouble encryption procedures,  there was a general
consensus to move forward with this documet in the WG.


Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

There are no known active implementations of this document.
This document did not require expert review of the types noted.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

The document shepherd is Suhas Nandakumar; the responsible Area Director is Murray S. Kucherawy.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

This document has been reviewed and discussed several times with in
the WG. It has been reviewed by personnel from Security Area.
(Special thanks to Russ Housley)

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

I do not have any concerns about the working group reviews to date.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

It has been reviewed by Russ Housley from Security Area.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns that I am aware of.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are IPR declaration at https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-perc-dtls-tunnel

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The working group as a whole concurs with this approach as one of the
ways to achieve the goal for setting up keying for end to end encryption.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No threats of appeal or otherwise.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No nits were found when verified on the version
draft-ietf-perc-dtls-tunnel-07.txt

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

This document does not present the need for these reviews.

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

Not applicable.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

There are no requests for downward references.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

This document does not change the status of any existing RFC.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This document establishes a new registry to contain message type
values used in the DTLS Tunnel protocol. The name for this registry is
"Datagram Transport Layer Security (DTLS) Tunnel Protocol Data Types for
Privacy Enhanced Conferencing" The update is not controversial within
the working group. 

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

This document establishes a new registry to contain message type
values used in the DTLS Tunnel protocol. The name for this registry is
"Datagram Transport Layer Security (DTLS) Tunnel Protocol Data Types for
Privacy Enhanced Conferencing" The update is not controversial within
the working group.  Future allocations needs a specification to update
the registry.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

ABNF content in the document was validated with
https://tools.ietf.org/tools/bap/abnf.cgi

 
(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
Not Applicable

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

draft-ietf-perc-dtls-tunnel is targeted as Informational status document,
and this write­up is for the same. This is reflected on the title page
and in the data tracker.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document defines a DTLS tunneling protocol for use in multimedia
conferences that enables a Media Distributor to facilitate key
exchange between an endpoint in a conference and the Key Distributor.
The protocol is designed to ensure that the keying material used for
hop-by-hop encryption and authentication is accessible to the media
distributor, while the keying material used for end-to-end encryption
and authentication is inaccessible to the media distributor.

Working Group Summary

This document has been discussed and reviewed several times by the
WG. Given the nature of work proposed by this document as defining
one of the ways (recommendations) to setup protocol machinery between
a key distributor and the end points for providing keying material
needed for PERCdouble encryption procedures,  there was a general
consensus to move forward with this documet in the WG.


Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

There are no known active implementations of this document.
This document did not require expert review of the types noted.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

The document shepherd is Suhas Nandakumar; the responsible Area Director is Murray S. Kucherawy.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

This document has been reviewed and discussed several times with in
the WG. It has been reviewed by personnel from Security Area.
(Special thanks to Russ Housley)

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

I do not have any concerns about the working group reviews to date.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

It has been reviewed by Russ Housley from Security Area.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns that I am aware of.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

There are IPR declaration at https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-perc-dtls-tunnel

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The working group as a whole concurs with this approach as one of the
ways to achieve the goal for setting up keying for end to end encryption.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No threats of appeal or otherwise.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No nits were found when verified on the version
draft-ietf-perc-dtls-tunnel-07.txt

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

This document does not present the need for these reviews.

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

Not applicable.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

There are no requests for downward references.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

This document does not change the status of any existing RFC.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This document establishes a new registry to contain message type
values used in the DTLS Tunnel protocol. The name for this registry is
"Datagram Transport Layer Security (DTLS) Tunnel Protocol Data Types for
Privacy Enhanced Conferencing" The update is not controversial within
the working group. 

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

This document does not request new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

ABNF content in the document was validated with
https://tools.ietf.org/tools/bap/abnf.cgi

 
(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
Not Applicable