Re: [dane] I-D Action: draft-ietf-dane-srv-04.txt

Viktor Dukhovni <viktor1dane@dukhovni.org> Wed, 12 February 2014 21:08 UTC

Return-Path: <viktor1dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35331A06BC for <dane@ietfa.amsl.com>; Wed, 12 Feb 2014 13:08:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 8bQWpf8q4wKg for <dane@ietfa.amsl.com>; Wed, 12 Feb 2014 13:08:20 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id BCE301A0620 for <dane@ietf.org>; Wed, 12 Feb 2014 13:08:16 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id AA1A22AB23C; Wed, 12 Feb 2014 21:08:13 +0000 (UTC)
Date: Wed, 12 Feb 2014 21:08:13 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140212210813.GI278@mournblade.imrryr.org>
References: <20140211221320.30490.31053.idtracker@ietfa.amsl.com> <52FAA17F.3060703@cisco.com> <20140211233403.GV278@mournblade.imrryr.org> <52FBB013.2080502@cisco.com> <20140212195413.GG278@mournblade.imrryr.org> <52FBDBF6.5080309@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52FBDBF6.5080309@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] I-D Action: draft-ietf-dane-srv-04.txt
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Feb 2014 21:08:23 -0000

On Wed, Feb 12, 2014 at 01:39:18PM -0700, Matt Miller wrote:

> >> Thank you for the feedback, Viktor.  These comments make sense to
> >> me. We'll try to get an update out before the cutoff to address
> >> them.
> > 
> > Thanks.  You could mention that both name checks and key usage are 
> > effectively handled by the TLSA record for DANE-EE(3).  The TLSA 
> > record binds the certificate or public key to the requested port 
> > and protocol at the TLSA base domain, the binding is clearly for a
> > TLS server, so there is an implicit key usage of TLS server. 
> > Finally, the RRSIG expiration date sets the expiration time of the 
> > TLSA "pseudo-certificate".  A requirement to ignore the
> > certificate content gives the publisher flexibility (e.g. same
> > certificate for multiple SRV hosts, ...).
> > 
> 
> Section 5 (after I change the "MAY" to a "MUST") already states that
> matching a DANE-EE(3) TLSA bypasses the rest of the certificate checks
> (paragraph 2), but the current wording might be too clumsy.  I'll see
> what I can wordsmith to make it more explicit.

It is only a question of how much you feel it is appropriate to
provide a rationale for this requirement and in how much detail
you want to provide it.

> I could also add something about the RRSIG expiration, but isn't that
> already covered by RFC4035 ? 5.3.1 (bullet 5)?

I don't know that RFC 4035 specifically talks about imputing a TLS
server key expiration time from a DNS RRSIG expiration time, but
per the above comment, it is largely a question of whether you want
to explain why it is OK to ignore the "3 X Y" certificate content
and get everything you need from DNSSEC.

-- 
	Viktor.