Re: [dane] Servers which offer RPK but have no TLSA records for that key

John Gilmore <gnu@toad.com> Fri, 06 June 2014 01:30 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 B092F1A037A for <dane@ietfa.amsl.com>; Thu, 5 Jun 2014 18:30:19 -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 TI_3hT6fPWHv for <dane@ietfa.amsl.com>; Thu, 5 Jun 2014 18:30:19 -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 0D1EA1A0379 for <dane@ietf.org>; Thu, 5 Jun 2014 18:30:19 -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 s561UBBT021673 for <dane@ietf.org>; Thu, 5 Jun 2014 18:30:11 -0700
Message-Id: <201406060130.s561UBBT021673@new.toad.com>
To: dane@ietf.org
In-reply-to: <20140605232509.GQ27883@mournblade.imrryr.org>
References: <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> <m3bnu93yzc.fsf@carbon.jhcloos.org> <201406052227.s55MREBT016220@new.toad.com> <20140605232509.GQ27883@mournblade.imrryr.org>
Comments: In-reply-to Viktor Dukhovni <viktor1dane@dukhovni.org> message dated "Thu, 05 Jun 2014 23:25:09 -0000."
Date: Thu, 05 Jun 2014 18:30:11 -0700
From: John Gilmore <gnu@toad.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/uJu1r4xja-puBjt2qzlyV2b_1MY
Subject: Re: [dane] Servers which offer RPK but have no TLSA records for that key
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:30:19 -0000

> You're saying that the server should know the sorry state of its
> DNS TLSA RRs as seen by the client.  This is likely impractical.
> Servers just have key material and do TLS handshakes they are
> DNSSEC/DANE agnostic.  They have no idea what mechanism if any the
> client is planning to use to authenticate the server's keys/certs.

I agree that the server software should not be trying to figure out
"TLSA RRs as seen by the client".  The server may not have access to
the same DNS servers as the client.  The best that we can ask is
that the system administrator of the server "keeps in mind" the
public configuration of the TLSA records that relate to the server.

I would be surprised to hear anyone in this group claiming that the
TLS server can be configured completely independently of the TLSA
records published in its domain.  In particular, the keys used in the
TLSA records and in the TLS server have to be coordinated so that they
match.  If they are not coordinated, DANE will never work with that
TLS server.

So, given that the people who configure the server must already know
whether their domain is publishing TLSA records that authenticate
their PKIX certificate, why is it such a stretch for the people who
configure the server to also know whether their domain is publishing
TLSA records that authenticate an RPK used by the server?

	John