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

"Osterweil, Eric" <eosterweil@verisign.com> Thu, 06 February 2014 01:50 UTC

Return-Path: <eosterweil@verisign.com>
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 B26FB1A01E0 for <dane@ietfa.amsl.com>; Wed, 5 Feb 2014 17:50:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcOsoaymql9e for <dane@ietfa.amsl.com>; Wed, 5 Feb 2014 17:50:41 -0800 (PST)
Received: from exprod6og118.obsmtp.com (exprod6og118.obsmtp.com [64.18.1.233]) by ietfa.amsl.com (Postfix) with ESMTP id 809471A0194 for <dane@ietf.org>; Wed, 5 Feb 2014 17:50:40 -0800 (PST)
Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob118.postini.com ([64.18.5.12]) with SMTP ID DSNKUvLqb4Ed9q+xJqKaiPLxTF63ZXZ2H0dP@postini.com; Wed, 05 Feb 2014 17:50:40 PST
Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s161oc30028562 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 20:50:38 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 5 Feb 2014 20:50:38 -0500
From: "Osterweil, Eric" <eosterweil@verisign.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Thread-Topic: [dane] draft-ietf-dane-smime and certificate discovery
Thread-Index: AQHPIrYeUFxijq0eb0qd3oWTI9ga7ZqnfkgAgAAkWICAACdtAA==
Date: Thu, 6 Feb 2014 01:50:37 +0000
Message-ID: <3DF5DF99-1550-4E69-AC0E-4E207433626B@verisign.com>
References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> <A1C41700-578C-45C1-9A66-ACC051970F47@gmail.com> <5DEFF47F-6533-4F1B-8D23-216108989787@verisign.com> <03FF6C3C-0542-4D0F-97D5-1785F55D2CEF@vpnc.org> <FAB9D9AB-023B-48E3-BD26-15FC9B87FE3F@verisign.com> <6F632081-95C9-4E61-831D-EAEF2ECCE08C@vpnc.org>
In-Reply-To: <6F632081-95C9-4E61-831D-EAEF2ECCE08C@vpnc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.152.4]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2BD19E260720334AAC7B01FBEB6883D0@verisign.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<dane@ietf.org>" <dane@ietf.org>
Subject: Re: [dane] draft-ietf-dane-smime and certificate discovery
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: Thu, 06 Feb 2014 01:50:43 -0000

On Feb 5, 2014, at 6:29 PM, Paul Hoffman <paul.hoffman@vpnc.org>
 wrote:

> On Feb 5, 2014, at 1:19 PM, Osterweil, Eric <eosterweil@verisign.com> wrote:
> 
>> 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?
> 
> It is often better if a WG decides on a direction, not just a specific technology. During the TLSA discussions, there were many threads about delivery vs. discovery, and the WG early on went for "delivery, not discovery". As I said in the previous message, if the WG wants to revisit that decision and goes towards "discovery", there are lots of ways we can make TLSA and SMIMEA records have some interesting new properties.

Paul, I don't think we have nearly enough data points to prescribe the general principles of all DANE protocols.  We have TLSA, and that is great.  I sincerely mean that, I think the TLSA work is a great step forward.  However, I also think that a starting assumption that prescribes that all DANE protocols should be executed under the same pre-computed discussions as the TLSA work is very bad for DANE.  S/MIME's semantics, requirements, and usage are different than TLS'.  How different?  I don't even claim to know that.  I think this line of discussion (disc vs. deliv) marginalizes the very specific issues that Scott raised and the subsequent issues that I raised.  Can we try to stay on point?

>> 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.
> 
> I'm agnostic, and am happy for this document and TLSA go whichever way the IETF wants. However, I'm not in favor of trying to cross the line and see if the IETF notices.

I see you keying in on words, and I worry you're objecting to phraseology rather than the technical issues.  Would you prefer to reboot the conversation with more specific terminology?  These issues are important, so how about ``key learning.'' That is, imho, a more accurate description anyway.

>> 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.
> 
> It's not the technical issues that are important, however.
> 
> So, WG: is "DNS for delivery vs. DNS for delivery and discovery" a topic people want to revisit?

No, sorry, this is not the question that I raised.  I offered very specific technical justifications for technical suggestions.  Any answer to the above is not something I have raised or am discussing.

Eric