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-path-middleb
> oxes-01.txt
>
> However, as the text of interworking is written in
> http://www.ietf.org/internet-drafts/draft-ietf-sip-media-security-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-framework-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
