Re: [dane] I-D Action: draft-ietf-dane-smime-03.txt

"Osterweil, Eric" <> Wed, 05 February 2014 20:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 21D411A020E for <>; Wed, 5 Feb 2014 12:48:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.601
X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mE3sNb0gDtvD for <>; Wed, 5 Feb 2014 12:48:30 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9FEAD1A01CC for <>; Wed, 5 Feb 2014 12:48:25 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Wed, 05 Feb 2014 12:48:29 PST
Received: from ( []) by (8.13.6/8.13.4) with ESMTP id s15KmOlB014984 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 15:48:24 -0500
Received: from ([::1]) by ([::1]) with mapi id 14.02.0342.003; Wed, 5 Feb 2014 15:48:23 -0500
From: "Osterweil, Eric" <>
To: Jakob Schlyter <>
Thread-Topic: [dane] I-D Action: draft-ietf-dane-smime-03.txt
Thread-Index: AQHPCyZe4iLhCQLcdU6kJvU3W3pU85p7QbWAgCwGwgCAAEFoAIAAGtwA
Date: Wed, 5 Feb 2014 20:48:22 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<>" <>
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.txt
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: Wed, 05 Feb 2014 20:48:32 -0000

On Feb 5, 2014, at 2:12 PM, Jakob Schlyter <>

> On 5 feb 2014, at 16:17, Osterweil, Eric <> wrote:
>> I noticed that the current (-04?) draft doesn't seem to have taken these recommendations, but I think they should be incorporated.
> As per Paul's reply Jan 8th, we've had no consensus on adding these features as both was (at least by Paul and me) of questionable value. Scott seemed to somewhat agree in a followup mail. However, I do welcome a more elaborate discussion on the pros _and_ cons so we can close these issues.

Hey Jakob,

Indeed, I was adding in support for Scott's proposal because I agreed with at least three of his points.  I'd be happy to elaborate on any of the issues I pointed out, though I did think the comments I initially made were reasonably detailed, no?  Actually, to that point, I don't recall seeing substantive a rebuttal to Scott's suggestions on Jan 8?

I actually did read Paul's response ( ), and I felt it didn't present a very in-depth response to the detailed suggestions that Scott made.  That's why I felt it was important to express my support for Scott's suggestions.

For example, Paul responded:
  ``The slight saving of space also introduces a new, significant failure mode …  I'd say "no" on this one.''
I don't agree that this is a failure mode that invalidates the cert learning, and disagree with its dismissal.  Moreover, I elaborated on other reasons why I think these labels are important, ``Finally, I think the `_encr' and `_sign' labels are excellent additions to the _discovery_ mechanism that DANE enables.  Viewing DANE as a discovery mechanism for certs, I can't help but feel that the process of trying to discover a signing key vs.trying to discover an encryption key a first class element of the protocol.  Rather than asking for all keys and then selecting from them, I (as an RP) likely already know which of these I want, and I should be able to discover them separately in DANE (and owners should be able to manage them separately in DANE).  Based on that, these changes really seems like great fodder for being encoded in the domain name, imho.''

Paul also said,
  ``We considered things like this for TLSA, and the WG seemed very hesitant…''
I also don't agree with this, which I noted in my response:  ``difference between saying, `don't use this cert for this operation,' and `this cert is universally revoked.'  These really are fundamentally different, and DANE lets us express them that way.''

I also think Scott's suggestion for the certificate access field is a very good one, and I'd very much like to see his suggested text incorporated.