Re: [dane] draft-ietf-dane-smime and certificate discovery

"Osterweil, Eric" <> Wed, 05 February 2014 21:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 426D71A022B for <>; Wed, 5 Feb 2014 13:19:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H3wKivzXzR1f for <>; Wed, 5 Feb 2014 13:19:33 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6E36E1A0234 for <>; Wed, 5 Feb 2014 13:19:27 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID DSNKUvKq3pJhcG0M2IBT/T7QKyYfpJRE/; Wed, 05 Feb 2014 13:19:27 PST
Received: from ( []) by (8.13.6/8.13.4) with ESMTP id s15LJP9t021375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 16:19:26 -0500
Received: from ([::1]) by ([::1]) with mapi id 14.02.0342.003; Wed, 5 Feb 2014 16:19:25 -0500
From: "Osterweil, Eric" <>
To: Paul Hoffman <>
Thread-Topic: draft-ietf-dane-smime and certificate discovery
Thread-Index: AQHPIrYeUFxijq0eb0qd3oWTI9ga7ZqnfkgA
Date: Wed, 5 Feb 2014 21:19:24 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<>" <>
Subject: Re: [dane] draft-ietf-dane-smime and certificate discovery
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 21:19:35 -0000

On Feb 5, 2014, at 4:06 PM, Paul Hoffman <>

> On Feb 5, 2014, at 7:17 AM, Osterweil, Eric <> wrote:
>> Specifically, DANE is (imho) excellent example of a standard architecture for certificate discovery using DNS.  
> As has been noted in many places over the past few decades, using the DNS for information deliver vs. information discover are very different things. Jakob and I have chosen to go with the standard assumption that the DNS is for information delivery, and other protocols (these days, mostly HTTP) can be used for information discovery.
> If the DANE WG wants to change this, and the IETF at large agrees, we can certainly walk down that path, both with this document and with TLSA itself.

Hey Paul,

Thanks for the quick response.  I am, however, a little puzzled by it.  So, is there some reason why these discussions here (on the WG list) are not the actual substance of determining what the DANE WG wants?  As I understand it (perhaps incorrectly?), we are discussing a working group document, so discussion of its contents should be inbounds and any resulting rough WG consensus should help direct its contents, no?

As for the broader statement of what DNS is for, and what the IETF at large thinks, I think perhaps you have expressed your own opinion here, and I (personally) do not agree.  In my view, DNS is (very much) a resource mapping (i.e. learning) mechanism.  That's how we find routable endpoints for HTTP. ;)  Content delivery aside.  I suspect you and I may actually be on the same page on that one, but apparently not on the learning issue.

Back to the main issue, I am following up on Scott's solicitation for discussion about his proposed changes, and expressing my support for them.  I have read your response to those and responded to it, and I am happy to discuss the technical details further.