Subject: [dispatch] Review of draft-johansson-dispatch-dane-sip-01

From: Dave Cridland <[email-masked]>
Date: Thu, 6 Feb 2014 23:02:47 +0000

Olle,

Richard Barnes asked me to read this one over. Sorry to be the harbinger of
doom, here - I'll buy you a pint in London.

draft-johansson-dispatch-dane-sip-01

TL;DR: I'm not convinced that this document should be adopted or taken
further. The reason is that much of what is discusses is actually already
covered by RFC 6125, as (hopefully to be) updated by draft-ietf-dane-srv.
Energy should be redirected to either dane-srv, or a revision of RFC 6125,
or both.

Issues (some of which minor):

1) It appears to discuss only server authentication by an end-user client,
and not mutual peer authentication of servers. I suspect both are important
in SIP (as they are in XMPP).

2) It conflates DANE (which provides constraints on certificates) with
DNSSEC (which allows a validating party to use additional reference
identifiers securely as in RFC 6125 § 6.2.1, as well as providing security
for TLSA records).

3) It refers to the AD flag as a definitive guide to the security (in the
sense of DNSSEC) of a DNS RR, whereas I thought a client actually has to
either check the signatures locally (and essentially disregard this flag)
or else have a secure link to a trusted resolver (largely impossible,
perhaps loopback).

4) "CNAME" is used without expansion in a document describing both DNS and
X.509.

5) It's not using the terms of art established in RFC 6125.

This is not to say the document is not valuable - it's sufficiently
valuable that we have an RFC covering this area and a further draft
expanding upon it - the subject matter is clearly important.

I personally think RFC 6125 is very useful, but it might warrant a revisit
once DANE-SRV is complete, and I would encourage the author to place any
remaining energy in that direction, as well as DANE-SRV itself. This should
apply to not only SIP, but other protocols too, and therefore be of wider
benefit.

As it stands, the draft already restates some of RFC 6125, but lacks much
of the depth and coverage - entirely understandable in an early stage
draft, but it does suggest there's a lot of work to be done, and the work
has been done already. The additional discussion of TLSA records this draft
has would - one hopes - be covered by DANE-SRV.

It is possible that between the two documents there may be some SIP
specific information that implementors would find useful; in particular RFC
6125 is fairly light in discussion of NAPTR records, for instance. But I
suspect a document filling those gaps might only need to be an
informational document providing better examples, or else would be better
folded into an update to (or revision of) RFC 6125.

(Please explicitly copy me on responses; I am not subscribed to the
dispatch mailing list)

Dave.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 7 Feb 2014 09:40:58 +0100

On 07 Feb 2014, at 00:02, Dave Cridland <[email-masked]> wrote:

> Olle,
> 
> Richard Barnes asked me to read this one over. Sorry to be the harbinger of doom, here - I'll buy you a pint in London.
Thank you for doing this. There has been very little discussion about it, a few questions about backwards compatibility and a lot of support for doing something. I look forward to a good Ale with you in London!

> TL;DR: I'm not convinced that this document should be adopted or taken further. The reason is that much of what is discusses is actually already covered by RFC 6125, as (hopefully to be) updated by draft-ietf-dane-srv. Energy should be redirected to either dane-srv, or a revision of RFC 6125, or both.
Well, obviously I am. Note that I'm new in the IETF draft-writing business, so there's a lot of stuff to do with the document as you clearly say. I got to a point when I was asking myself why no one was doing anything and got surprised one morning when I realised that no one was me, myself and I. 

The issue at hand is not really RFC 6125 but RFC 5922 that updates RFC 3261. That document clearly defines how to verify a TLS server certificate with a given SIP URI using domains. The DANE srv goes against this and goes back to SRV host names in the certificate. I wanted to write a document that documents an alternative to 5922 for SIP developers and also clearly defines how certificates can be constructed and how these can be or not be compatible with 5922. 

SIP and TLS has a long history of confusion and we need to clear that up. The DANE documents clearly
states that listing all the service names in the certificate is not viable for hosting situations and that we need
to change that practise. I agree with that.

Now is this document ends up as BCP, informative or actually will have normative changes to 5922/3261 in it's final form, I don't know. But I do want to defend production of a document in the RAI area to help already confused SIP implementors on where to go and point them towards the DANE document output.

In addition, as you know, the DANE wg charter clearly states that protocol specific issues, which I think that the potential issue with 5922 is, should not be handled by the DANE wg if there are working groups covering those protocols. (Just to explain to list readers why I submitted this to dispatch and not DANE).

