UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS)
RFC 7345
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
(Alissa Cooper; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
(Alia Atlas; former steering group member) No Objection
(Barry Leiba; former steering group member) (was Discuss) No Objection
UPDATE:
I asked Dave Crocker for a review, as he chaired the fax working group, way back when. One comment that he made, which I agree with and want to pass on, is this:
<< When the technical details of a reference are so fundamental to a new specification, I prefer the citation to it to be as precise as possible, to save the reader from having to do searching. Hence I suggest that the initial reference to UDPTL should explicitly cite "Section 9" of the t38.2010 doc. >>
-----
Christer has responded to all my earlier comments; I leave the responses here for the record. Thanks!
-- Section 4.2 --
The offerer SHOULD assign the SDP "setup" attribute with a value of
"actpass". Alternatively, the offerer MAY assign the SDP "setup"
attribute with a value of "active" or "passive". The offerer MUST
NOT assign an SDP "setup" attribute with a "holdconn" value.
Standard SHOULD/MAY problem: MAY is not an alternative to SHOULD; MAY is entirely optional.
In order to resolve this, let me first ask *why* the offerer SHOULD set "setup" to "actpass", under what conditions might the offerer need to use "active" or "passive" instead, and what are the consequences of doing that?
-------------------------
RESPONSE:
Setting the value to "actpass" allows the terminating endpoint to determine the TLS role, ie which endpoint will send ClientHello.
"active" or "passive" is used if the offerer, for whatever reason, insists on being either the sender (TLS client) or receiver (TLS server) of the ClientHello.
In order to solve the SHOULD/MAY problem, I suggest the following modified text:
The offerer SHOULD assign the SDP "setup" attribute with a value of
"actpass", unless it insists on being either the sender or receiver of the
DTLS ClientHello message, in which case it can use either a value of
"active" (sender of ClientHello) or "passive" (receiver of ClientHello).
---------------------------------------------------
-- Section 5.2.2 --
The UA MUST demultiplex packets arriving on the IP address and port
associated with the DTLS association, e.g. as follows:
I'm not sure what the "e.g. as follows" is saying. Are the two bullets meant to be one example how how one might demultiplex the packets, and there are also other ways one might do it? Are the two bullets a suggested way, or just an example? Or is there some other sense that I'm not seeing?
-------------------------
RESPONSE:
The idea is to mandate support of the mechanism described in the document, but to not prevent usage of alternative future mechanisms.
I agree that the current text is a little confusing, so I suggest the following modified text:
"The UA MUST support the following mechanism for
demultiplexing packets arriving on the IP address and
port associated with the DTLS association:"
o If the value of the first byte of the packet is 0 or 1, then the
packet is STUN.
o If the value of the first byte of the packet is between 20 and 63
(inclusive), the packet is DTLS."
---------------------------------------------------
Very, very small, tiny point, which you can completely ignore if you like: "SHALL" and "MUST" mean exactly the same thing, and I always find it preferable to use one or the other, consistently. You mostly use "MUST", but in Sections 3, 5.1, and 5.2.2 you have one instance each of "SHALL". I mildly, mildly suggest that you change those three to "MUST", to be consistent.
-------------------------
RESPONSE:
I agree with you, and I am happy to replace SHALL with MUST.
---------------------------------------------------
-- Section 4.4 --
When the offerer receives an SDP answer and, if the offerer ends up
being active it MUST initiate a DTLS handshake by sending a DTLS
ClientHello message on the negotiated media stream, towards the IP
address and port of the answerer.
That reads oddly to me, mostly, I think, because of the "and, if" bit. Maybe you just need to delete the comma and the "if". Alternatively, you could delete "and".
-------------------------
RESPONSE:
I suggest to remove "and".
"When the offerer receives an SDP answer, if the offerer ends up
being active it MUST initiate a DTLS handshake by sending a DTLS
ClientHello message on the negotiated media stream, towards the IP
address and port of the answerer."
---------------------------------------------------
-- Section 5.3 --
After the DTLS handshake caused by rekeying has completed, because of
possible packet reordering on the wire, packets protected by the
previous set of keys can arrive.
That sentence seems awkward because things come in an odd order -- kind of backward. May I suggest this?:
NEW
During rekeying, packets protected by the previous set of keys can
arrive after the DTLS handshake caused by rekeying has completed,
because packets can be reordered on the wire.
END
-------------------------
RESPONSE:
Looks good. I'll update as suggested.
---------------------------------------------------
-- Section 6 --
The standard DTLS strategy for authenticating the communicating
parties is to give the server (and optionally the client) a PKIX
[RFC5280] certificate. The client then verifies the certificate and
checks that the name in the certificate matches the server's domain
name. This works because there are a relatively small number of
servers with well-defined names; a situation that does not usually
occur in the VoIP context.
I don't follow the last sentence. I don't understand why there are relatively few servers that have well defined names. I don't see why that's important with respect to how authentication by cert validation works. And I don't get how this relates to VoIP. Can you explain, please?
-------------------------
RESPONSE:
We borrowed the text from RFC 5763.
However, I agree that the VoIP text is confusing, and suggest the following modified text:
"The standard DTLS strategy for authenticating the communicating
parties is to give the server (and optionally the client) a PKIX
[RFC5280] certificate. The client then verifies the certificate and
checks that the name in the certificate matches the server's domain
name. This works because there are a relatively small number of
servers and the cost for issuing and deploying PKIX certificates can
be justified. Issuing and deploying PKIX certificates to all clients is
not realistic in most deployment scenarios."
---------------------------------------------------
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) (was Discuss) No Objection
Thank you very much for the updated introduction. This helps a lot to clarify the purpose of the work.
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
I will simply ask this as a question; I have no intention of DISCUSSing it. If the SEC ADs are interested, they are in a much better position to DISCUSS: Given that there's confidentiality/integrity protection available at the application layer, I was left to wonder why 3GPP wanted to do it at the transport layer. I'm worried that the reason they want to do this is in order to more easily *violate* confidentiality: Doing it at the transport layer means that intermediaries can peek at the contents of the FAX, whereas doing it at the application layer prevents everybody but the end users from being able to peek. Is that what's going on here? If so, and if this is considered a reasonable thing to want to do, that should probably be called out as a potential vulnerability in the security considerations (or perhaps a new privacy considerations) section. Sorry for thinking nefarious thoughts, but I've got to ask.
(Richard Barnes; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
Thank you for producing this document. If I was more familiar with the details, I'd have balloted "yes".
(Stephen Farrell; former steering group member) (was Discuss) No Objection
Thanks for adding the crypto alg detail.