Re: [keyassure] Bare keys again

Phillip Hallam-Baker <hallam@gmail.com> Mon, 21 March 2011 21:03 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 394043A68CB for <keyassure@core3.amsl.com>; Mon, 21 Mar 2011 14:03:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.563
X-Spam-Level:
X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8S558tUyv6BE for <keyassure@core3.amsl.com>; Mon, 21 Mar 2011 14:03:54 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 453E03A68BC for <keyassure@ietf.org>; Mon, 21 Mar 2011 14:03:53 -0700 (PDT)
Received: by qwg5 with SMTP id 5so5245369qwg.31 for <keyassure@ietf.org>; Mon, 21 Mar 2011 14:05:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=abwdWT0oe9eCWWJAwBS7W9btQ/o91wOvTLvW0WyqcMQ=; b=S79Al1LCt+cqWB/vRsgON2lK+02qdzzx3LI9XxQw5ChiCmmVcsGqaQqZPxrwry+2wl VFAsbpTyRQCgkxIixGRx3cFjYMUxFFHtuLgc9ZjJeDwz5rlXeYZEvMt/O9GCGTs059uH yc6Kq4ZFVs/4ZozD6Cf6kGFb+3ELFsxaDtZ5Y=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PizphhhkCYjdgTo02N6HiSScKrhNBlKTWeDEgVRUAWeY6Y2qk7lPjX85BaiDc7lRzS eddMN2gPmqzziY4VBIk5zgknlUInEgS5RQl2pyk7eguc6quhLhJ3Nv1/F9na64v86eJU NF5jazyJEBBuk8IUqopM+v4jyQ5EZxDIxN/Eo=
MIME-Version: 1.0
Received: by 10.224.173.79 with SMTP id o15mr3812778qaz.221.1300741526279; Mon, 21 Mar 2011 14:05:26 -0700 (PDT)
Received: by 10.52.167.100 with HTTP; Mon, 21 Mar 2011 14:05:26 -0700 (PDT)
In-Reply-To: <AANLkTimyOXv66UeG2q2dmt1-e_Ek6WPPH-coueFc7fDS@mail.gmail.com>
References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <alpine.LFD.1.10.1103201932370.20162@newtla.xelerance.com> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <alpine.LFD.1.10.1103202028110.20162@newtla.xelerance.com> <1300669586.2117.12.camel@localhost> <alpine.LFD.1.10.1103202211390.20162@newtla.xelerance.com> <1300739370.2117.40.camel@localhost> <alpine.LFD.1.10.1103211631260.20162@newtla.xelerance.com> <AANLkTimyOXv66UeG2q2dmt1-e_Ek6WPPH-coueFc7fDS@mail.gmail.com>
Date: Mon, 21 Mar 2011 17:05:26 -0400
Message-ID: <AANLkTin1QjUbVFN8FqjL2SPRLSRRw4Ahs4zbhy4ZdZuX@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary="20cf303343e99e548b049f047cb5"
Cc: keyassure@ietf.org
Subject: Re: [keyassure] Bare keys again
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Mar 2011 21:03:55 -0000

As a meta point here, the only point to doing work in IETF is to 1) get buy
in from people in your working group and 2) get buy in from people in other
working groups.

Trying to use DANE as a means of eliminating X.509 from TLS is a non-starter
as far as I am concerned. If this group is not going to listen to the TLS WG
or the PKIX WG there is not a lot of point in it being here. Its like going
to the Bayreuth festival and not wanting to go to opera.


Trying to modify Internet protocols is like trying to change the wheels on a
bike while the rider is still riding it (yeah, people really do that for a
job).

Trying to modify Internet security protocols is like playing a game of Jenga
on the rider's helmet with the guy trying to change his wheel.


What might appear to be a minor change to the protocol can have significant
and unpredictable results throughout the system.

The way we avoid such results is mostly to avoid changes that do not have a
very very good justification.


Not liking ASN.1 is not a justification in my view.