Re: [dane] draft-ietf-dane-smime

Viktor Dukhovni <ietf-dane@dukhovni.org> Sat, 01 November 2014 23:33 UTC

Return-Path: <ietf-dane@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 5E6501A1BA4 for <dane@ietfa.amsl.com>; Sat, 1 Nov 2014 16:33:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6] 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 ntWoKBPjYmUu for <dane@ietfa.amsl.com>; Sat, 1 Nov 2014 16:33:24 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B37CE1A1B9E for <dane@ietf.org>; Sat, 1 Nov 2014 16:33:24 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BE3552AAD9C; Sat, 1 Nov 2014 23:33:22 +0000 (UTC)
Date: Sat, 1 Nov 2014 23:33:22 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20141101233322.GU19103@mournblade.imrryr.org>
References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <39C76846-F695-435D-9A5C-6989D06E9573@verisign.com> <20141031172840.GM19103@mournblade.imrryr.org> <F6025049-7FEC-4286-AABF-AB1E47452742@verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <F6025049-7FEC-4286-AABF-AB1E47452742@verisign.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/iNW2LhsZSE5vTHO25anwFkETbwk
Subject: Re: [dane] draft-ietf-dane-smime
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: Sat, 01 Nov 2014 23:33:26 -0000

On Sat, Nov 01, 2014 at 08:38:44PM +0000, Osterweil, Eric wrote:

> > Which certificate is being invalidated? Why is this needed?  What's
> > wrong with publishing a "3 1 1" association with an impossible key?
> 
> Thanks for sending this note!  The idea here is to say, ``this
> specific key (which an RP may or may not have used before) is not
> to be used for this inbox, at this time.''  An impossible key just
> means _that_ key can?t be used.  This idea isn?t trying to disable
> an email inbox, just ensure that a key that may pass (or may have
> passed, once upon a time) other verification is unambiguously
> de-authorized.

Well, in *that* case the association data MUST be the leaf digest!
At least that would comport much better with the other DANE usages,
and allow selective "revocation" of one or more records.

However, it seems to me that *any* record which does not match the
current SMIME RR is implicitly invalid to valid new messages.  What
purpose does "reject" serve?


> > Once this field is not "NO", what is the meaning of the associated
> > data field carried with such a record?  Is it still providing a
> > valid DANE association?
> 
> Yeah, I would say so.  I think this is the case most akin to the TLSA model.  I would say:
> 0 == use TLSA-style DANE
> 1 == look for info from a service that is described by NAPTR
> 2 == Look for info served from a WebFinger service.

What is the meaning of the associated *DATA* field?  Why should
this be an SMIMEA record.  I think this is misuse of that record.

> I don?t understand this comment, but I think it stems from a miscommunication above.  This field would be used to say, ``look over there for the cert.??  If the cert info is encoded in SMIMEA, or its retrieval is outside of the DANE scope (i.e., the cert is included in an email message), then this field is left as 0 (not used).
> 
> Does that make more sense?

No.  The alternate sources can be published and the application
can look there if it sees fit.

-- 
	Viktor.