Subject: Re: [Sip] WGLC on DTLS Framework draft-ietf-sip-dtls-srtp-framework-02

From: "Dan Wing" <[email-masked]>
Date: Wed, 23 Jul 2008 21:05:34 -0700

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

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

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

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

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

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

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.

Section A.3:  

add a reference to draft-ietf-avt-dtls-srtp-03.txt
which describes how session resumption is supposed to be
implemented.

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

Section A.15, Denial of Service Vulnerability (R-DOS)

Please add a reference to Section 4.2.1 of RFC4347.

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

-d

_______________________________________________
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