Subject: [sipcore] SIPCORE Minutes, IETF89, March 2014

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Mar 2014 17:37:00 -0400

The raw notes from the SIPCORE sessions, along with a summary of 
conclusions and action items have been posted for the IETF89 
proceedings. You can find them at:

https://datatracker.ietf.org/secr/proceedings/89/sipcore

I've included the summary below. Please note the action items!

	Thanks,
	Paul

=================== Conclusions & Action Items  ===================

* Errata on 3325:

Conclusion: No objection to interpretation given by chairs.

Action: Agree to clarify that it is allowed, but not required, to 
interpret these characters when not enclosed in <>.

* draft-johansson-dispatch-dane-sip:

Conclusion: Few present understood the issue. Many were confused.

Action: Olle to send use cases to the list.

* draft-yusef-sipcore-digest-scheme:

Conclusion: Don't fix Digest, fix Authentication

Action: Those who think fixing digest is insufficient should send use 
cases to the sipcore mailing list.

* draft-johansson-sip-dual-stack

Action: split the action item into two: one for the DNS part, and 
another for the remainder of Happy Eyeballs. Discuss the milestone text 
on the list.

Action: call for adoption of draft-johansson-dispatch-dane-sip on the 
list for the DNS part.

* RFC 6665 Dialog Re-Use with REFER

Conclusion: Much objection to need for GRUU to solve this problem.

Action: Robert Sparks and Adam Roach to write a new draft updating 
RFC3515 (REFER) for consistency with RFC6665.
Action: Continue discussion on list. (Especially those who object to 
described approach.)

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 22 Mar 2014 08:33:02 +0100

On 21 Mar 2014, at 22:37, Paul Kyzivat <[email-masked]> wrote:

> The raw notes from the SIPCORE sessions, along with a summary of conclusions and action items have been posted for the IETF89 proceedings. You can find them at:
> 
> Action: Agree to clarify that it is allowed, but not required, to interpret these characters when not enclosed in <>.
> 
I don't think the confusion was about use cases at all or whether we need DANE or not - it was about whether the DANE group documents was enough,
if this is just a bump in the TLS stack or if we actually need to do something in SIPcore. Some people claimed
we need to do zero, nothing, nada. Some people (including me) claims we do need to document this,
especially since the SIP Domain certificate RFC is an update to RFC 3261 and DANE usage changes
the certificate contents.

The DANE group is very clear that we do need to document our usage. Wes Hardaker pointed that out
several times during the discussion. It's documented in the DANE SRV drafts too.

> Action: Those who think fixing digest is insufficient should send use cases to the sipcore mailing list.
> 
> Action: split the action item into two: one for the DNS part, and another for the remainder of Happy Eyeballs. Discuss the milestone text on the list.
> 
> Action: call for adoption of draft-johansson-dispatch-dane-sip on the list for the DNS part.
Our draft only includes the DNS part so the full draft can be adopted as is. THere's no draft covering the Happy Eyeballs part yet.

/O

> Action: Robert Sparks and Adam Roach to write a new draft updating RFC3515 (REFER) for consistency with RFC6665.
> Action: Continue discussion on list. (Especially those who object to described approach.)
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 23 Mar 2014 15:58:30 -0400

> several times during the discussion. It's documented in the DANE SRV drafts too.

OK. Maybe "use cases" isn't a proper characterization of what we need.
But clearly we have a problem around lack of understanding. And it isn't 
entirely clear exactly *what* people lack an understanding of.

My guess is that we have people with a range of understandings of DANE. 
And so a range of understandings of what we need to do.

IMO the starting point is to clarify why DANE is important to SIP. I see 
a couple of reasons, neither specific to sip, but relevant to sip:
- reliance on DNSSEC is more trustworthy than reliance on CAs
- server certificates are more easily managed than domain certs

I think your draft would benefit by having a section specifically 
addressing this. But it might be helpful to have some list discussion on 
it before you update the draft.

Once we get past "why DANE?", we then get to "what do we need to do 
before we can use DANE with sip?" Your draft addresses that, but 
obviously some people disagree on how much needs to be specified, and 
how much can be had by reference to existing generic documents. I doubt 
that big changes are needed in what you have already for this, but maybe 
it can be clarified to address the concerns that were raised - to make 
it crystal clear. Referencing the the explicit places where the generic 
DANE documents say that we must document the sip-specific usage would 
help here.

Does this match your understanding of what happened?
If so, I'll tweak the actions to agree.

	Thanks,
	Paul