UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS)
draft-ietf-mmusic-udptl-dtls-10

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

---------------------------------------------------

Thank you very much for the updated introduction.  This helps a lot to clarify the purpose of the work.

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.

Thank you for producing this document. If I was more familiar with the details, I'd have balloted "yes".

Thanks for adding the crypto alg detail.