Subject: [dispatch] Fwd: DANE SRV draft and SIP

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 21 Apr 2013 13:25:35 +0200

Hi!

Looking at DANE for SIP, I mailed out some thoughts on the DANE mailing list. If we come to
the conclusion that RFC 5922 will need to be updated - will this work be done in Dispatch
or Dane or somewhere else?

DANE also has impacts on SIP Identity as an alternative discovery mechanism for
domain certificates (replacing HTTPS).

/O

Vidarebefordrat brev:

> Från: "Olle E. Johansson" <[email-masked]>
> Ämne: DANE SRV draft and SIP
> Datum: 21 april 2013 12:27:47 CEST
> Till: dane WG list <[email-masked]>
> Kopia: "Olle E. Johansson" <[email-masked]>
> 
> Hi!
> 
> Looking at the DANE SRV draft with my SIP eyes I realize that there's a lot of work to be done to get this
> to work with SIP. 
> 
> SIP has no StartTLS, we use NAPTR records to select transport. The NAPTR points to a SRV
> name that resolves into a set of host names.
> 
> The SIP Domain certificates RFC - http://tools.ietf.org/html/rfc5922 - specificies matching a 
> given SIP URI with a certificate. The matching is done on service domain either with 
> a ALT name URI, like sip:ietf.org or a DNS name, like ietf.org - but not the host name.
> 
> I personally agree with the policy in the DANE SRV draft that we should match on the
> SRV hostname used to get A/AAAA records when using DNSsec. For this to work,
> the path from the SIP URI over NAPTR to SRV and hostnames needs to be fully
> signed in and verified in the DNS. This is going to require an update to 5922.
> 
> The final question is how to handle this without SNI. The certificates for both
> DANE verification and RFC 5922 plus "old-style" verification with the sip
> domain in the CN seems like a complicated mess to manage.
> 
> Food for thought on a sunny Sunday.
> 
> The SRV draft is not clear on how to use Subject AltNames of various types,
> and doesn't mention NAPTR. I am not personally aware of other protocols using
> this setup, so maybe this requires a very SIP specfic draft, following the wake of the
> smtp work.
> 
> /O
>

---

From: Mary Barnes <[email-masked]>
Date: Mon, 22 Apr 2013 10:18:45 -0500

Updates to 5922 should happen in the RAI area.  We can discuss on
DISPATCH the need for the updates and then decide exactly where the
work should be done.  I would think the work would be done in SIPCORE,
since 5922 updates RFC 3261.

Thanks,
Mary.

On Sun, Apr 21, 2013 at 6:25 AM, Olle E. Johansson <[email-masked]> wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 22 Apr 2013 17:34:07 +0200

> since 5922 updates RFC 3261.

A very important change is the SIP URI to certificate matching.
In SIP, we have specified in RFC 5922 that the certificate should match
the requested domain, not the host name choosen by the RFC 3263 process.

In the current DANE drafts for SRV records the matching is done by
the host name choosen as a result in the SRV lookups. This requires
a validated trusted chain from the NAPTR down to the SRV and
A/AAAA lookup.

I can see the point of not having to get new or updated certificates for
every domain added to a hosted service. 

5922 states the following:

SIP domain identity:  An identity (e.g., "sip:example.com") contained
      in an X.509 certificate bound to a subject that identifies the
      subject as an authoritative SIP server for a domain.

With DNSsec, the signed DNS zone binds a domain to a server,
and the X.509 certificates identifies the server, but doesn't
say anything about being authoritative for a domain.

Validating certs by host name and binding authority in DNS 
is a normative change to 5922.

I haven't spent any bandwidth on considering SIP identity yet,
but it is applicable there too.

/O

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 22 Apr 2013 11:05:08 -0500

> the requested domain, not the host name choosen by the RFC 3263 process.

Olle: Indeed.  I think we have to be careful here before changing
rfc5922.  The mechanism in rfc5922 was designed specifically to
validate domains, not individual hosts.  More inline (at the end).

> is a normative change to 5922.

