Re: [dispatch] DANE SRV draft and SIP

[Peter Saint-Andre <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/22/13 1:18 PM, Olle E. Johansson wrote:
> 
> 22 apr 2013 kl. 20:28 skrev Peter Saint-Andre
> <[e-mail]>:
> 
> On 4/22/13 12:18 PM, Olle E. Johansson wrote:
>>>> 
>>>> 22 apr 2013 kl. 18:42 skrev "DRAGE, Keith (Keith)" 
>>>> <[e-mail]>:
>>>> 
>>>>> 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.
>> 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
>>>> 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).
>> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRdZBXAAoJEOoGpJErxa2pokgP/18C2O2vOT6KgnpplYm7pm1/
qgRYj5ezta6wJumOyU4Zf1Tyko89YjhUO9dRSO01ETG2Y23Fmgxe4kGK4qjnAlwL
fQsdIHBWmT/8s3pSF+/eT6629yaw7kLGnTJe/G2tZ36eN6Gms/WQiEAJF4JpmyEj
U7oVdANfQGvVljU7yzHSCc4d5hBmDIcmXEfh/msXvcutfX6ptIrKGszwGhBlnVXS
ARn+qxmofVedz/UdwZYH92RpaFrDolqZrcbt6mB3cCPskM3WxEv6GDqwqZ6fWV81
X+tt2v5aetSky97wC0ewtHjOtJ17UAPFGBNLuoktNfD9N3sYT6bCcXYE99+JjNBL
dq44uw0zLG1EbY1u3cTYVDnS6f62sM3XWkgZAqgyQQcmi60DsMKSnEym7vJO5o7Y
1/GkdxER30cvSA1hzQQIY8qTjAK5PTIZieAteU0cy7MeFwmO285pymteeU7TSu0d
jEOy1jt7Swize9Wizo0zjRAxkpGiWnxEJCcvQau9+h0SF9YR7XHxsnSi+q7W/KWl
xXsiYJtmhxFQtdn0AQXbBS2y/ZPSv48S968qOnVKUg+AHkVAoiJghLs01usqYQuk
xNvHw97I5rAGgF87++mae5E+XbAEsD47J2Ozwc741yQqwUzIoZG5tase2GivSkjf
ensJrCtBxZTT37hGsZoa
=O0cH
-----END PGP SIGNATURE-----