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

Warren Kumari <warren@kumari.net> Mon, 20 October 2014 22:18 UTC

Return-Path: <warren@kumari.net>
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 3CAFB1ACF05 for <dane@ietfa.amsl.com>; Mon, 20 Oct 2014 15:18:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 ydmFPID8BzRW for <dane@ietfa.amsl.com>; Mon, 20 Oct 2014 15:18:10 -0700 (PDT)
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ADC71ACEFE for <dane@ietf.org>; Mon, 20 Oct 2014 15:18:10 -0700 (PDT)
Received: by mail-wi0-f173.google.com with SMTP id fb4so8450858wid.6 for <dane@ietf.org>; Mon, 20 Oct 2014 15:18:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=w7W8DwASCAZ0RXsPwm9VaDR4FtJ6MQSACy/GaTYdwx4=; b=hWIPvoX0LLtvpmcc7xSqM745zAXvrS7OcwrRr396tklhBHDRXQdXSW2F460hDaAmfF FEo4O6+QsxCdYmqFCse2v0bjHd4vjFZeoxA/cSj7IxizLBCFjYmXSXkWlUo/xZF/yKge QabMLIlF1aqLKT6B18UPsnUEG33mt+M6qkctrC5MINU7dLz1Xw73um6ME3Z7oTgyMSAN gWltKMqVXEGa5la3vOGwzdWjSXlFrek5UcxlS68dhEpGR8iv6Wo82R3OQMansrTM5Uyt wNLtnWkZSqxrkUrZlKpmElxUQjh8GgEnCimYeYWCBNKd2ahMccp9gQaLp1pn4YiyRGsv BkwA==
X-Gm-Message-State: ALoCoQnV5inEJhY0J8FKm94cMAzgWS1MWlH6Vt9LjD6AOQ8lUwnvt9hKgB1yxEHpnxCCFUB67OQl
MIME-Version: 1.0
X-Received: by 10.194.63.229 with SMTP id j5mr14371001wjs.23.1413843488871; Mon, 20 Oct 2014 15:18:08 -0700 (PDT)
Received: by 10.194.77.134 with HTTP; Mon, 20 Oct 2014 15:18:08 -0700 (PDT)
In-Reply-To: <CAHw9_iKfQ_6j03TeTHmEOpBNg6xZDZvRu-WAw2OzAykde8fpGQ@mail.gmail.com>
References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com> <CF875C06-E4DA-4DCA-A722-5FDEE04B3069@vpnc.org> <67BDE5B6-58C7-4E0B-8CB4-045E51027D85@ieca.com> <3473729E-BC37-48DB-9ACD-FB872CB666DE@vpnc.org> <FE426405-9658-41BD-BD3B-68D358CC3CEB@verisign.com> <63BF3336-C9B8-4D16-BEB7-D42EFBB7A113@vpnc.org> <DDDF307A-9180-43C2-B612-2B13C2E98A18@verisign.com> <CAHw9_iKfQ_6j03TeTHmEOpBNg6xZDZvRu-WAw2OzAykde8fpGQ@mail.gmail.com>
Date: Mon, 20 Oct 2014 15:18:08 -0700
Message-ID: <CAHw9_iLd5NnosiRufcSYLPU-WD3ZmmGMr=Oks4gNUzQ90sLFVg@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
To: "Osterweil, Eric" <eosterweil@verisign.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/7Z7GZ8WoNw4TBI7ue0-ejyceM60
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "<dane@ietf.org>" <dane@ietf.org>
Subject: Re: [dane] draft-ietf-dane-smime
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Mon, 20 Oct 2014 22:18:13 -0000

On Mon, Oct 20, 2014 at 9:46 AM, Warren Kumari <warren@kumari.net> wrote:
> [top post at random place in thread ]
>
> I'd like everyone to take a breath and step back for a minute. I'd like to
> (off list) arrange a call with Paul and Eric so we can summarize this to be
> as concise as possible and then get the WG consensus *on the actual points
> under discussion*...
>

To help us focus the discussion and help us get make progress, we will
be putting this conversation on hold, and discussing the requirements
document - draft-osterweil-dane-ent-email-reqs-00.

Eric will review the doc, revise it if necessary (along with his
co-chairs) and then either post it or let us know that it is still up
to date and then we'll discuss it and the requirements. This should
let us make progress on this doc...

Thanks to everyone for being willing to discuss this in a civil manner...

w


> W
>
>
> On Monday, October 20, 2014, Osterweil, Eric <eosterweil@verisign.com>
> wrote:
>>
>>
>> On Oct 20, 2014, at 11:54 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>>
>> > On Oct 20, 2014, at 8:23 AM, Osterweil, Eric <eosterweil@verisign.com>
>> > 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.
>>
>> The relevant information needed during distribution would seem to vary
>> based on the security model (as evidenced by this thread).  Actually, that’s
>> been one of the main points of this thread.
>>
>> >> , 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.
>>
>> Paul, we are all part of the working group.  This is the the working
>> group.  I feel like I must be missing some nuanced distinction you have in
>> mind between working group discussions (like this one) and some other
>> arbitration?
>>
>> >> 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)
>>
>> Paul, these were not my proposals.  These were proposed by Scott Rose.  I
>> saw merit in them and when they seemed to be dismissed out of hand I voiced
>> my support.  Also, the proposal included the _encr + _sign labels.
>>
>> > 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.
>>
>> But we are still roughing out this draft.  This would seem to be a good
>> opportunity to try and get things write in the initial work.
>>
>> >>> 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.
>>
>> I think this thread is devolving.  The number is greater than two, and
>> reviewing the posts of this thread should corroborate the higher level of
>> interest.
>>
>> >> 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, what constituted ``the WG’’ in your mind?
>>
>> Eric
>> _______________________________________________
>> dane mailing list
>> dane@ietf.org
>> https://www.ietf.org/mailman/listinfo/dane
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad idea in
> the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair of
> pants.
>    ---maf



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf