Subject: [dane] terminology question

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 03 Dec 2013 17:17:12 -0700

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.

Naming is hard, and I hope we can get it right.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 4 Dec 2013 00:42:07 +0000

> 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.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 4 Dec 2013 08:47:50 -0500

On Dec 3, 2013, at 7:17 PM, Peter Saint-Andre <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

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). 

"Source domain" definition  is a good example of this. In -vocabulary- draft 
the application issues query for "query name" where it is expecting to find the "Service Specification Records". 
but DNAME/NAPTER/CNAME  rules may rewrite the name sent to application server to the "resulting name" from the query 
thus the term "Offered Name". 

For HTTP Service Specification Records == Service Address records i.e. address record is the service specification, 
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. 

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.

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). 

> 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 :-) 

	Olafur

> 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/
> 
> iQIcBAEBAgAGBQJSnnSIAAoJEOoGpJErxa2pIPcP/3ynoIh5Xn1oBXMtf1Tj4yyZ
> sJc2kEoA1r49CLCz3TsqHaQonB/lK6tZP0WGYoNobj/C6Vd9U8RQW2TElWM7fVo1
> ltZmBA0Tx6KHv/XQmnNsrKVbiueqMui5tWvyHDE/x/Wt18lJPM1n4LdY+xkR4O62
> en7PCNTLNxAjkpjPKrEqbp0YYiI67rsnKxNOEJkjry3l+j9FOYlPyBtHAyRZISgV
> YKy6eIyIEGYOfIXtiiEYPx3UNgIuOLpozu5OWAmypdP6xTfXYmHpAX9HVD7lPPqK
> ZOGzz61RYDSid186uBQGizahaAabRvIwayQ8ZZTr7C+JYW//CckRRrC04R12h9K+
> qNfnzSzf11x01VMfEK2V7muD2uqi28LBXsC/vY2E/r6FRxAp7BS1OZccFK224NnK
> xI+ETnMsl/ZaWIOKhyJk44bWODWr6ij1Gxen3UoEIsU90akFmzCuCEdbdgf0lATr
> wX71rVUi5O/ytHQZ/YfhOtc2j7qbrnfSc7KZcgr7X7IkhexP3/nVKtuziqdrbL4U
> i7pVh5xlgyTszEyowyKWIjr0+J98Llbdz0Xs1hTOTwEONW4cx7TsUd05cwdmoc4G
> KLabfuUTYKp4NslfIV4smBIl2uzrYUaz0ACjLQSrzk4dNGZAj0L6IlyS92g211Pl
> WEIrV0m+zIhv6K1ffWiS
> =VUnT
> -----END PGP SIGNATURE-----
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 06 Dec 2013 13:40:49 -0700

Hi Olafur, thanks for the reply. Comments inline.

On 12/4/13 6:47 AM, Olafur Gudmundsson 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,
> 
>> 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 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/