Re: [dane] terminology question

[Peter Saint-Andre <[e-mail]>]

-----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 <[e-mail]> 
> 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-----