[dispatch] draft-johansson-dispatch-dane-sip-01 - certificate validation

Michael Procter <michael@voip.co.uk> Sat, 25 January 2014 22:40 UTC

Return-Path: <michael@voip.co.uk>
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 A51C41A00A4 for <dispatch@ietfa.amsl.com>; Sat, 25 Jan 2014 14:40:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.579
X-Spam-Level:
X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 sqD5mpgYa-zC for <dispatch@ietfa.amsl.com>; Sat, 25 Jan 2014 14:40:35 -0800 (PST)
Received: from na3sys009aog130.obsmtp.com (na3sys009aog130.obsmtp.com [74.125.149.143]) by ietfa.amsl.com (Postfix) with SMTP id 1C5161A009D for <dispatch@ietf.org>; Sat, 25 Jan 2014 14:40:35 -0800 (PST)
Received: from mail-wg0-f41.google.com ([74.125.82.41]) (using TLSv1) by na3sys009aob130.postini.com ([74.125.148.12]) with SMTP ID DSNKUuQ9YeeMIWppBqqvToTX8c0JdsbM5fk7@postini.com; Sat, 25 Jan 2014 14:40:34 PST
Received: by mail-wg0-f41.google.com with SMTP id n12so3017137wgh.2 for <dispatch@ietf.org>; Sat, 25 Jan 2014 14:40:32 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=kaF3jbAVwOSH6KTcfpq3D21imu7AqDVVTb2t9svopDg=; b=UjDWXY3xMj5WnX608WbuNL00HW5tkB5R/lWKNxYkNQGgJZVbz1bxR5aG9DnVN5wa8F IMm1rRLLsgbLSHpq4q9WtfARqp8kckLXRapYD7wtY+TQQouAW2hty8qzaWzjYorcCyry Aj7dqGE49XHk5aAaEGBv9S2Ve1mwLYHDQ4ANgxtMbZYVPdpUnBdSC0AcH4WWy8itYri9 piUjLF/GutP7cxyXoDh2EAJhTNBC6sxNME8h2LTJLzazxxz1Hv6bVoZEJ+qROs277Bst iKpvX9A9HRS2G068EhZVXL4ict9GTJ6b2IZA0T+5DfYAKhPdYZpkXD6Clmwiu+UpGXmB HBsQ==
X-Gm-Message-State: ALoCoQnDO9X5nTENB5sqY8IolxQ3TZEvYLQQ7gJW7yEd9sQnufFWWsIAZ1QiBMQEJ3+7lWsphTPuXDSkKnqetyjYemczJRUg9pUa1iuHGuCW7jWCb/5s31EjSYIWrn+g+GTxSwce4aUfGDJ7eh5IV0KS8VxxabLV4A==
X-Received: by 10.180.98.42 with SMTP id ef10mr7356891wib.49.1390689632482; Sat, 25 Jan 2014 14:40:32 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.98.42 with SMTP id ef10mr7356889wib.49.1390689632390; Sat, 25 Jan 2014 14:40:32 -0800 (PST)
Received: by 10.194.42.195 with HTTP; Sat, 25 Jan 2014 14:40:32 -0800 (PST)
Date: Sat, 25 Jan 2014 22:40:32 +0000
Message-ID: <CAPms+wQC2KB4ymHxQfuf8HS9nsDPh33fAOA9BPHCT0qfxV7OhA@mail.gmail.com>
From: Michael Procter <michael@voip.co.uk>
To: Olle E Johansson <oej@edvina.net>, IETF Dispatch <dispatch@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [dispatch] draft-johansson-dispatch-dane-sip-01 - certificate validation
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, 25 Jan 2014 22:40:36 -0000

Hi Olle,

I have read your draft on DANE for SIP, and have a question about
section 8.  The section starts with the statement:

   When using DANE-based validation the client validates the SRV
   hostname with the certificate using RFC 5922 rules.

I'm not sure we want to use the SRV hostname here.  RFC 5922 uses the
original domain before the NAPTR lookup (the AUS) which is probably
the same as the SRV hostname, but may be different[0].

I think we have to keep the mechanisms aligned to ensure that a
certificate that matches under RFC 5922 rules continues to match after
you add a TLSA RR.

Best regards,

Michael


[0] RFC 3263 Section 4.1, para 10 starts:
   It is not necessary for the domain suffixes in the NAPTR replacement
   field to match the domain of the original query (i.e., example.com
   above).