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

"Olle E. Johansson" <oej@edvina.net> Thu, 02 January 2014 10:16 UTC

Return-Path: <oej@edvina.net>
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 82BA91AD669 for <dispatch@ietfa.amsl.com>; Thu, 2 Jan 2014 02:16:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] 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 HAD2LjOw-Yl3 for <dispatch@ietfa.amsl.com>; Thu, 2 Jan 2014 02:16:11 -0800 (PST)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 30CB01AC4A3 for <dispatch@ietf.org>; Thu, 2 Jan 2014 02:16:09 -0800 (PST)
Received: from [192.168.40.22] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 5AEB493C2A1; Thu, 2 Jan 2014 10:16:01 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: "Olle E. Johansson" <oej@edvina.net>
Date: Thu, 02 Jan 2014 11:16:00 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <0BA14051-5C7F-4416-8CD2-413347D540D3@edvina.net>
References: <20140102101042.27427.64547.idtracker@ietfa.amsl.com>
To: "dispatch@ietf.org list" <dispatch@ietf.org>
X-Mailer: Apple Mail (2.1822)
Subject: [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: Thu, 02 Jan 2014 10:16:13 -0000

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. 

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.
> 
>