Subject: [Sip] New version of draft-ietf-sip-dtls-srtp-framework

From: Eric Rescorla <[email-masked]>
Date: Tue, 26 Aug 2008 15:05:39 -0700

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-masked]') 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-masked]' or
> 'sip:[email-masked];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-masked] [mailto:[email-masked]] 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-masked]') are used, 
> 
> I believe the current consensus is that a phone number would include
> ;user=phone, so the example should be
> sip:[email-masked];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-masked], 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 27 Aug 2008 14:28:49 +0100

Eric,

Thanks. The new draft takes care of my comments.

John 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eric Rescorla
> Sent: 26 August 2008 23:06
> To: [email-masked]
> Subject: [Sip] New version of draft-ietf-sip-dtls-srtp-framework
> 
> >    the peer's identity is 
> sip:[email-masked], it is
> > what is recommended also in 
> draft-ietf-mmusic-media-path-middleboxes-01,
> > section 7, REC #1.
>