Summary: Has 3 DISCUSSes. Needs 3 more YES or NO OBJECTION positions to pass.
This is nothing big and should be easy to fix: On section 7.1, of course... "If DTLS is transported on top of a connection-oriented transport protocol (e.g., TCP or SCTP), where all IP packets are acknowledged, all DTLS packets associated with a previous DTLS association MUST be acknowledged (or timed out) before a new DTLS association can be established on the same instance of that transport (5-tuple)." I don't think this would be necessary for QUIC. The point here is, I believe, not the fact that TCP and SCTP are connection-oriented, but that re-transmissions cannot be easily distinguished from the original packet. So the point is rather the use of a reliable protocol that retransmits in a specific way. However, why would you use DTLS with TCP instead of TLS? And I also don't think you want to use DTLS with QUIC because it has it's own crypto. I guess the recommendation should rather be that reliable transports should use TLS, and if DTLS is needed a new DTLS connection can only be established if there is not retransmission ambiguity which is always the case when all outstanding packets are ack'ed or considered lost (timed out). Or am I missing the point?
A couple mostly editorial comments: - Probably a nit: In section 3.2 'must' is used while in section 3.3 'MUST' is used. I would assume that both sections should probably use the same. - in sec 5.1: "Because of this, if an unordered transport is used for the DTLS association, a new transport (3-tuple) must be allocated by at least one of the endpoints so that DTLS packets can be de-multiplexed." Why is this a 3-tuple (instead of a 5-tuple)? I guess you talk about the source address, source port, transport 3-tuple? May say this more explicitly. Also the word of the use transport is confusing to me here because it's used for the transport protocol as well as for the transport 'connection' (if a connection-oriented transport protocol is used). Maybe s/new transport/new flow/? Moreover, there should probably be a 'MUST' here instead of 'must'! - sec 5.2:"In addition, the offerer MUST insert in the offer an SDP 'tls-id' attribute with a unique attribute value." Is that a MUST or rather a SHOULD? The rest of the text reads like this should be a SHOULD. - Shouldn't this document cite RFC6347 normatively, e.g. here (sec 5.3): "... the answerer MUST initiate a DTLS handshake by sending a DTLS ClientHello message towards the offerer." - I would like to see more discussion about linkability based on the introduction of the "tls-id" in the security considerations section.
This is a fine document, but I have one [hopefully easy to answer] question and a couple of other minor ones: In Section 5.1. General Endpoints MUST support the cipher suites as defined in [RFC8122]. I don't see any ciphers specified in that RFC. Can you clarify what you mean?
8. TLS Considerations NOTE: Even though the SDP 'connection' attribute can be used to indicate whether a new TLS connection is to be established, the unique combination of SDP 'tls-id' attribute values can be used to identity a TLS connection. The unique value can be used e.g., within TLS protocol extensions to differentiate between multiple TLS connections and correlate those connections with specific offer/ answer exchanges. Are any such extensions defined or in the process of being standardized? If an offerer or answerer receives an offer/answer with conflicting attribute values, the offerer/answerer MUST process the offer/answer as misformed. I think a pointer to document and section where such handling is specified would be useful here.
1. Assuming I understand this document correctly, it conflicts with the guidance in JSEP. Specifically, S 4 says: No default value is defined for the SDP 'tls-id' attribute. Implementations that wish to use the attribute MUST explicitly include it in SDP offers and answers. If an offer or answer does not contain a 'tls-id' attribute (this could happen if the offerer or answerer represents an existing implementation that has not been updated to support the 'tls-id' attribute), unless there is another mechanism to explicitly indicate that a new DTLS association is to be established, a modification of one or more of the following characteristics MUST be treated as an indication that an endpoint wants to establish a new DTLS association: o DTLS setup role; or o fingerprint set; or o local transport parameters; or o ICE ufrag value This seems to say that if there is no tls-id attribute, then an ICE restart (which necessitates a ufrag change) requires a DTLS restart. JSEP isn't incredibly clear on this point, but 5.7.3 seems to say that tls-id neeed not be present: * tls-id value, which MUST be set according to [I-D.ietf-mmusic-dtls-sdp], Section 5. If this is a re-offer and the tls-id value is different from that presently in use, the DTLS connection is not being continued and the remote description MUST be part of an ICE restart, together with new ufrag and password values. If this is an answer, the tls-id value, if present, MUST be the same as in the offer. I believe that the first sentence is in error, as we clearly can't have JSEP implementations requiring that tls-id be present. ... o If the remote DTLS fingerprint has been changed or the tls-id has changed, tear down the DTLS connection. This includes the case when the PeerConnection state is "have-remote-pranswer". If a DTLS connection needs to be torn down but the answer does not indicate an ICE restart or, in the case of "have-remote-pranswer", new ICE credentials, an error MUST be generated. If an ICE restart is performed without a change in tls-id or fingerprint, then the same DTLS connection is continued over the new ICE channel. I think the best interpretation of this is that if tls-id is not present (and hence unchanged) then ICE restart does not cause DTLS restart. This is also my memory of the consensus in RTCWEB. In any case, these two documents clearly must match. 2. S 4 says: The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls- id' attribute is 'IDENTICAL', which means that the attribute value must be identical across all media descriptions being multiplexed [I-D.ietf-mmusic-sdp-bundle-negotiation]. This is not actually what JSEP requires: different categories. To avoid unnecessary duplication when bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be repeated in bundled m= sections, repeating the guidance from [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1. This includes I suspect this is old text. 3. S 7.1 says: If DTLS is transported on top of a connection-oriented transport protocol (e.g., TCP or SCTP), where all IP packets are acknowledged, This is incorrect, because none of these protocols ack all IP packets. all DTLS packets associated with a previous DTLS association MUST be acknowledged (or timed out) before a new DTLS association can be established on the same instance of that transport (5-tuple). More generally, I'm not sure that this is useful, because the required semantic isn't *acknowledged* but rather that the receiver can appropriately demux. So, say you just stop sending DTLS on connection A and start sending on B, what's the delimiter, given that you don't require close_notify here? IIRC, we just decided to punt on this whole thing. Does anyone try to have successive connections over the same transport, even when it's connection oriented? 4. The demux instructions seem to have gotten lost from 6.7.1. At minimum these need a reference to RFC 7983.
S 5.1. media session immediately (see [RFC8122]). Note that it is permissible to wait until the other side's fingerprint(s) has been received before establishing the connection; however, this may have undesirable latency effects. I agree that it's permissible, but why would you do this? This does not seem like helpful guidance. S 10. Please do something about the "NEW" constructions. I literally had to pull these into ediff to know what had changed. That's not useful to people. I'm not a fan of this construction in general, but at minimum you need to explain what has changed. S 9. Regardless of the previous existence of a DTLS association, the SDP 'setup' attribute MUST be included according to the rules defined in [RFC4145] and if ICE is used, ICE restart MUST be initiated. What is the rationale for this rule?
This falls well into the "This is outside my area of expertise" part of: This ballot position may be interpreted as "This is outside my area of expertise or have no cycles", in that you exercise the ability to move a document forward on the basis of trust towards the other ADs. :-)
I agree with Alexey's discuss, thanks for addressing it.
Mostly a nit... RFC4572 has been Obsoleted by RFC8122. I think that this change in status implicitly means that all references to RFC4572 should now really refer to RFC8122. I then don't think there's a need to explicitly Update the references from RFC4572 to RFC8122. In the text Updating RFC5763 (10.2.1), the document says: "The reference to [RFC4572] is replaced with a reference to [RFC8122]." I don't think that is necessary. Also, the Update to RFC7345 (10.3.3) adds a Normative bibliographical entry to RFC8122, but no text is updated to point at that RFC. I don't think this is necessary either.
Thanks for the quick answer to my DISCUSS. I agree with the core assertion of EKR's DISCUSS: this document needs to be aligned with JSEP. I think we're going to need a little additional work figuring out which document needs to change where they disagree. In addition to those areas he highlights in his DISCUSS, the following text is also in conflict: DTLS-SDP: "the offerer and answerer generate their own local 'tls-id' attribute values, and the combination of both values identify the DTLS association." JSEP: "If this is an answer, the tls-id value, if present, MUST be the same as in the offer." [Note: this does appear to be an issue in JSEP rather than this document] I would think the long-form title of this document should include "TLS," to reflect that it also contains TLS-related procedures. Section 1: "...but currently there is no way..." will not age well once this is an RFC. Suggest "...previously, there was no way..." or somesuch. Section 2 uses RFC 2119 boilerplate, and then the very next sentence uses a non-normative "must." I would strongly recommend moving to RFC 8174 boilerplate. The conventional name for DTLS-SRTP is "DTLS-SRTP" -- please change replace "SRTP-DTLS" with "DTLS-SRTP" everywhere it appears. The last paragraph in section 5.4 starts with "NOTE" (which implementors frequently read as non-normative) and then contains a normative statement. Suggest removing "NOTE:" Please expand the following acronyms upon first use and in the title; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. - SDP - Session Description Protocol - DTLS - Datagram Transport Layer Security - TLS - Transport Layer Security - ICE - Interactive Connectivity Establishment - SCTP - Stream Control Transmission Protocol - SRTP - Secure Realtime Transport Protocol - UDPTL - UDP Transport Layer