Subject: [Sip] Doc we need to have draft-ietf-sip-dtls-srtp-framework-01 on the -71 agenda?

From: Dean Willis <[email-masked]>
Date: Thu, 28 Feb 2008 12:07:50 -0600

Is there any need for discussion of the DTLS framework
(draft-ietf-sip-dtls-srtp-framework-01) during our meeting?

The authors think that it is pretty much ready for WGLC and that all
known issues have been resolved.

The list has been fairly quiet on the topic.

Anybody read the new version yet and have an opinion?

--
Dean
_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 28 Feb 2008 14:18:30 -0500

> known issues have been resolved.

I do not agree.

One of the points I raise in my rfc4474-concerns draft is that dtls-srtp 
is basing integrity of the fingerprint on 4474, and that 4474 does not 
provide integrity against intermediary modifications of the number, and 
even for user@domain names this can happen.

I think this needs to be called out in the draft. The security 
considerations section does not discuss this.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
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: Eric Rescorla <[email-masked]>
Date: Thu, 28 Feb 2008 11:30:46 -0800

At Thu, 28 Feb 2008 14:18:30 -0500,
> considerations section does not discuss this.

Because it's not a DTLS-SRTP issue. It's a SIP/4474 issue.

The fingerprint in the SIP messaging does *not* tie the DTLS-SRTP
handshake to the phone number or to the domain name. Rather, it ties
the media to the SIP signalling. Period. It allows whatever guarantees
you are prepared to assert about the signalling to be extended to
media. If those guarantees allow you to make assertions about the
caller (or callee) identity, then great.  If not, then DTLS-SRTP
doesn't help, nor is it intended to.

Look at it this way:
When the phone rings (or your UA shows you that the other side has
answered), it can show you some meta-information about who you're
talking to. The objections you have to RFC 4474 (and I'm not saying I
agree with them) already apply at this point, before a single RTP
packet has traversed the wire. This is not a DTLS-SRTP issue.

-Ekr

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 28 Feb 2008 20:14:00 +0000

Without a means of binding the secure media to the identity of the
remote party, DTLS-SRTP is not a complete solution. I don't think we can
say the framework is finished until we have that complete solution. In
particular, the framework uses RFC 4474 as part of the mechanism - if
the solution to the RFC 4474 problem turns out to be something different
from RFC 4474, the framework would be wrong.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Eric Rescorla
> Sent: 28 February 2008 19:31
> To: Jonathan Rosenberg
> Cc: [email-masked]; Dean Willis
> Subject: Re: [Sip] Doc we need to have 
> draft-ietf-sip-dtls-srtp-framework-01 on the -71 agenda?
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 29 Feb 2008 01:35:20 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
> Rescorla
> Sent: Thursday, February 28, 2008 2:31 PM
>
>

I don't think he's claiming it's a "DTLS-SRTP" protocol issue, it's an issue for draft-ietf-sip-dtls-srtp-framework-01.  Reading this draft it sure seems to me the draft makes claims rfc4474 can't live up to.  It's not a knock on the idea, just that some statements the draft makes need some clarification/softening or elaboration.  Not everyone reading it in the future lives and breathes this stuff as you do. :)

For example, the end of section 2 says:
   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.

That is not actually true.  In fact, it's not even true with perfect end-end rfc4474 - it requires rfc4916, afaik. (4474 only helps Bob, not Alice, right?)  But even then it doesn't mean "Alice" and "Bob" know it to be absolute.

Also section 8 says:
   As long as each side of the connection can verify
   the integrity of the SDP INVITE then the DTLS handshake cannot be
   hijacked via a man-in-the-middle attack.  This integrity protection
   is easily provided by the caller to the callee (see Alice to Bob in
   Section 7) via the SIP Identity [RFC4474] mechanism.

Well, rfc4474 doesn't actually provide integrity by the caller to callee, so clearly it can't be "easily" done using it.  I should also note that section 7, which is referenced there as the way to do this, actually says:
   The SIP signaling from Alice to her proxy is transported over TLS to
   ensure an integrity protected channel between Alice and her identity
   service.

That is also a nit error, in that the term "ensure" isn't right.  Using TLS from the UAC to proxy ensures you're using TLS from the UA to the proxy.  The proxy may or may not be the identity service, or may or may not be using TLS to your registrar, and your registrar may or may not be the identity service, and so on.

Also, section 8 does describe the weaknesses of other mechanisms to bind the media to signaling, such as section 8.2 on SIPS.  But it does not do so with regard to rfc4474.  That implies to the average RFC reader there are none.

-hadriel