I would like to understand DANE's approach better before we
proceed to modify rfc5922.  Unfortunately, I am swamped for the next
couple of weeks, but I will like to spare some time after that to
understand better your motivation.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 22 Apr 2013 16:42:43 +0000

While there was never a formal mailing list poll (because we never got to the point of needing a 3261bis), I think there was a considerable body of opinion during the development of domain-certs that the material would form part of any 3261bis work. That I think lends support to any further work being done in sipcore.

I do suggest you look back in the archives for the mailing list discussion on domain-certs. You'll find it on the sip (not sipcore) mailing list archive. You'll find the WG discussion between Feb 2008 and April 2009 with the IESG approval discussion continuing until May 2010.

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Mary Barnes
> Sent: 22 April 2013 16:19
> To: Olle E. Johansson
> Cc: [email-masked] list
> Subject: Re: [dispatch] Fwd: DANE SRV draft and SIP
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 22 Apr 2013 10:48:31 -0600

On 4/22/13 9:34 AM, Olle E. Johansson wrote:
>> Updates to 5922 should happen in the RAI area.  We can discuss
>> on DISPATCH the need for the updates and then decide exactly
>> where the work should be done.  I would think the work would be
>> done in SIPCORE, since 5922 updates RFC 3261.
> 
> A very important change is the SIP URI to certificate matching. In
> SIP, we have specified in RFC 5922 that the certificate should
> match the requested domain, not the host name choosen by the RFC
> 3263 process.
> 
> the host name choosen as a result in the SRV lookups. This
> requires a validated trusted chain from the NAPTR down to the SRV
> and A/AAAA lookup.
> 
> I can see the point of not having to get new or updated
> certificates for every domain added to a hosted service.

Yes, this is a huge problem for multi-tenanted services. We've been
thinking about this for a while in the XMPP world. I suggest you have
a look at http://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/ (also
in the RAI area, of course!) for some related considerations. XMPP too
uses SRV (not NAPTR) but draft-dane-srv doesn't quite meet the needs
of XMPP, either (Matt Miller and I are providing feedback to the DANE
WG as needed).

Peter

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 22 Apr 2013 20:18:57 +0200

> I do suggest you look back in the archives for the mailing list discussion on domain-certs. You'll find it on the sip (not sipcore) mailing list archive. You'll find the WG discussion between Feb 2…

Keith,
Thank you for the reference.

Note that I'm not saying that  RFC 5922 is wrong. The issue at hand is that the DANE groups current RFC
suggests a solution not compatible with 5922. We need to decide which way to go.

We could recommend that the DANE way is used when DNSsec and DANE validation is possible,
and keep RFC 5922 for other cases. Or update the recommendation in 5922 to make sip with TLS
better in regards to hosting larger amounts of domains.

In any case, I think we need to do something to support DANE in SIP.

Regards,

/Olle

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 22 Apr 2013 12:28:20 -0600

On 4/22/13 12:18 PM, Olle E. Johansson wrote:
>> While there was never a formal mailing list poll (because we
>> never got to the point of needing a 3261bis), I think there was a
>> considerable body of opinion during the development of
>> domain-certs that the material would form part of any 3261bis
>> work. That I think lends support to any further work being done
>> in sipcore.
>> 
>> I do suggest you look back in the archives for the mailing list
>> discussion on domain-certs. You'll find it on the sip (not
>> sipcore) mailing list archive. You'll find the WG discussion
>> between Feb 2008 and April 2009 with the IESG approval discussion
>> continuing until May 2010.
> 
> Keith, Thank you for the reference.
> 
> Note that I'm not saying that  RFC 5922 is wrong. The issue at hand
> is that the DANE groups current RFC suggests a solution not
> compatible with 5922. We need to decide which way to go.
> 
> We could recommend that the DANE way is used when DNSsec and DANE
> validation is possible, and keep RFC 5922 for other cases.

Well, it's clear to me that we wouldn't allow checking of the derived
domain (in RFC 6125 terms) unless DNSSEC validation succeeds. Since
that is currently a rare event, we'd just continue to do what RFC 5922
says, which in draft-ietf-xmpp-dna we call the PKI prooftype.

