Re: [dane] terminology question
Peter Saint-Andre <stpeter@stpeter.im> Fri, 06 December 2013 20:40 UTC
Return-Path: <stpeter@stpeter.im>
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 7E7131AE3CE for <dane@ietfa.amsl.com>; Fri, 6 Dec 2013 12:40:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.49
X-Spam-Level:
X-Spam-Status: No, score=0.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=2.393] 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 Q4woZ4quBEJD for <dane@ietfa.amsl.com>; Fri, 6 Dec 2013 12:40:55 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF961AE3CC for <dane@ietf.org>; Fri, 6 Dec 2013 12:40:55 -0800 (PST)
Received: from sjc-vpn7-1962.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 283B240332; Fri, 6 Dec 2013 13:40:51 -0700 (MST)
Message-ID: <52A23651.4000504@stpeter.im>
Date: Fri, 06 Dec 2013 13:40:49 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Olafur Gudmundsson <ogud@ogud.com>
References: <529E7488.80601@stpeter.im> <C7C6B853-5A06-4DA3-9737-2A633ADA6C65@ogud.com>
In-Reply-To: <C7C6B853-5A06-4DA3-9737-2A633ADA6C65@ogud.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "dane@ietf.org list" <dane@ietf.org>
Subject: Re: [dane] terminology question
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 Dec 2013 20:40:57 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Olafur, thanks for the reply. Comments inline. On 12/4/13 6:47 AM, Olafur Gudmundsson wrote: > > On Dec 3, 2013, at 7:17 PM, Peter Saint-Andre <stpeter@stpeter.im> > wrote: > > In RFC 6125, Jeff Hodges and I tried hard to define some > terminology related to certificate checking in TLS. That > terminology might not be ideal, but I'd like to see if we can > align draft-ogud-dane-vocabulary with the RFC 6125 terms. > > 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. > >> Peter, > >> Thanks asking this question, > >> You made me read RFC6125 and to my horror the vocabulary there >> is attempting similar things as I'm doing in my draft, but in >> section 1.8 I realized that you might have taken a shortcut that >> leads to a incomplete specification i.e. you are not taking into >> account the effects of CNAME and DNAME records on the resolution, >> in particular DNAME requires careful rules as to the names used >> to present to the servers. (my guess is this is where the "i >> don't really grok" comment comes from) (I think NAPTR has >> similar effects). You are right, we did not address CNAME, DNAME, or NAPTR. The spec was already convoluted enough. :-) But I think that was an oversight on our part. I've bcc'd Jeff so he's aware of it. >> "Source domain" definition is a good example of this. In >> -vocabulary- draft the application issues query for "query name" Which, I take it, is roughly equivalent to "Name" in RFC 2782, right? >> where it is expecting to find the "Service Specification >> Records". I'm not clear on exactly what those are. Perhaps a few (clearer?) examples would help. The current examples confuse me: Protocols have different ways to provide information about where servers are located. Web servers are frequently specified by name i.e. the "www" prefix. Email servers have a special RR type (MX), Jabber uses SR records, ENUM uses NAPTR records etc. and there are also protocols that use a combination like S-NAPTR a schema where NAPTR records are used to specify where to look for SRV records. For all practical purposes NAPTR + SRV should combined be treated as the Service Specification. Does this mean that "www" is a Service Specification Record? ;-) It makes sense to me that, say, the result of an MX or SRV query is a "Service Specification Record" -- a query for _Service._Proto.Name gives you one or more addresses that together specify the service. For example: $ dig +short -t SRV _xmpp-server._tcp.google.com 5 0 5269 xmpp-server.l.google.com. 20 0 5269 alt3.xmpp-server.l.google.com. 20 0 5269 alt2.xmpp-server.l.google.com. 20 0 5269 alt1.xmpp-server.l.google.com. 20 0 5269 alt4.xmpp-server.l.google.com. Is that what you have in mind? >> but DNAME/NAPTER/CNAME rules may rewrite the name sent to >> application server to the "resulting name" from the query Understood. >> thus the term "Offered Name". Offered by whom? >> For HTTP Service Specification Records == Service Address >> records i.e. address record is the service specification, I assume that's because no MX, SRV, etc. is used for HTTP? >> but Jabber uses SRV records for the Service Specification >> Records and the Service Address Records are associated with the >> servers listed in the SRV RRset. What does "associated with" mean here? I find the definition of "Service Address Records" confusing, too: This is where the address records used by the servers reside, specifications SHOULD NOT make a difference between what kind of address records are used. I am not sure what you mean when you talk about location here, i.e., the place where the address records reside. What kind of location are we talking about? >> To a large extent I think the differences we see are due to the >> different approaches, i.e. you are attempting to word rules for >> existing applications. Yes. Plus I don't have a pair of DNS glasses that enables me to see things the way you do. >> I'm defining rules that are general and ignore the names >> existing applications have used an concentrate on concepts that >> then can be used by application specifications. I wanted to >> create definitions that allow minimal DNS related text inside a >> DANE application specification (not sure I'm there yet). Yes, I can see that's what you're doing. However, I find the level of abstraction you've reached to be a bit rarified. At least, it's not grounded in things that I can grasp easily (application space). But that's perhaps my problem, not yours. :-) > Naming is hard, and I hope we can get it right. > > >> Naming of concepts is hard, definitions are hard, understanding >> the nuances of interaction of multiple protocols is even harder >> :-) Indeed. :-) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSojZQAAoJEOoGpJErxa2p0h0P/3fOSLCMyKc2Z4yxQkEtCXf+ xRtPDIhpbpdTmrYPzg8t73HN5gPYYlKKiWknmT4W+k75Gq6OGh7vZSLU+nxD3Tp+ iC42LqEeknpR7SOcWRCmPOloTTJY33E31dQy+K8Dc3/ehzrvtC+Cp7uus5ZbjESS jU3Bzp9ou/q48ALrskDuiIJa8+GXKsOyjSLKv4NZxWnSa8+9yt+xNxGZNlsU4p5M kYXpGPcM4FOhxkb9y35uvLzKciqNE+/NLDc/bat9cMLhwHsEbOQOdaJJhnROb8XD hzvuMhCOJtQdrm1dFBz3oJFqB7/VH/vRoipBzLgBnrR4eprDmljCXVKHvF4EBP47 xxruB9Vz3jWUJ+Bu+XcRaGdYutbmdm/DaylwZoKaLCXqD8hyCtdkcdSMLA7XlpCr ZZyfB3wzVOMSWSD/numW5TZxRAwMTaDQSvHZOg9qzRf+JVMaZviH91U4iTY7xAGU s9Y0+8HEpJ+Jvs7CdcR+DssEGGtBMA/VCijjAP9wvZibJBjzBuysWrsBT6Jt8eHd Iatffaggul5KAgQeup4NrURUUo4BzgYt/ND2oTocwvPVeeqMUJrWgKC597iWKwdh 4DcIPcmcXCmLG7m0eDnRaUAOacqA0eItQkwK+0hy47k+QMYGfGqw2OUWpFnR1BlG GZ7kxLGOJGk3NqcwXYAG =CHE4 -----END PGP SIGNATURE-----
- [dane] terminology question Peter Saint-Andre
- Re: [dane] terminology question Viktor Dukhovni
- Re: [dane] terminology question Olafur Gudmundsson
- Re: [dane] terminology question Peter Saint-Andre
- Re: [dane] terminology question Olafur Gudmundsson