Skip to main content

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

Yes

Murray Kucherawy

No Objection

Erik Kline
(Robert Wilton)

Recuse


Note: This ballot was opened for revision 09 and is now closed.

Murray Kucherawy
Yes
Erik Kline
No Objection
Francesca Palombini
No Objection
Comment (2021-07-01 for -09) Sent
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
Roman Danyliw
No Objection
Comment (2021-06-30 for -09) Sent
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 …”
Éric Vyncke
No Objection
Comment (2021-06-30 for -09) Sent
[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/ ?
Zaheduzzaman Sarker
Recuse
Comment (2021-07-01 for -09) Not sent
I work very closely with one of the inventors of one of the claimed IPR, hence decided to recuse myself.
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2021-10-28 for -11) Sent for earlier
Thank you for addressing my Discuss points!
Robert Wilton Former IESG member
No Objection
No Objection (for -09) Not sent