> Or update the recommendation in 5922 to make sip with TLS better in
> regards to hosting larger amounts of domains.

I think that is somewhat a separate issue from defining the DANE
prooftype, because other prooftypes might be possible or more
deployable in the short term, such as the POSH prooftype that Matt
Miller and I have defined in draft-miller-xmpp-posh-prooftype (but
which is not specific to XMPP).

Peter

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 22 Apr 2013 21:18:31 +0200

22 apr 2013 kl. 20:28 skrev Peter Saint-Andre <[email-masked]>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
I'm not sure that the certificates would be compatible, which is a problem.
A non-DNSsec client following RFC 5922 requires one certificate with domain
names and the DNSsec/DANE client would require host names in the
same certificate - unless we have certificate selection (TNI).

Being tricky one could possibly have the host name in the CN
and add SIP domain URIs in subj alt names.

> which is not specific to XMPP).
I need to read up on your drafts, but how do you handle certificates
for one server supporting multiple prooftypes? Are they compatible
in XMPP?

/O
> 
> Peter
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJRdYFEAAoJEOoGpJErxa2pLCoP/1wYQA2CGqmaCwtG0udAP9bL
> PyaYjqWqofvEdnJk/Nm/HKZdZ3MuGzpqydWo11Yi/GOyyjIzZrNQKZ2c4gPhCiNB
> KdOMiMGBU625vsCJjhu8E5b14sXc4lJc7iEf2dfmMQpwer26YmGrRpolVSsBZ/td
> 3FvkbPChbC9zg8YHSN9k9tkQlxfwwK5sjgIMDGtOhaKnhUBlIiGV0iTXZL1nkMdq
> X9DUWzlvCHxNHWB2W1nbtYagNWu6QaoJTI88O/5qcwP4pZsrHbhelvqeuERfF+sY
> sBIBrxYBNUhM9a7wWhxrlqSBeM/nt/oM46osV/sI5qrobkNs26l7hHkh/CVzpr/H
> 72c1PaujqKJx4Osidyi24a9Lc6JTke/v4gr+ObN9zDBaUvAcXghqk73j8P2rUsj+
> T64/lN1n22G87d9sdi9X7RUdfTlPmg65CFmfhBMTfYnz2ZL7YzVxvnKs+Q/BF/1S
> 7pHMJoviKM7V1cx3OYaEBqFnnRzWOlcfrULzy0VrFw7IjxD6+W9RxGoi2Zv1R2xL
> tBy+FV9iUXS9CHyrEmjm+DYgqopg70PCaIEjHZzrC2SCbWw2DBbP0K/d5YL51Vmz
> Hyz8T3h4pSfgkwa/wPs7WeP6UrHV3Cz66077L+taLuT1NV7JP1lr9L8pLDMj6xQ8
> fpkwx+0yZnAY8VBDp76A
> =6W3o
> -----END PGP SIGNATURE-----

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 22 Apr 2013 13:32:39 -0600

On 4/22/13 1:18 PM, Olle E. Johansson wrote:
>>>>> While there was never a formal mailing list poll (because
>>>>> we never got to the point of needing a 3261bis), I think
>>>>> there was a considerable body of opinion during the
>>>>> development of domain-certs that the material would form
>>>>> part of any 3261bis work. That I think lends support to any
>>>>> further work being done in sipcore.
>>>>> 
>>>>> I do suggest you look back in the archives for the mailing
>>>>> list discussion on domain-certs. You'll find it on the sip
>>>>> (not sipcore) mailing list archive. You'll find the WG
>>>>> discussion between Feb 2008 and April 2009 with the IESG
>>>>> approval discussion continuing until May 2010.
>>>> 
>>>> Note that I'm not saying that  RFC 5922 is wrong. The issue
>>>> at hand is that the DANE groups current RFC suggests a
>>>> solution not compatible with 5922. We need to decide which
>>>> way to go.
>>>> 
>>>> We could recommend that the DANE way is used when DNSsec and
>>>> DANE validation is possible, and keep RFC 5922 for other
>>>> cases.
> 
> Well, it's clear to me that we wouldn't allow checking of the
> derived domain (in RFC 6125 terms) unless DNSSEC validation
> succeeds. Since that is currently a rare event, we'd just continue
> to do what RFC 5922 says, which in draft-ietf-xmpp-dna we call the
> PKI prooftype.
>> I'm not sure that the certificates would be compatible, which is
>> a problem. A non-DNSsec client following RFC 5922 requires one
>> certificate with domain names and the DNSsec/DANE client would
>> require host names in the same certificate - unless we have
>> certificate selection (TNI).
> 
>> Being tricky one could possibly have the host name in the CN and
>> add SIP domain URIs in subj alt names.

