Re: [dane] terminology question
Viktor Dukhovni <viktor1dane@dukhovni.org> Wed, 04 December 2013 00:42 UTC
Return-Path: <viktor1dane@dukhovni.org>
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 B95E61ADE89 for <dane@ietfa.amsl.com>; Tue, 3 Dec 2013 16:42:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 1HYO4wum7Rvd for <dane@ietfa.amsl.com>; Tue, 3 Dec 2013 16:42:10 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 45E6B1ADF79 for <dane@ietf.org>; Tue, 3 Dec 2013 16:42:10 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2D6C72AB141; Wed, 4 Dec 2013 00:42:07 +0000 (UTC)
Date: Wed, 04 Dec 2013 00:42:07 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20131204004207.GX761@mournblade.imrryr.org>
References: <529E7488.80601@stpeter.im>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <529E7488.80601@stpeter.im>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] terminology question
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
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: Wed, 04 Dec 2013 00:42:12 -0000
On Tue, Dec 03, 2013 at 05:17:12PM -0700, Peter Saint-Andre wrote: > In particular, RFC 6125 uses the term "source domain" to refer to the > fully qualified domain name that a TLS client expects to find in the > certificate (or, in DANE, potentially the key) that is presented by > the TLS server. RFC 6125 also uses the term "derived domain" to refer > to a domain name (or host name) that the client has derived from the > source domain in an automated fashion (e.g., via a DNS SRV record). > > As far as I can determine, draft-ogud-dane-vocabulary uses the terms > "Query [Name]" and "Final [Name]" for something like "source domain" > and "derived domain". However, draft-ogud-dane-vocabulary also uses > the terms "Service Specification Records" and "Service Address > Records" in a way that might be similar, although I confess that I > don't really grok draft-ogud-dane-vocabulary in fullness and the > latter two terms are unclear to me. > > Naming is hard, and I hope we can get it right. With DANE the name the client expects to find in a peer certificate is the "TLSA base domain". Thus if the TLSA records were found via: _25._tcp.mx.example.com. IN TLSA 3 1 1 {blob} (even if that was an alias for some other location in DNS) the "TLSA base domain" is "mx.example.com" and with usages other than 3, that's basically what one looks for in the peer certificate. At least for SMTP, there is an additional twist, because when the TLSA base is the result of an MX lookup: example.com. IN MX 0 mx.example.com. the DANE SMTP draft (in agreement with the expired SRV draft) specifies that "example.com" is also an acceptable name in the peer certificate. This allows sites with pre-DANE "UCC" certificates that only match the email domain, to be acceptable to both DANE and non-DANE clients. Thus a DANE SMTP client will admit either the original domain or the MX hostname as a valid SMTP server name. All that said, I am not directly answering your question. Just pointing out that the "TLSA base domain" is the natural analogue of the actual (derived?) domain used for peer verification, except that with DANE the "derivation" process is always DNSSEC validated. With SMTP (and perhaps if we stay with the spirit of the expired SRV draft) when the TLSA base domain differs from the "source domain" (e.g. envelope recipient domain) it would be also be a valid peername. -- Viktor.
- Re: [dane] terminology question Olafur Gudmundsson
- [dane] terminology question Peter Saint-Andre
- Re: [dane] terminology question Viktor Dukhovni
- Re: [dane] terminology question Peter Saint-Andre
- Re: [dane] terminology question Olafur Gudmundsson