> 1) It appears to discuss only server authentication by an end-user client, and not mutual peer authentication of servers. I suspect both are important in SIP (as they are in XMPP).
I attempted to start a discussion with Robert Sparks about how DANE can apply to SIP connection reuse and client auth in Berlin, but was in a clear RJS way told that DANE had nothing to do with client authentication. Well, it may not be DANE but end up as ENAD, but I do think that we can leverage on DNSsec here. I took it out of scope now since I heard from Robert's reaction that I propably should stick with server authentication for now... :-)
> 
> 2) It conflates DANE (which provides constraints on certificates) with DNSSEC (which allows a validating party to use additional reference identifiers securely as in RFC 6125 § 6.2.1, as well as providing security for TLSA records).
> 
> 3) It refers to the AD flag as a definitive guide to the security (in the sense of DNSSEC) of a DNS RR, whereas I thought a client actually has to either check the signatures locally (and essentially disregard this flag) or else have a secure link to a trusted resolver (largely impossible, perhaps loopback).
> 
> 4) "CNAME" is used without expansion in a document describing both DNS and X.509.
> 
Good feedback all of these. Let's work on that. I've already accepted an offer from Gonzalo Salguiero to co-author and help me clear up things like this. He has far more experience than me in using the right language. I just wanted to get the discussion started and get the topic into the proper wg.
> 
> This is not to say the document is not valuable - it's sufficiently valuable that we have an RFC covering this area and a further draft expanding upon it - the subject matter is clearly important.
Agree.
> 
> I personally think RFC 6125 is very useful, but it might warrant a revisit once DANE-SRV is complete, and I would encourage the author to place any remaining energy in that direction, as well as DANE-SRV itself. This should apply to not only SIP, but other protocols too, and therefore be of wider benefit.
I am following DANE-SRV as well as the SMIME work. The authors there are doing a fine job.
> 
> As it stands, the draft already restates some of RFC 6125, but lacks much of the depth and coverage - entirely understandable in an early stage draft, but it does suggest there's a lot of work to be done, and the work has been done already. The additional discussion of TLSA records this draft has would - one hopes - be covered by DANE-SRV.
I don't think the work has been done already. You are missing the issue with RFC 5922 that stands in the way.
> 
> It is possible that between the two documents there may be some SIP specific information that implementors would find useful; in particular RFC 6125 is fairly light in discussion of NAPTR records, for instance. But I suspect a document filling those gaps might only need to be an informational document providing better examples, or else would be better folded into an update to (or revision of) RFC 6125.
I am always in favour of helping implementors to navigate across the sea of drafts and RFCs that defines what we call the SIP protocol.

/O
> 
> (Please explicitly copy me on responses; I am not subscribed to the dispatch mailing list)
> 
> Dave.

---

From: Dave Cridland <[email-masked]>
Date: Fri, 7 Feb 2014 12:23:56 +0000

On Fri, Feb 7, 2014 at 8:40 AM, Olle E. Johansson <[email-masked]> wrote:

> > Richard Barnes asked me to read this one over. Sorry to be the harbinger
> of doom, here - I'll buy you a pint in London.
> Thank you for doing this. There has been very little discussion about it,
> a few questions about backwards compatibility and a lot of support for
> doing something. I look forward to a good Ale with you in London!
>
> >
> >
> Well, obviously I am. Note that I'm new in the IETF draft-writing
> business, so there's a lot of stuff to do with the document as you clearly
> say. I got to a point when I was asking myself why no one was doing
> anything and got surprised one morning when I realised that no one was me,
> myself and I.
>
> The issue at hand is not really RFC 6125 but RFC 5922 that updates RFC
> 3261. That document clearly defines how to verify a TLS server certificate
> with a given SIP URI using domains. The DANE srv goes against this and goes
> back to SRV host names in the certificate. I wanted to write a document
> that documents an alternative to 5922 for SIP developers and also clearly
> defines how certificates can be constructed and how these can be or not be
> compatible with 5922.
>
As an aside, this can be addressed using pure DNSSEC and the reference
identifier "gathering" discussed in RFC 6125 § 6.2.1 - the XMPP community
has been experimenting which this (see in particular Kim Alvefur's
"DANE-lite" work in the Prosody open-source XMPP server). There's also
POSH, which might well be applicable (draft-miller-posh-03), and uses a
different trust path to emulate something close to DANE, and is under
discussion within the XMPP working group.

DANE offers somewhat more, and more flexible, ways of specifying additional
reference identifiers and certificate constraints, but arguably for a SRV
based protocol - such as SIP or XMPP - DANE doesn't add much more to the
solution for mass-hosting providers than DNSSEC alone.

> Now is this document ends up as BCP, informative or actually will have
> normative changes to 5922/3261 in it's final form, I don't know. But I do
> want to defend production of a document in the RAI area to help already
> confused SIP implementors on where to go and point them towards the DANE
> document output.
>
> In addition, as you know, the DANE wg charter clearly states that protocol
> specific issues, which I think that the potential issue with 5922 is,
> should not be handled by the DANE wg if there are working groups covering
> those protocols. (Just to explain to list readers why I submitted this to
> dispatch and not DANE).
>
>
Right, I accept that RFC 5922 details issues that are specific to SIP, as
well as discussing more general issues. Having quickly whistled through RFC
5922, I further accept that a possibly updated RFC 6125 + DANE-SRV will
still fall short due to the SIP specific issues.