In practice, large hosting providers either (1) don't offer
certificates at all or (2) offer a certificate with the hostname /
derived domain instead of the source domain. In the case of (2), this
forces the client developer to offer a special registration method or,
even worse, forces the user to override security settings (so that,
for example, everyone just "knows" that gmail.com users are actually
going to be presented with a certificate for talk.google.com). Both of
those are bad outcomes.

>>>> Or update the recommendation in 5922 to make sip with TLS
>> I need to read up on your drafts, but how do you handle
>> certificates for one server supporting multiple prooftypes? Are
>> they compatible in XMPP?

I see no reason why they can't be.

Peter

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 24 Apr 2013 08:37:37 -0600

I'm keen on someone writing a draft that specifies how to do DANE with SIP and bringing that draft to dispatch. 

However, I don't think you want to do that as un update to 5922. I think you want it to be just a new draft that is an extension to SIP and does not update or replace any of the existing draft. 

I think Dispatch would be a good place to start the discussion around it and decide how if this was a sip core thing, or a new small WG, or something else. There are a few different problems that can be tacked. One is validating that the TLS connection has the right cert. The other is more 4474 style identity issues. I think it will be good to see discussion on the dispatch list of the scope of problems we want to solve with DANE. 

Cullen <with my Dispatch co-chair hat on>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 24 Apr 2013 17:25:44 +0200

> I think Dispatch would be a good place to start the discussion around it and decide how if this was a sip core thing, or a new small WG, or something else. There are a few different problems that c…
Ok, thanks for the feedback. There's some discussion already on the DANE list to coordinate with the work on SMTP and XMPP.

I'm trying to collect my thoughts here and will come back with some ideas for discussion.

/O

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 29 Apr 2013 12:33:59 +0000

I regarded the destination group as a given, i.e. SIPCORE.

I agree that a draft would be useful to confirm that, but then I see the key DISPATCH decision as to whether it is dispatchable, rather than where it is going.

Keith

> Behalf Of Cullen Jennings
> Sent: 24 April 2013 15:38
> To: Olle E. Johansson
> Subject: [dispatch] Brigining SIP+DANE to Dispatch
> 
> 
> However, I don't think you want to do that as un update to 5922. I think
> you want it to be just a new draft that is an extension to SIP and does
> not update or replace any of the existing draft.
> 
> I think Dispatch would be a good place to start the discussion around it
> and decide how if this was a sip core thing, or a new small WG, or
> something else. There are a few different problems that can be tacked. One
> is validating that the TLS connection has the right cert. The other is
> more 4474 style identity issues. I think it will be good to see discussion
> on the dispatch list of the scope of problems we want to solve with DANE.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Apr 2013 10:24:49 -0400

> I agree that a draft would be useful to confirm that, but then I see the key DISPATCH decision as to whether it is dispatchable, rather than where it is going.

I agree that the point where this should be addressed, if dispatched, is 
sipcore.

	Thanks,
	Paul (as co-chair of sipcore)

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 29 Apr 2013 16:34:26 +0200

29 apr 2013 kl. 16:24 skrev Paul Kyzivat <[email-masked]>:

> I agree that the point where this should be addressed, if dispatched, is sipcore.

Sounds like there is a plan. Now let's focus on getting this process done :-)

Thanks for all the feedback!

/O