Eric, Thanks. The new draft takes care of my comments.
John > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Eric Rescorla > Sent: 26 August 2008 23:06 > To: [email protected] > Subject: [Sip] New version of draft-ietf-sip-dtls-srtp-framework > > I just submitted a new version of this document intended to address > the WGLC comments. Attached below are the dispositions of the > comments I received. Please let me know if I've screwed anything > up. > > -Ekr > > John Elwell: > > This is in good shape - just a bunch of minor comments. > > > > 1. "The Real-time Transport Protocol (RTP) [RFC3550] is used > > to transmit real time media on top of UDP and TCP [RFC4571]. > > Datagram TLS [RFC4347] was introduced to allow TLS > functionality to > > be applied to datagram transport protocols, such as UDP and DCCP. > > This draft provides guidelines on how to establish SRTP [RFC3711] > > security using an extension to DTLS (see > [I-D.ietf-avt-dtls-srtp])." > > This first says that RTP can be used on top of UDP and TCP, but then > > says that this draft addresses the use of DTLS for > establishing SRTP. > > DTLS is applicable only when SRTP is carried over UDP, not TCP. This > > should be made clear, e.g., > > "...guidelines on how to establish SRTP [RFC3711] security > over UDP..." > > Done. > > > > 2. "S/MIME > > signatures, as described in RFC 3261, or SIP Identity, > as described > > in [RFC4474] provides the highest level of security > because they are > > not susceptible to modification by malicious intermediaries." > > Also there are other places in the draft that mention > S/MIME, including > > section 8.3. In the SIP session at IETF72 there was discussion about > > deprecating S/MIME in SIP. If this is the intent of the WG, > is it wise > > to mention the technique in new RFCs? > > I think I'd prefer to leave this in here. S/MIME hasn't been > deprecated > yet, and it's add to not mention something that after all is in > RFC 3261 and would get the job done. > > > > 3. "The SIP message > > containing the offer SHOULD be sent to the offerer's sip > proxy over > > an integrity protected channel which SHOULD add an > identity header > > according to the procedures outlined in [RFC4474]. " > > It is the proxy, not the channel, that should add the > Identity header > > field. Also some other nits. Change to: > > "The endpoint SHOULD send the SIP message > > containing the offer to the offerer's sip proxy over > > an integrity protected channel. The proxy SHOULD add an Identity > > header field > > according to the procedures outlined in [RFC4474]." > > Done. > > > > 4. "The far endpoint (answerer) may now establish a mutually > > authenticated DTLS association to the offerer." > > This assumes that the far endpoint will play the active > role. However, > > that is not necessarily so, and will depend what is > negotiated in SDP. > > Fixed. > > > > 5. "DTLS-SRTP does not provide anonymous calling." > > Should this say: > > "DTLS-SRTP does not prevent anonymous calling."? > > No, but I agree it's unclear. I rewrote as > > The use of DTLS-SRTP does not provide anonymous calling, > however it also does not prevent it. > > > > > 6. "Additionally, it MUST be ensured that the Privacy > header [RFC3325] > > is > > used in conjunction with the SIP identity mechanism to > ensure that > > the identity of the user is not asserted when enabling anonymous > > calls." > > In fact 3325 does not define the Privacy header field - it > only defines > > the additional value 'id'. Suggest we say: > > "Additionally, it MUST be ensured that the Privacy header field with > > value 'id' [RFC3325]...." > > I don't know whether we also need a reference to RFC 3323, > in which case > > it would become: > > "Additionally, it MUST be ensured that the Privacy header field > > [RFC3323] with value 'id' [RFC3325]....". > > Fixed. > > > > 7. Should section 6.1 on anonymous calls have an > informative reference > > to the ua-privacy draft? > > Added. > > > > 8. "Each answerer will create a DTLS association with > > the offerer." > > It is not necessarily the case that the answerer will create the > > association - it could also be the offerer. > > s/create/form/ > > > > 9. "Once the answer is received, the active endpoint > > will either reuse the existing association or establish > a new one, > > tearing down the existing association as soon as the offer/answer > > exchange is completed." > > If the answerer is the active endpoint, how can it > determine that the > > offer/answer exchange is completed, i.e., how does it know > the offerer > > has received the answer? > > Yeeah, that is weird. I think I fixed that. > > > > 10. "Note > > that this may mean adjusting the endpoint IP addresses if the > > selected candidate pair shifts, just as if the DTLS > packets were an > > ordinary media stream." > > What is the impact on the in-progress or completed DTLS handshake if > > there is a shift of IP address? > > None. DTLS does not care about IP addresses as long as it gets > the data it needs. > > > > 11. "Implementations of this specification SHOULD support DTLS-SRTP > > [I-D.ietf-avt-dtls-srtp]." > > I thought the whole draft was about DTLS-SRTP. Therefore why is this > > only SHOULD strength? Under what circumstances are > exceptions allowed? > > What are the alternatives to be used in these exceptional > circumstances? > > It should say MUST. It does now. > > > > 12. "Also note > > that there is a fingerprint attribute on the 'c' line > of the SDP." > > An attribute is a separate line, not part of a c-line. > > Fixed. > > > > 13. "This is computed from Bob's self-signed certificate." > > That is true for the answer, but for the offer it is from Alice's > > certificate. > > Doh! > > > > 14. "a=tcap:1 UDP/TLS/RTP/AVP RTP/AVP" > > Shouldn't this be: > > "a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP" > > Done. > > > > 15. "Message 3 shows Bob > > sending a DTLS ClientHello directly to Alice for each > 'm' line in > > the SDP. In this case two DTLS ClientHello messages > are sent to > > Alice. Bob sends a DTLS ClientHello to > 192.168.1.103:6056 for RTP > > and another to port 6057 for RTCP." > > The figure does not show two ClientHello messages, but it should do. > > This would then make the first sentence above wrong - it > would be two > > per 'm'line, not one per 'm' line. It is only one per 'm' line if > > RTP/RTCP mux is used. > > I fixed this by rewriting the text, not the figure. > > > > 16. "Note that in this case, Bob signals the actual > transport protocol > > configuration of SRTP over DTLS in the acfg parameter." > > This appears under message 9 (RTP/RTCP), but really it should occur > > under message 8 (200 OK). > > Fixed. > > > > 17. "When phone number URIs (e.g., > > 'sip:[EMAIL PROTECTED]') are used, there is no > > structural reason to trust that the domain name is > authoritative > > for a given phone number, although individual proxies > and UAs may > > have private arrangements that allow them to trust > other domains." > > This might suggest that the problem exists only when user=phone is > > absent, whereas it exists also (more particularly so) when > user=phone is > > present. It might be better to say: > > "When phone number URIs (e.g., > > 'sip:[EMAIL PROTECTED]' or > > 'sip:[EMAIL PROTECTED];user=phone') are used...." > > Done. > > > > NITS: > > - Change "media plan" to "media plane". > > - "in Enhancements for Authenticated Identity > > Management in SIP [RFC4474] is used" - delete "in". > > - "SIP proxies downstream of the identity service" change to "SIP > > proxies downstream of the authentication service" > > - "Since the identity header is a > > digital signature across several SIP headers, in addition to the > > bodies of the SIP message, " > > This contains several instances of wrong terminology. > "identity header" > > should be "Identity header field. "SIP headers" should be > "SIP header > > fields", and "bodies" should be "body". A SIP message has a single > > header (comprising header fields) and a single body > (perhaps containing > > multiple body parts). Similar corrections are needed throughout the > > document. > > I think I got all these. > > > > - "upon receiving the other side's then" > > I think this should say: > > "upon receiving the other side's SDP then" > > Done. > > > - "and key negotiation succeeds otherwise RTP is used" > > Change to: > > "and key negotiation succeeds, otherwise RTP is used" > > Done. > > > - "RTP is the > > default and will be understood by endpoints that do not > understand > > SRTP or this key exchange mechanism but SRTP is preferred." > > Change to: > > "This allows an offerer to express a preference for SRTP, > but RTP is the > > default and will be understood by endpoints that do not > understand > > SRTP or this key exchange mechanism. > > Done. > > " > > - "Answerers SHOULD use this UPDATE mechanisms." > > Change "mechanisms" to "mechanism". > > - "the assurances of DTLS-SRTP provides " > > Change to: > > "the assurances that DTLS-SRTP provides" > ^^^^ > > Done. > > > John > > > > > > Hannes Tschofenig: > > A few random comments: > > > > The fingerprint alone protects against active attacks on > the media > > but not active attacks on the signalling. In order to > prevent active > > attacks on the signalling, in Enhancements for > Authenticated Identity > > Management in SIP [RFC4474] is used. > > > > I believe we should indicate that SIP Identity >>may<< be used. > > Done. > > > > When Bob receives the offer, > > Bob establishes a mutually authenticated DTLS connection > with Alice. > > > > It is not really mutually authenticated at this point in time. > > Something like > > " > > When Bob receives the offer, > > Bob initiates a DTLS exchange with Alice. > > " > > > > At this point Bob can begin sending media to Alice. > Once Bob accepts > > Alice's offer and sends an SDP answer to Alice, Alice can begin > > sending confidential media to Bob. > > I rewrote this a little differently. > > > > > > We would have to assume symmetric RTP (which is only recommended by > > draft-ietf-avt-dtls-srtp) here to allow Alice to send media > immediately > > after the DTLS handshake. Otherwise we may need another > DTLS handshake > > before Alice can send media to Bob. > > I think the new text covers this. > > > > I was actually wondering why not to mandate symmetric RTP > given that the > > number of exchanges are much lower. > > the consensus in AVT was not to do so. > > > Alice and Bob will verify the > > fingerprints from the certificates received over the > DTLS handshakes > > match with the fingerprints received in the SDP of the > SIP signaling. > > This provides the security property that Alice knows > that the media > > traffic is going to Bob and vice-versa without > necessarily requiring > > global PKI certificates for Alice and Bob. > > > > > > o When RFC 4474 Identity is used, this solution works > even when the > > SIP proxies downstream of the identity service are > not trusted. > > > > We could provide a pointer to the security considerations section, > > namely Section 8.6. > > I provided a pointer. > > > > A pointer to RFC 4916 ("Connected Identity"), even though I do not > > consider it as too important based on the scenarios it > addresses, would > > not hurt here. > > Maybe something like would help: > > "Retargeting of a dialog-forming request (changing the value of the > > Request-URI), the UA that receives > > it (the User Agent Server, UAS) can have a different > identity from > > that in the To header field. When RFC 4916 is used then it is > > possible to supply its identity to the peer UA by means of > a request in > > the > > reverse direction, and for that identity to be signed by an > > Authentication Service. > > " > > Added. > > > > There is no need to reveal keys in the SIP signaling > or in the SDP > > message exchange. In order for SDES and MIKEY to provide this > > security property, they require distribution of > certificates to > > the endpoints that are signed by well known certificate > > authorities. > > > > > > I believe we should delete the last sentence since we > provide a detailed > > discussion of SDES and MIKEY in the media security requirements > > document. > > > Removed. > > > Section 5 > > > > The far endpoint (answerer) may now establish a mutually > > authenticated DTLS association to the offerer. > > > > > > The same comment from above applies since at this stage > there two end > > points aren't mutually authenticated yet. > > > > > > o If the fingerprint does not match the hashed > certificate then the > > endpoint MUST tear down the media session immediately. > > > > Tentatively establishing a session and tearing it down if the > > fingerprint doesn't match is one possible strategy. > Alternatively, the > > offerer could wait for an answer with the fingerprint and > subsequently > > execute the DTLS handshake and cancel the handshake and the session > > establishment immediately if the cert used in the handshake does not > > match the fingerprint. > > I added some material. > > > > This would obviously delay the establishment of the secure channel. > > Particularly for early media this would mean that media is > unprotected. > > Early media will, however, be tough anyway. > > > > I don't have a strong opinion on the two approaches but I believe we > > should mention the DoS potential in the security > consideration section. > > I don't see that there is any signifciant DoS potential. Can you > provide some text? > > > > > > 6.5. Session Modification > > > > Once an answer is provided to the offerer, either endpoint MAY > > request a session modification which MAY include an > updated offer. > > This session modification can be carried in either an INVITE or > > UPDATE request. Once the answer is received, the active endpoint > > will either reuse the existing association or establish > a new one, > > tearing down the existing association as soon as the offer/answer > > exchange is completed. > > > > > > I think we need to differentiate the case where the SDP changes only > > slightly, for example, a change in codec vs. the case where, for > > example, an IP address changes. > > Hence, in some cases creating a new association might not even be > > possible. > > I added some text. > > > > Section 7: > > > > The SIP signaling from Alice to her proxy is transported > over TLS to > > ensure an integrity protected channel between Alice and > her identity > > service. Note that all other signaling is transported > over TCP in > > this example although it could be done over any > supported transport. > > > > I guess we should also say that the communication between the SIP > > proxies is protected someone, specifically when SIP > Identity (or other > > security mechanisms) is not available. > > I added some text. > > > > This shows the initial INVITE from Alice to Bob > carried over the > > TLS transport protocol to ensure an integrity > protected channel > > between Alice and her proxy which acts as Alice's identity > > service. Note that Alice has requested to be either > the active or > > passive endpoint by specifying a=setup:actpass. Bob > chooses to > > act as the DTLS server and will initiate the session. > Also note > > that there is a fingerprint attribute on the 'c' line > of the SDP. > > This is computed from Bob's self-signed certificate. > > > > Shouldn't this be Alice's self-signed cert, as shown in the > subsequent > > exchange. > > Fixed. > > > > At this point, Bob can begin sending early media (RTP > and RTCP) to > > Alice. Note that Alice can't yet trust the media since the > > fingerprint has not yet been received. This lack of trusted, > > secure media is indicated to Alice. > > > > At the last sentence we should indicate that this > indication is part of > > the user interface rather than something that is meant to > be part of the > > protocol exchange. > > Fixed. > > > Section 8: Security Considerations > > > > > > Other mechanisms, such as the S/MIME mechanism described > > in RFC 3261, or the mechanisms described in > > [I-D.wing-sip-identity-media] or [I-D.fischer-sip-e2e-sec-media], > > could also serve this purpose. > > > > > > I believe we should just mention S/MIME and SIP CERT rather than > > individual drafts that may not go anywhere. > > I've removed this, but I have no strong position so I'll put > it back in > if people object. > > > > Section 8.2: > > > > > > This sentence is a bit tough to read: > > > > If SIP Identity is not used, but the signaling is > protected by SIPS, > > the security guarantees are weaker, but some security is still > > provided as long as all proxies are trusted, this > provides integrity > > for the fingerprint. > > > > > > Suggest to break it into 3 sentences: > > > > If SIP Identity is not used, but the signaling is > protected by SIPS, > > the security guarantees are weaker. Some security is still > > provided as long as all proxies are trusted. This > provides integrity > > for the fingerprint in a chain-of-trust security model. > > Done. > > > > It does not provide a strong assertion of who > > Alice is communicating with. However, as much as the > target domain > > can be trusted to correctly populate the From header field value, > > Alice can use that. The security issue with this > approach is that if > > one of the Proxies wished to mount a man-in-the-middle attack, it > > could convince Alice that she was talking to Bob when really the > > media was flowing through a man in the middle media > relay. However, > > this attack could not convince Bob that he was taking to Alice. > > > > > > I believe that this last paragraph does not provide a lot > of value given > > that SIPS fits into the chain of trust security model and hence, by > > definition, you have to trust the proxies. If the proxies > are, for some > > reason, not trustworthy anymore than there is a problem. > > I trimmed this down quite a bit. > > > > 8.3. S/MIME > > > > > > I would delete the last sentence from that section, namely > > " > > However, so far there have been no deployments of S/MIME > > for SIP. > > " > > > > Reason: The problem is not really S/MIME as such. The > problem is how to > > distribute the certificates. This problem has, however, > been tackeled > > with SIP CERT and hence the situation may look different in > a few years. > > Additionally, one could argue of lack of deployment of > other security > > mechanisms as well. > > Removed. > > > 8.5. Short Authentication String > > > > DTLS does not natively support > > this mode, however it would be straightforward to add > one as a TLS > > extension [RFC3546]. > > > > I would delete the term "straightforward" and say something like > > " > > DTLS does not natively support > > this mode. Based on the level of deployment interest a TLS > > extension [RFC3546] could provide support for it. > > " > > > > Reason: There has not been a lot of interest in this > mechanism lately. > > Hence, I am not sure whether there is actually a lot > interest from the > > community. > > Done. > > > > Additionally, it might be useful to indicate that this > mechanism only > > helps when you actually know the person's voice. This fits to some > > communication patters. When you know your communication > partners already > > out-of-band then things are a lot easier anyway. > > For those cases where this is not true things get more > complicated. For > > example, how do I know that I talk to a person at my bank, insurance > > company, car dealer, travel agency, help desk, etc.? One > may not know > > the voice of these folks. > > Added some material. > > > > Appendix A: > > > > A.4. Clipping (R-AVOID-CLIPPING) > > > > Because the key establishment occurs in the media plane, > media need > > not be clipped before the receipt of the SDP answer. > > > > > > I believe we should indicate that in this case the early > media is not > > secured. > > That's not 100% accurate. I've added clarifying text. > > > > A.7. (R-SIG-MEDIA, R-ACT-ACT) > > > > > > It might be good to indicate that the interaction between > the UA and the > > authentication service needs to be secured as well and that the > > authentication service is responsible for executing proper > > authentication of the user. > > Done. > > > > A.8. Binding to Identifiers (R-ID-BINDING) > > > > We should weaken the language a bit to indicate that other > mechanisms, > > such as SIP CERT and S/MIME may also be used and not only > SIP Identity. > > Done. > > > > A.11. RTP Validity Check (R-RTP-VALID) > > > > We should also mention STUN packets by referencing Section 5.1.2 of > > http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp-03 > > Done. > > > > A.15. Denial of Service Vulnerability (R-DOS) > > > > DTLS offers some degree of DoS protection particuarly as > a built-in > > feature. > > > > > > > > A.16 is already covered by A.7. I would delete it. > > > Done. > > > > A.18: Maybe we should add one more sentence: "RFC 4474 is able to > > prevent an active attacker on the signalling path to > downgrade the call > > from SRTP to RTP." > > Done. > > > > A.22. Interworking with Intermediaries (R-TRANSCODER) > > > > " > > A description of the interworking with Session Border > Controllers is > > described in this document. > > " > > > > The interworking with SBCs is covered in > > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-media-pa > th-middleb > > oxes-01.txt > > > > However, as the text of interworking is written in > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-media-secur > ity-requir > > ements-07.txt > > the transcoder needs to have access to the keying material > and therefore > > the description from A.21 on media recording (and key disclosure) is > > applicable here as well. > > > I added a short amount of text. > > > > A.23. PSTN Gateway Termination (R-PSTN) > > > > The DTLS-SRTP framework allows the media security to > terminate at a > > PSTN gateway. This does not provide end-to-end security, but is > > consistent with the security goals of this framework because the > > gateway is authorized to speak for the PSTN namespace. > > > > > > There are several scenarios that would have to be discussed in this > > context; they are described in Section 3 of > > draft-schwartz-sip-e164-ownership-01.txt, namely > > * IP-IP Case (not relevant to Section A.23 although E.164 > numbers are > > used). > > * IP-PSTN-IP Case > > * PSTN-to-IP Case > > * IP-to-PSTN Case > > > > The problems are slightly different for each of these > cases. However, as > > most folks would probably agree the security of all these cases is > > rather weak (or at least unpredictable). > > > > I wonder how to best treat this subject but it may not hurt > to describe > > the issues in more detail in the appendix. Text is already > available -- > > hence it would be more of a copy-and-paste operation. > > I think this is actually contentious enough that I'd rather not > get into it, since this is just about media-security-requirements > compliance. > > > > There are two requirements that have not been discussed: > R-ALLOW-RTP and > > R-HERFP. > > > > "R-ALLOW-RTP: DTLS-SRTP allows RTP media to be received by > the calling > > party until SRTP has been negotiated with the answerer, > after which SRTP > > is preferred over RTP. > > " > > > > Here is first try: > > " > > R-HERFP: The Heterogeneous Error Response Forking Problem > (HERFP) is not > > applicable to DTLS-SRTP since the key exchange protocol > will be executed > > along the media path and hence error messages are communicated along > > this path and proxies do not need to progress them. > " > > I added this text. > > > > Dan Wing: > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Dean > > Willis > > > Sent: Wednesday, July 23, 2008 1:26 AM > > > To: SIP IETF > > > Cc: Cullen Jennings > > > Subject: [Sip] WGLC on DTLS Framework > draft-ietf-sip-dtls-srtp-framework-02 > > > > > > > > > I'm happy to announce a Working Group Last Call on the > > > standards-track DTLS Framework document: > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-sip-dtls-srtp-f > ramework-02.txt > > > > > > I'd like to conclude this WGLC by Friday, August 8, 2008. > > > > > > Please review the document and send any comments to the list and > > > author Eric Rescorla. > > > > I'm happy to see this finally WGLC'd, too! > > > > > > > > Overall: > > > > The framework document needs to require endpoints send and > > receive ietf-mmusic-sdp-capability-negotiation. Without support > > for that draft, many of the media security requirements cannot be > > met (as mentioned in A.1 of draft-ietf-sip-dtls-srtp-framework-02). > > ietf-mmusic-sdp-capability-negotiation should be promoted > > to a normative requirement, and should be required (MUST) for > > endpoints to support in order to adhere to the DTLS-SRTP > framework. > > Otherwise, we are hosed for forking and hosed for retargeting. > > Agreed. Added. > > > > > Section 1, Introduction: > > > > However, even hop-by-hop security such as provided by > SIPS provides > > some protection against modification by attackers who > are not on the > > signalling path. > > > > With or without SIPS, if the attacker is off the signalling > path, the > > attacker has little hope of doing much damage -- they need to > > guess a lot of SDP values and guess a bunch of SIP values (call-id) > > in order to be successful. > > > > So, I would replace the last phrase with: > > > > "... who are not in control of on-path signaling elements." > > > > resulting in: > > > > However, even hop-by-hop security such as provided by > SIPS provides > > some protection against modification by attackers who are not in > > control of on-path signaling elements." > > Done. > > > > Section 5, Exchanging Certificates: > > > > (the text exceeds the section title when it goes beyond just what > > happens with certificate exchange; perhaps consider re-titling). > > > > My slightly more substantive comment is: > > > > The answerer SHOULD use the setup attribute value of > > setup:active and will send the client_hello in the media path." > > ^^^^ > > MUST > > Refined to match your comments and Peter's. > > > > Section 6.6, "ICE Interaction": > > > > ... > > If ICE is not being used, then there is potential for a bad > > interaction with SBCs via "latching", as described in > > [I-D.ietf-mmusic-media-path-middleboxes]. In order to avoid this > > issue, if ICE is not being used and the DTLS handshake has not > > completed, upon receiving the other side's then the > passive side MUST > > ^ > > SDP > > > > do a single unauthenticated STUN [I-D.ietf-behave-rfc3489bis] > > connectivity check in order to open up the appropriate pinhole. > > > > > > Requirements to do something when ICE is *not* being used > should not be in a > > section titled "ICE Interaction". I would move this > paragraph describing how > > to handle SBC 'latching' to its own section perhaps titled > "SBC Interaction". > > Done. > > > > Section 8.6, > > > > o When phone number URIs (e.g., > > 'sip:[EMAIL PROTECTED]') are used, > > > > I believe the current consensus is that a phone number would include > > ;user=phone, so the example should be > > sip:[EMAIL PROTECTED];user=phone > > Done > > > > Section 8.6, "Limits of Identity Assertions" > > > > (This section is well written.) > > > > > > Implementors should therefore take care not to indicate > > misleading peer identity information in the user > interface. e.g. If > > ^^^^^^ > > formatting > error around here > > the peer's identity is > sip:[EMAIL PROTECTED], it is > > not sufficient to display that the identity of the peer as > > +17005551008, unless there is some policy that states > that the domain > > "chicago.example.com" is trusted to assert E.164 numbers. > > > > chicago.example.com only needs to be trusted to assert > numbers you trust > > it to assert -- not a blanked "to assert E.164 numbers". > For example, > > I might trust, and expect, Verizon to claim E.164s that it owns, but > > I do not trust, nor expect, Verizon to claim an E.164 with a +353 > > country code. > > > > I would revise the above to end with something like: > > > > ... unless there is some policy that states that the domain > > "chicago.example.com" is trusted to assert the E.164 number > > is it asserting. > > ^^^^^^^^^^^^^^^ > > Done. > > > > later, > > > > Otherwise, the recipient cannot rely on the RFC 4474 Identity > > assertion and the UA MUST not indicate to the user that > a secure call > > ^^^^^^^^ > > MUST NOT > > has been established to the claimed identity. > Implementations which > > are configured to only establish secure calls SHOULD > terminate the > > call in this case. > > Done. > > > > Section A.3: > > > > > > add a reference to draft-ietf-avt-dtls-srtp-03.txt > > which describes how session resumption is supposed to be > > implemented. > > Done. > > > > > Section A.12., "3rd Party Certificates (R-CERTS, R-EXISTING)" > > > > Third party certificates are not required. However, if > the parties > > share an authentication infrastructure that is > compatible with TLS > > (3rd party certificates or shared keys) it can be used. > > > > > > RFC4474 is part of the framework for securing DTLS-SRTP, and > > as you know there is a lot of consternation around this point. > > Citing section 13.4 of RFC4474 would be helpful, because section > > A.12 of sip-dtls-srtp-framework relies on the following small > > sentence in Section 13.4 of RFC4474: > > > > It > > is strongly RECOMMENDED that self-signed domain > certificates should > > not be trusted by verifiers, unless some previous key > exchange has > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > justified such trust. > > ^^^^^^^^^^^^^^^^^^^^ > > I added a reference. > > > > Section A.15, Denial of Service Vulnerability (R-DOS) > > > > Please add a reference to Section 4.2.1 of RFC4347. > > Done. > > > > > Section A.18., "Downgrading Protection (R-DOWNGRADE)" > > > > DTLS provides protection against downgrading attacks since the > > selection of the offered ciphersuites is confirmed in a > later stage > > of the handshake. This protection is efficient unless > an adversary > > is able to break a ciphersuite in real-time. > > > > This should also mention integrity protection of signaling is > > necessary in order to prevent downgrade to RTP (because I believe > > we need to require sdp-capability-negotiation for all of this to > > work correctly.) > > Agreed. added some text per this and Hannes's comments. > > > > > > Peter Schneider: > > > > > > 1) The draft currently states in section 5: > > > > " The endpoint MUST use the setup attribute defined in > [RFC4145]. > > The endpoint which is the offerer MUST use the setup attribute > > value of setup:actpass and be prepared to receive a > client_hello > > before it receives the answer. The answerer SHOULD > use the setup > > attribute value of setup:active and will send the > client_hello in > > the media path." > > > > My proposal is to replace the last sentence by "The > answerer MUST use > > the setup > > attribute value of setup:active or the setup attribute value of > > setup:passive." > > I set this to MUST use both but with active as recommended. > > The answerer MUST use either a setup attribute value of > setup:active or setup:passive. Note that if the answerer uses > setup:passive, then the DTLS handshake will not begin until > the answerer is received, which adds additional > latency. setup:active allows the answer and the DTLS handshake > to occur in parallel. Thus, setup:active is RECOMMENDED. The > active party MUST send the ClientHello in the media path. > > I think this is the best compromise. There's really no advantage > to being passive. > > > > With this, if the receiver takes up the active role, as > recommended in > > the original text, he can start the handshake and if the > handshake has > > been carried out successfully before the SDP answer, he can send > > encrypted early media (before the SDP answer). Obviously, > with the usage > > of self signed certificates, the offerer can authenticate > the origin of > > the early media only retrospectively, after he has received the SDP > > answer, which somewhat reduces the value of encrypting the > early media. > > Early media as well as a handshake at that point in time > will however > > not work in an environment, where middleboxes are present > that will not > > let traffic pass in the media plane before the answer has been sent. > > > > So if the receiver assumes such an environment, he may > decide to take up > > the passive role. By this, the offerer will start the > handshake as soon > > as he receives an answer, which would typically be close to > the first > > point in time at which the handshake messages will be able > to pass the > > middleboxes. > > > > I feel it's quite reasonable to do the handshake after > offer and answer > > have been exchanged, because the offerer can check the > fingerprint of > > the certificate received in the handshake immediately; and > he will not > > accept encrypted media that may be sent by an attacker. So > he is less > > vulnerable to DoS. This does not allow encrypted early media to be > > received, but is this so essential? In fact, accepting only > encrypted > > early media could be harmful, as it would prevent a caller > to receive > > e.g. an announcement that is sent by some server in the network that > > only sends unsensitive announcements and therefore does not support > > encryption at all. > > I think this is covered in the security considerations section. > > I don't really understand what DoS issue you're concerned about. > > > > > 2) With respect to unmanaged (e.g. residential) stateful > firewalls the > > draft currently states in section 6.6 that if ICE is not > used and the > > handshake could not be completed (until offer and answer have been > > exchanged) > > > > "the passive side MUST > > do a single unauthenticated STUN [I-D.ietf-behave-rfc3489bis] > > connectivity check in order to open up the appropriate > pinhole. All > > implementations MUST be prepared to answer this request during the > > handshake period even if they do not otherwise do ICE." > > > > And later, in the message flow on page 13 and the respective > > explanations it becomes obvious that the idea is that the > sender of this > > STUN connectivity check in fact waits for an answer before > he proceeds > > That's not intended at all. They're done in parallel. > > > > (although implementations must only *be prepared* to answer a > > connectivity request - I wonder whether "be prepared" > should rather be > > removed from this sentence). However, if there are > middleboxes on the > > path that block the STUN connectivity check, an answer will > never come, > > although the purpose of the connectivity check - to > establish a session > > in the residential firewall and open it up for incoming > traffic - may > > already have been achieved. > > > > So instead of making the sending of the STUN connectivity check > > mandatory in this situation, I propose rather to recommend that the > > passive UA in the connection setup should try to make sure that a > > firewall protecting the UA does not block the client hello > starting the > > handshake. This could be done by STUN or other means. This > is exactly > > what is recommended also in > draft-ietf-mmusic-media-path-middleboxes-01, > > section 7, REC #1. > > I think IETF general policy is to prefer ICE, which is what you > would do here. This is a stopgap. > > > > 3) More generally, I propose that the draft should mention possible > > problems with middleboxes, and should advise implementors > to follow the > > recommendations in draft-ietf-mmusic-media-path-middleboxes. > > I don't want to create a normative reference, but I added a > section that points at that and states it has recommendations. > > > > 4) Concerning the possible sequence of messages used to establish > > sessions that use DTLS-SRTP, the draft IMO should give clearer > > recommendations. This is currently mostly treated in the section > > "example message flow", which indeed explains two flows > currently. It is > > unclear, to which degree this is normative, and what > variants of such > > flows would also be considered compliant to the draft. > > I went through and tried to add some clarifying text where I thought > appropriate. That said, since TLS allows inband negotiation and > there is some inherent reordering due to the use of multiple parallel > flows, a lot of different variants are legal. Is there some particular > point you want clarified? > > > > 5) Another topic where information is only given in the > example flows is > > the treatment of RTCP. If RTP/RTCP multiplexing on a single > port is not > > used, at which time should the handshake for RTCP be done - > immediately > > after the handshake for RTP, so that sender reports could > be sent for > > early media? Or only after the SDP answer, when both sides > know which > > ports are used on both sides? This becomes even more complex, if > > non-symmetric RTP/RTCP would be applied, which is not excluded in > > draft-ietf-avt-dtls-srtp-02. > > I propose to describe these issues in a dedicated section. > > I added some text and referenced the AVT draft which talks about > the performance issues. > > -Ekr > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
