IETF Logo Mail Archive

Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys

John Gilmore <gnu@toad.com> Fri, 06 June 2014 01:41 UTC

Return-Path: <gnu@toad.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 411A41A0382 for <dane@ietfa.amsl.com>; Thu, 5 Jun 2014 18:41:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.102
X-Spam-Level:
X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RP_MATCHES_RCVD=-0.651] autolearn=no
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 QJpUBEczmATn for <dane@ietfa.amsl.com>; Thu, 5 Jun 2014 18:41:02 -0700 (PDT)
Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0459A1A0380 for <dane@ietf.org>; Thu, 5 Jun 2014 18:41:02 -0700 (PDT)
Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id s561esBT021883 for <dane@ietf.org>; Thu, 5 Jun 2014 18:40:54 -0700
Message-Id: <201406060140.s561esBT021883@new.toad.com>
To: dane@ietf.org
In-reply-to: <20140605151145.GA27883@mournblade.imrryr.org>
References: <OFB1999EAD.836E27A5-ON85257CE8.0067D557-85257CEB.000B5F5E@us.ibm.com> <20140602022733.GK27883@mournblade.imrryr.org> <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> <20140602172922.GS27883@mournblade.imrryr.org> <alpine.LFD.2.10.1406030056500.19868@bofh.nohats.ca> <20140603130839.GY27883@mournblade.imrryr.org> <m3ppip5s57.fsf@carbon.jhcloos.org> <20140604025535.GJ27883@mournblade.imrryr.org> <4e941a7fe4be00884d43cf848b30bec228883452@8b5064a13e22126c1b9329f0dc35b8915774b7c3.invalid> <20140605151145.GA27883@mournblade.imrryr.org>
Comments: In-reply-to Viktor Dukhovni <viktor1dane@dukhovni.org> message dated "Thu, 05 Jun 2014 15:11:45 -0000."
Date: Thu, 05 Jun 2014 18:40:54 -0700
From: John Gilmore <gnu@toad.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/_umKqDdYPeOYYsyfHBzJjRV15QE
Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys
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: Fri, 06 Jun 2014 01:41:03 -0000

> Finally, the WG could decide that servers which publish U/S/M
> combinations in their TLSA RRset that contain only future or only
> past keys are "misconfigured", and that servers SHOULD NOT do that.

I don't understand how any crypto protocol can succeed when it
authenticates only past or future keys, not the keys in present use.

Can you explain why you think such a server is NOT misconfigured?  Or
perhaps you will agree that this is misconfiguration, but you think
that for some reason that you can state, many people will foolishly
misconfigure their servers this way, such that the protocol should
gracefully handle that "common misconfiguration" case?

Struggling to understand,

	John

v2.23.0 | Report a Bug | By Email