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

Paul Kyzivat <pkyzivat@alum.mit.edu> Sat, 04 January 2014 16:23 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC171AE02F for <dispatch@ietfa.amsl.com>; Sat, 4 Jan 2014 08:23:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.165
X-Spam-Level:
X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqVhzrwnnP6B for <dispatch@ietfa.amsl.com>; Sat, 4 Jan 2014 08:23:53 -0800 (PST)
Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 49EC01AE037 for <dispatch@ietf.org>; Sat, 4 Jan 2014 08:23:53 -0800 (PST)
Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta15.westchester.pa.mail.comcast.net with comcast id 9s381n0041YDfWL5FsPlba; Sat, 04 Jan 2014 16:23:45 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id 9sPl1n00A3ZTu2S3gsPlRV; Sat, 04 Jan 2014 16:23:45 +0000
Message-ID: <52C83591.3080702@alum.mit.edu>
Date: Sat, 04 Jan 2014 11:23:45 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: dispatch@ietf.org
References: <20140102101042.27427.64547.idtracker@ietfa.amsl.com> <0BA14051-5C7F-4416-8CD2-413347D540D3@edvina.net>
In-Reply-To: <0BA14051-5C7F-4416-8CD2-413347D540D3@edvina.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1388852625; bh=ShnbZHHHC38DSvV/1CQfv8RPOBjUKGMVc5jXAbyMqXs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bTZOazilVPUChT3KTbeNvLSR+kXCQOHt3dhMNKzY0GtWRR9C/gHjrWb4Ut8OkMujr d42cV9rYkMpR8JbRwXLXb6H2OUwQNPxoyXotLn5b0CFkzi1mo5wmxWuwqsOUt1hxLB 5C0bgmArRaDYskPSJlQbguuXoX+vSpAYFKhJf+XAa3sSGDsxiyYvPG9cguu135FMFl F3uChhQAcDFq7OFMDM7OyWQ72dyLlmxh68EWqOh2NgrIoD7vG0E3d041vddfQQ/Q/a RFLRxE7ni7NIfUdpyXQW0CGpTqujyWY+jdUqlJCrLwoR1ff0TiAaxTEJX6fQoTnxNK 7jUZE1LKeh9vA==
Subject: Re: [dispatch] Fwd: New Version Notification for draft-johansson-dispatch-dane-sip-00.txt
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Jan 2014 16:23:55 -0000

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.

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.

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?

What about those coming to this without any history of 5922 support?

ISTM that there is need to get ubiquitous client support for this 
deployed. For that we have the usual chicken/egg scenario.

	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
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>