Re: [dispatch] Question about draft-johansson-dispatch-dane-sip-00.txt

["Olle E. Johansson" <[e-mail]>]

On 08 Jan 2014, at 20:02, Cullen Jennings (fluffy) <[e-mail]> wrote:

> 
> I'm a bit confused about if this differs from the procedures specified in http://tools.ietf.org/html/draft-ietf-dane-srv
> 
> 1) I was assuming that all we need to do for DANE in SIP was more or less make a draft which is an extension to 3261 (and not a modification of 3261) that said do what draft-ietf-dane-srv says. So when I read the normative parts of text of draft-johansson-dispatch-dane-sip I have a hard time deciding if is saying to do something different than draft-ietf-dane-srv or not. Can you help make this clear?
I need to go back and compare and maybe remove parts that are overlapping. On the other hand I want to have a document that is very clear for SIP developers. I guess the only difference is the way we start with a SIP uri domain part to look up the SRV.

Remember that I'm still a newbie in this document-writing space :-)

The "updates 5922" part will be removed in a coming edition of this draft. It's a misunderstanding on my behalf.

> 
> I would prefer to see the draft crisply separated into what the normative part of the draft is and what is gnarly tutorial but actually specified in other specifications. 
ok.
> 
> 
> 2) Lets say we have a domain example.com that is happily doing SIP with TLS with a normal cert. But an attacker managed to insert a DNS SRV record that points example.com to a host at attacker.com and get all the DNS signed for that. The host at attacker.com does have the private key for the certificate at example.com. 
> 
> In this case, my understanding of your draft is the attack successes and the DANE enabled client would successfully connect to attacker.com. Do I have this right and does this match up with assumptions on how DANE will be be deployed and used ? I'm not arguing this one way or other yet, I just want the draft to be very clear and help people understand. 
Well if attackers can insert records and get them signed, then the hole assumption of DANE being a secure platform falls on its head. It's like saying "If an attacker can get a certificate for fluffy.com signed by a well-known CA then people will trust the attackers web site to be owned by fluffy." Yes. And btw, that has happend...
That's one of the target scenarios that DANE is trying to stop by being able to specify the CA used for a service in a domain in the signed zone.

I guess we will have to look at DNS updates and how they're being signed at some point. But that's out of scope for this group.
> 
> 
> BTW - thanks for working on this. We've needed a DANE SIP draft for a long time. I would guess that this will all end up in sip core but glad to discuss it here in meantime. 
Your welcome.

/O
> 
> 
> Cullen
>