I think - and I could be *way* off here - that the primary specifics for
SIP are NAPTR lookups (which I don't really see well-covered in RFC 6125),
and authenticating a calling proxy (because - in the language of RFC 6125 -
the correct reference identifiers are largely unknown).

My gut feeling is therefore that the work needed is:

a) Complete DANE-SRV (draft-ietf-dane-srv), ensuring particular attention
is paid to the SIP cases.

b) An update to RFC 6125 to ensure knowledge about DNSSEC derivation of
additional reference identifiers is properly discussed, and (possibly)
better discussion of NAPTR lookup related issues.

c) A document which obsoletes RFC 5922, normatively references DANE-SRV and
RFC 6125bis, and builds upon those foundations to discuss SIP-specific
issues.

Does that seem like a reasonable work plan?

Dave.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 7 Feb 2014 14:36:16 +0100

On 07 Feb 2014, at 13:23, Dave Cridland <[email-masked]> wrote:

> As an aside, this can be addressed using pure DNSSEC and the reference identifier "gathering" discussed in RFC 6125 § 6.2.1 - the XMPP community has been experimenting which this (see in particular Kim Alvefur's "DANE-lite" work in the Prosody open-source XMPP server). There's also POSH, which might well be applicable (draft-miller-posh-03), and uses a different trust path to emulate something close to DANE, and is under discussion within the XMPP working group.
I am aware of that work.
> 
> DANE offers somewhat more, and more flexible, ways of specifying additional reference identifiers and certificate constraints, but arguably for a SRV based protocol - such as SIP or XMPP - DANE doesn't add much more to the solution for mass-hosting providers than DNSSEC alone.
I am not sure I agree with you here. Beer bof it is.
> Right, I accept that RFC 5922 details issues that are specific to SIP, as well as discussing more general issues. Having quickly whistled through RFC 5922, I further accept that a possibly updated RFC 6125 + DANE-SRV will still fall short due to the SIP specific issues.
> 
> I think - and I could be *way* off here - that the primary specifics for SIP are NAPTR lookups (which I don't really see well-covered in RFC 6125), and authenticating a calling proxy (because - in the language of RFC 6125 - the correct reference identifiers are largely unknown).
NAPTR is there and is used in many places, but most devices go for SRV directly.
> a) Complete DANE-SRV (draft-ietf-dane-srv), ensuring particular attention is paid to the SIP cases.
Yes. And possibly inject some SIP into DANE S/MIME.
> 
> b) An update to RFC 6125 to ensure knowledge about DNSSEC derivation of additional reference identifiers is properly discussed, and (possibly) better discussion of NAPTR lookup related issues.
Can't say much about that right now, will have to investigate and come back to you on that. Sounds fair.

> 
> c) A document which obsoletes RFC 5922, normatively references DANE-SRV and RFC 6125bis, and builds upon those foundations to discuss SIP-specific issues.
I do not think we can or should obsolete 5922. But we need an alternative and that needs to be documented just because 5922 updates RFC 3261.

> Does that seem like a reasonable work plan?
There is still room for discussion, but I think we now agrees that there is work to be done in the RAI area  too and that my draft is a starting point (but not the final document) for this work.

Greetings,
/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 7 Feb 2014 15:00:16 +0100

To add - the DANE srv draft says this:

"Separate documents describe how to apply this specification to
   particular application protocols.  If you are writing such as
   document the following points ought to be covered:"

What I tried to write was such as separate document... :-)

Section 6 of http://tools.ietf.org/html/draft-ietf-dane-srv-03

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Feb 2014 11:14:28 -0500

On 2/7/14 8:36 AM, Olle E. Johansson wrote:
[snip]
>> b) An update to RFC 6125 to ensure knowledge about DNSSEC derivation
>> of additional reference identifiers is properly discussed, and
>> (possibly) better discussion of NAPTR lookup related issues.
>> c) A document which obsoletes RFC 5922, normatively references
>> DANE-SRV and RFC 6125bis, and builds upon those foundations to discuss
>> SIP-specific issues.
> I do not think we can or should obsolete 5922. But we need an
> alternative and that needs to be documented just because 5922 updates
> RFC 3261.
>
>>
> There is still room for discussion, but I think we now agrees that there
> is work to be done in the RAI area  too and that my draft is a starting
> point (but not the final document) for this work.

+1

I have been pleased to see that someone has taken on the task of 
starting to figure out how to exploit DANE and DNSSEC for SIP. I know 
very little about DANE, but enough to see that it is probably important.

I'm also pleased that it isn't just Olle - that Dave is taking the role 
of devil's advocate here. And hopefully that will stimulate more debate. 
That should lead to the best result. (I'm getting more educated by 
following the draft and the debate.)

This is starting in dispatch because it wasn't immediately clear if it 
fell entirely in the scope of sipcore. I'm ok with it staying in 
dispatch until we figure out exactly what the scope of the required work is.

	Thanks,
	Paul