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

Paul Hoffman <> Mon, 20 October 2014 15:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CBB881A1AE1 for <>; Mon, 20 Oct 2014 08:55:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.647
X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Zd4ERHNtKhMt for <>; Mon, 20 Oct 2014 08:55:24 -0700 (PDT)
Received: from (Hoffman.Proper.COM []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 744AD1A1AFD for <>; Mon, 20 Oct 2014 08:54:52 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.9/8.14.7) with ESMTP id s9KFsogQ083508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Oct 2014 08:54:51 -0700 (MST) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Paul Hoffman <>
In-Reply-To: <>
Date: Mon, 20 Oct 2014 08:54:50 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Eric Osterweil <>
X-Mailer: Apple Mail (2.1990.1)
Cc: "<>" <>
Subject: Re: [dane] draft-ietf-dane-smime
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Oct 2014 15:55:27 -0000

On Oct 20, 2014, at 8:23 AM, Osterweil, Eric <> wrote:

> TLS and S/MIME use pretty different security models (session vs. object security)

Sure, but how is that difference relevant here? DANE is about distributing certificates and keying information through DNS: it is agnostic to the security model.

> , so necessarily coupling the RRs doesn’t seem to make sense.  

It has so far in the WG. The WG asked us early on to make as few changes as possible to the TLSA definition.

> In addition, to echo what others have already said on the list, I really don’t think it is reasonable to gate updates to the SMIMEA proposal on updating TLSA.

Fully agree, and that's not what I was proposing. The two changes that you have proposed (revocation indication and alternate sources for getting the information) can be done as new values to the existing RR subfields. Doing so would make what you want usable for both SMIMEA and TLSA. Proposals to make those changes can trivially be done as stand-alone Internet Drafts.

>> A better process would be for the proponents to offer a standalone draft for the idea that will be an extension that would be usable to both TLSA and SMIMEA and any other documents that come later.
> Just by looking at the list, it seems like there are a number of voices that disagree with you on this.  

Where "a number" means "two", and even they didn't actually disagree about creating standalone drafts, simply that the assumption that the use cases might be different.

> Also, isn’t the SMIMEA work still an evolving draft?  

Yes, of course.

> What else does one need besides: articulated rationale, proposed requirements, operational data, suggested text, and running code from multiple people in order to support suggested revisions?  

Consensus in the WG. That may seem anathema to you, but it's the way that the IETF works.

--Paul Hoffman