Re: [dane] terminology question
Olafur Gudmundsson <ogud@ogud.com> Fri, 14 February 2014 21:49 UTC
Return-Path: <ogud@ogud.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 0A9BF1A0437 for <dane@ietfa.amsl.com>; Fri, 14 Feb 2014 13:49:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.493
X-Spam-Level:
X-Spam-Status: No, score=0.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 QMY9E-W84RhI for <dane@ietfa.amsl.com>; Fri, 14 Feb 2014 13:49:50 -0800 (PST)
Received: from smtp68.ord1c.emailsrvr.com (smtp68.ord1c.emailsrvr.com [108.166.43.68]) by ietfa.amsl.com (Postfix) with ESMTP id CC2951A03E4 for <dane@ietf.org>; Fri, 14 Feb 2014 13:49:46 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 4281B148405; Fri, 14 Feb 2014 16:49:45 -0500 (EST)
X-Virus-Scanned: OK
Received: by smtp1.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 035D7148257; Fri, 14 Feb 2014 16:49:44 -0500 (EST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Olafur Gudmundsson <ogud@ogud.com>
In-Reply-To: <52A23651.4000504@stpeter.im>
Date: Fri, 14 Feb 2014 16:49:44 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D3B309F-B2FD-4316-9AA4-C73CC3CD4F10@ogud.com>
References: <529E7488.80601@stpeter.im> <C7C6B853-5A06-4DA3-9737-2A633ADA6C65@ogud.com> <52A23651.4000504@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/PwCxvtsJvHQQxk_wis_VakLaX6w
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, 14 Feb 2014 21:49:53 -0000
On Dec 6, 2013, at 3:40 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote: > -----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? Yes just more expressive :-) > >>> 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? ;-) No it says the "A" record at www… is the SSR I will fix this text to be clearer, rewrote the section to large extent. > > 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: > In my terminology the MX is the Service Specification Record. > $ 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? > YES >>> 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? > The application when it sends a "name" in its request after connecting. >>> 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? > Yes we are living with the mistake of HTTP of not using SRV records in the beginning :-) >>> 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? > The intent is say, "the address records returned when the address records of the servers are queried for" ? > 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? > I agree and will fix I was trying to cover both IPv4 and v6 plus the possibility of geolocated address being returned. How about: "These are the address records for the that offer the service." >>> 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. > Nor do I have good App glasses :-) >>> 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. :-) > I think it is both our problems, I need to do better job of explaining, others need to tell me what needs explanation. >> 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. :-) > Sorry for taking this long to respond this fell of my todo list :-( Olafur > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ >
- 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