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

"Osterweil, Eric" <> Mon, 20 October 2014 15:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0842C1A1B7F for <>; Mon, 20 Oct 2014 08:30:06 -0700 (PDT)
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 WRr-8a5MTTOM for <>; Mon, 20 Oct 2014 08:30:04 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC4C51A6EF0 for <>; Mon, 20 Oct 2014 08:23:58 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID DSNKVEUpDkkVpoBbkWKSzMA/; Mon, 20 Oct 2014 08:24:01 PDT
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id s9KFNvY4023995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Oct 2014 11:23:57 -0400
Received: from ([::1]) by ([::1]) with mapi id 14.03.0174.001; Mon, 20 Oct 2014 11:23:56 -0400
From: "Osterweil, Eric" <>
To: Paul Hoffman <>
Thread-Topic: [dane] draft-ietf-dane-smime
Thread-Index: AQHP2+CXduy9obN06UaH3lWvHXXI5ZwabJwAgBgn4ICAAikmgIAEwWkA
Date: Mon, 20 Oct 2014 15:23:57 +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] 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:30:06 -0000

On Oct 17, 2014, at 10:46 AM, Paul Hoffman <> wrote:

> On Oct 15, 2014, at 10:46 PM, Sean Turner <> wrote:
>> The idea that the proponents of these changes need to go change the TLSA spec because you think it applies to both seems a little bit excessive.  If you think the changes apply to both, then great feel free to go and propose those changes get made in the TLSA spec; I see no reason to burden the proponents of these changes with that job.
> Nor do I see a reason for the proponents to burden us with making the changes here if there is no support for them. As you probably saw, another WG member pointed out that there were significant technical issues with the wording of the revocation proposal. If we incorporate that into the S/MIME draft, that draft will get delayed while the proponents get their wording right.

Hey Paul,

TLS and S/MIME use pretty different security models (session vs. object security), so necessarily coupling the RRs doesn’t seem to make sense.  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.

> 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.  Also, isn’t the SMIMEA work still an evolving draft?  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?  Please accept the proposed SMIMEA changes into the SMIMEA draft so that we can make progress on this work.

Thank you,