Re: [dispatch] New Version Notification for draft-johansson-dispatch-dane-sip-00.txt

[Paul Kyzivat <[e-mail]>]

Olle,

Thanks for clarification.

I think it would be helpful if you would add a section on deployment 
hints and issues. Then you could talk about various cases:

- updating a server that already supports TLS via 5922
- updating a client that already supports TLS via 5922
- recommendations for a server newly supporting TLS
- recommendations for a client newly supporting TLS
- ...

Another question that came to me is what to do about TLS client 
authentication?

	Thanks,
	Paul

On 1/7/14 6:12 AM, Olle E. Johansson wrote:
>
> On 04 Jan 2014, at 17:23, Paul Kyzivat <[e-mail]> wrote:
>
>> On 1/2/14 5:16 AM, Olle E. Johansson wrote:
>>> Hi!
>>> I have renamed my draft and resubmitted it again. Adding DNSsec/DANE support to SIP is not a bad idea in my point of view.
>>
>> It seems like a really good idea to me.
>>
>> I have a question about backward compatibility, as discussed in section 9:
>>
>> You say that that servers can use certificates that support both DANE and 5922 style validation. And IIUC that will be necessary in order to handle clients that don't support DANE validation.
> Yes.
>>
>> But the Intro explains that one of the important reasons for introducing DANE authentication is because of various logistic problems providing certificates for 5922 style validation. Providing backward compatibility negates that advantage.
> Well, I might need to clarify that. The current way to host multiple SIP domains is either to have one certificate with a long list of subject Alt Names or multiple IPs each with it's own certificate with the domain in SubjAltName. Both are very hard to maintain. Either buy a new cert for a new domain - and a new IP. Or reissue the existing cert to get an additional name.
> SNI could also be used, but is not yet wildely supported out there. It just means one cert per domain. I don't remember if we've specified how SNI applies to RFC 5922 - what are we specifying in the SNI lookup?
>
>
>>
>> Have you considered the migration path? Presumably those currently using 5922 already have a certificate that works for that. Will they be able to get a cert that continues that and also supports DANE validation?
> Yes, they just need to get the host name into the CN. 5922-compliant clients ignore the CN when there are SubjectAltNames and clients supporting this draft will ignore the SubjectAltNames.
>
>>
>> What about those coming to this without any history of 5922 support?
> Those will look for something in some field that's very unspecified. Hard to support. I guess that they will look for something to match in the CN. What that is varies - which is why we need standardization :-)
>
> Wild guess is that they look for the domain in the CN. They will not accept certificates according to this RFC.
> Again SNI could help.
>
>>
>> ISTM that there is need to get ubiquitous client support for this deployed. For that we have the usual chicken/egg scenario.
> Always that chicken and the %&€&€& egg. ;-)
>
> Thank you for your feedback, Paul!
>
> /O
>>
>> 	Thanks,
>> 	Paul
>>
>>> If the view gets larger we might want to focus a bit more on security aspects of SIP in the RAI area. There are many issues to look at. Why isn't S/MIME deployed, how do we get more TLS - if that's what we want? Can we improve upon MD5 digest authentication? Do we want to fix SIP identity that many claim is broken? Is it possible to set up sessions with end2end security?
>>>
>>> Happy New Year!
>>>
>>> /O
>>>
>>>
>>>
>>> Begin forwarded message:
>>>>
>>>> A new version of I-D, draft-johansson-dispatch-dane-sip-00.txt
>>>> has been successfully submitted by Olle E. Johansson and posted to the
>>>> IETF repository.
>>>>
>>>> Name:		draft-johansson-dispatch-dane-sip
>>>> Revision:	00
>>>> Title:		TLS sessions in SIP using DNS-based Authentication of Named Entities (DANE) TLSA records
>>>> Document date:	2014-01-02
>>>> Group:		Individual Submission
>>>> Pages:		9
>>>> URL:            http://www.ietf.org/internet-drafts/draft-johansson-dispatch-dane-sip-00.txt
>>>> Status:         https://datatracker.ietf.org/doc/draft-johansson-dispatch-dane-sip/
>>>> Htmlized:       http://tools.ietf.org/html/draft-johansson-dispatch-dane-sip-00
>>>>
>>>>
>>>> Abstract:
>>>>    Use of TLS in the SIP protocol is defined in multiple documents,
>>>>    starting with RFC 3261.  The actual verification that happens when
>>>>    setting up a SIP TLS connection to a SIP server based on a SIP URI is
>>>>    described in detail in RFC 5922 - SIP Domain Certificates.
>>>>
>>>>    In this document, an alternative method is defined, using DNS-Based
>>>>    Authentication of Named Entities (DANE).  By looking up TLSA DNS
>>>>    records and using DNSsec protection of the required queries,
>>>>    including lookups for NAPTR and SRV records, a SIP Client can verify
>>>>    the identity of the TLS SIP server in a different way, matching on
>>>>    the SRV host name in the X.509 PKIX certificate instead of the SIP
>>>>    domain.  This provides more scalability in hosting solutions and make
>>>>    it easier to use standard CA certificates (if needed at all).
>>>>
>>>>    This document updates RFC 5922.
>>>>
>>>>
>>>
>>> _______________________________________________
>>> dispatch mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>
>>
>> _______________________________________________
>> dispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dispatch
>
>