Subject: [dane] #28: Interaction of SRV and TLSA records

From: "dane issue tracker" <[email-masked]>
Date: Thu, 04 Aug 2011 06:42:47 -0000

#28: Interaction of SRV and TLSA records

 Issue raised by Jim Schaad in:

 http://www.ietf.org/mail-archive/web/dane/current/msg03044.html

 And the issue is, if we have:

 _jabber._tcp.jabber.alice.com IN SRV 5 0 5269 jabber.bob.com.
 _xmpp-client._tcp.jabber.alice.com IN SRV 5 0 5222 jabber.bob.com.
 _xmpp-server._tcp.jabber.alice.com IN SRV 5 0 5269 jabber.bob.com.

 Should the DANE-aware client look-up:

 a) _port._tcp._jabber._tcp.jabber.alice.com IN TLSA <blob>
 b) _5269._tcp.jabber.bob.com

 Or even:
 c) _5269._tcp.jabber.alice.com

 when interacting with [email-masked]?

-- 
--------------------------------+-------------------------------------------
 Reporter:  ondrej.sury@…       |       Owner:  draft-ietf-dane-protocol@…             
     Type:  defect              |      Status:  new                                    
 Priority:  major               |   Milestone:                                         
Component:  protocol            |     Version:                                         
 Severity:  -                   |    Keywords:                                         
--------------------------------+-------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dane/trac/ticket/28>
dane <http://tools.ietf.org/dane/>

---

From: "dane issue tracker" <[email-masked]>
Date: Thu, 04 Aug 2011 07:47:23 -0000

Comment(by jakob@…):

 Given that DANE provides an association between a hostname and a
 certificate, and jabber.bob.com is the host where the service is provided,
 I'd go for (b). I also recommend we provide better examples of this in the
 draft.

Ticket URL: <http://trac.tools.ietf.org/wg/dane/trac/ticket/28#comment:1>
dane <http://tools.ietf.org/dane/>

---

From: "dane issue tracker" <[email-masked]>
Date: Fri, 05 Aug 2011 02:52:17 -0000

Comment(by matt@…):

 To amplify [comment:1 comment 1]: DANE applies to a service endpoint
 identified by (hostname, transport, port), i.e., after any service
 discovery process that plays a part in determining this tuple.  So (b).

 For a while, Phill wanted to entangle service discovery with DANE; I don't
 know that he ever accepted my decomposition, but at least he stopped
 claiming that I had failed to justify it.

Ticket URL: <http://trac.tools.ietf.org/wg/dane/trac/ticket/28#comment:2>
dane <http://tools.ietf.org/dane/>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 5 Aug 2011 09:59:25 -0400

Why is this an issue?  I thought that there was a fair bit of agreement that SRV resolution was a step before DANE came into play, and thus that the two processes are not interrelated.  After all, the TLS server is not the name you start the SRV process with, it's the result, and DANE addresses only the TLS server, not any application-layer identity of the server.

Opening an XMPP connection to example.com with SRV and DANE
1. Look up SRV _xmpp-server._tcp.example.com
2. Get _xmpp-server._tcp.example.com SRV xmpp1.hoster.com
3. Look up TLSA _5222._tcp.xmpp1.hoster.com
4. [[ follow any requisite CNAMEs ]]
5. Get _5222._tcp.xmpp1.hoster.com TLSA ... [[ or CNAME-redirected ]]
6. Proceed with TLS connection

--Richard

On Aug 4, 2011, at 10:52 PM, dane issue tracker wrote:

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 5 Aug 2011 16:51:04 +0200

> Why is this an issue?  I thought that there was a fair bit of agreement that SRV resolution was a step before DANE came into play, and thus that the two processes are not interrelated.  After all,…

+1

	jakob

---

From: Martin Rex <[email-masked]>
Date: Fri, 5 Aug 2011 18:23:47 +0200 (MEST)

Richard L. Barnes wrote:
> Why is this an issue?

The purpose of both, traditional TLS server endpoint identification
and DANE is similar: provide some means to verify the identity of the
server (it is similar to "authentication", but weaker).

>
>                         I thought that there was a fair bit of agreement
> that SRV resolution was a step before DANE came into play, and thus that
> the two processes are not interrelated.

There are _very_ interrelated.  As long as we cling to the concept
that "the user wanted to access 'example.com'", we have to ensure
that whatever the user gets is securely authorized by 'example.com'".

The answer to the different question "have i connected to server.foobar.net"
(by itself) is not a valid substitute to the users stated intend
to connect to "example.com", unless there is a TLSA record in example.com
that confirms that the certificate presented by server.foobar.net is
authorized to provide the service for "example.com".

>
> After all, the TLS server is not the name you start the SRV process with,
> it's the result, and DANE addresses only the TLS server, not any
> application-layer identity of the server.
> 

If you want to use SRV as described above, you imply that you do
not care about server endpoint identification at all (It might be
that you do not intend to say that, but technically, that is what
you do by requesting to look at the name that comes _out_of_ a
DNS SRV lookup rather than matching against the reference name that
the application starts with (and that goes _into_ the SRV lookup).

As I described in a previous message, for XMPP the 

-Martin

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 5 Aug 2011 13:25:29 -0700

So just to be clean in my mind, a client does the following:

1.  Map a service name to a server name.  This would be done in a service
specific manner using things such as MX or SRV records, funny naming (prefix
naming) and so forth.

2.  Map the server name to an address

3.  Retrieve the TSLA records based solely on the server name, protocol and
port number.

We are therefore ruling out of scope for DANE any matching for the TLS
session certificates based on the service/domain name pair as oppose to the
server name.   If for example, the protocol FOO defined a name form of
FOO:<domain name> and said that it is to be published in a certificate as a
SAN and that no server DNS name is to be published then there would be no
way to deal with indirecting through a SRV record to get from a service name
to a server name.

i.e.

_FOO.alice.com IN SRV 1 1 5990 alice.oscar.com

Could never have a certificate with the SAN of FOO:alice.com but would
instead need to have an SAN of FOO:alice.oscar.com as that is the only
server name we would have and DANE has stated that we only deal with server
names and not service names.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Richard L. Barnes
> Sent: Friday, August 05, 2011 6:59 AM
> To: dane issue tracker
> Cc: [email-masked]; [email-masked]
> Subject: Re: [dane] #28: Interaction of SRV and TLSA records
> 
> Why is this an issue?  I thought that there was a fair bit of agreement
that
> SRV resolution was a step before DANE came into play, and thus that the
two
> processes are not interrelated.  After all, the TLS server is not the name
you
> start the SRV process with, it's the result, and DANE addresses only the
TLS
> server, not any application-layer identity of the server.
> 
> Opening an XMPP connection to example.com with SRV and DANE 1. Look up
> SRV _xmpp-server._tcp.example.com 2. Get _xmpp-
> server._tcp.example.com SRV xmpp1.hoster.com 3. Look up TLSA
> _5222._tcp.xmpp1.hoster.com 4. [[ follow any requisite CNAMEs ]] 5. Get
> _5222._tcp.xmpp1.hoster.com TLSA ... [[ or CNAME-redirected ]] 6. Proceed
> with TLS connection
> 
> --Richard
> 
> 
> 
> > Comment(by matt@.):
> > For a while, Phill wanted to entangle service discovery with DANE; I
> > don't know that he ever accepted my decomposition, but at least he
> > stopped claiming that I had failed to justify it.
> >
> > --
> > --------------------------------+-------------------------------------
> > --------------------------------+------
> > Reporter:  ondrej.sury@.       |       Owner:
draft-ietf-dane-protocol@.
> > --------------------------------+-------------------------------------
> > --------------------------------+------
> >
> > Ticket URL:
> > <http://trac.tools.ietf.org/wg/dane/trac/ticket/28#comment:2>

---

From: Mark Andrews <[email-masked]>
Date: Sat, 06 Aug 2011 11:09:42 +1000

In message <[email-masked]>, Martin Rex writes
> the application starts with (and that goes _into_ the SRV lookup).

No, there are just different security models for the different
transport models.  HTTP uses one model and SMTP uses a different
model.  HTTP is direct, SMTP is store and forward.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Leif Johansson <[email-masked]>
Date: Sat, 06 Aug 2011 13:40:04 +0200

>> Why is this an issue?  I thought that there was a fair bit of agreement that SRV resolution was a step before DANE came into play, and thus that the two processes are not interrelated.  After all,…

I tried to introduce the SRV analogy to prove that very point.
Unfortunately the point was somewhat lost.

	Cheers Leif

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 6 Aug 2011 08:10:02 -0700

> when interacting with [email-masked]?

(b), based on the idea that the user's agent will know that it was connecting to jabber.bob.com after doing the SRV lookup. 

--Paul Hoffman

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 8 Aug 2011 08:21:18 -0400

That's not quite correct.  The matching of names in certificates happens a layer above DANE; DANE is about finding a certificate for a name and verifying its validity as a certificate, not necessarily its validity as a credential for a particular name or service.  That process is specified by RFC 2818, RFC 6125, etc.

So for example, an XMPP hosting provider's server xmpp1.provider.com might have a cert that has an SRVName SAN for _xmpp-server._tcp.customer.com.  The hosting provider could then provision that cert in a TLSA record under _port._tcp.xmpp1.provider.com in order to facilitate discovery.  But the SRVName would still be there for the application to use in authenticating the remote entity.

--Richard

---

From: [email-masked]
Date: Tue, 9 Aug 2011 09:23:51 +0000

and how are caches folded into this mix?  in steps 2 & 3, if I preload
 a cache w/ data, your resolver is going to use it, right?

/bill

---

From: Tony Finch <[email-masked]>
Date: Wed, 10 Aug 2011 17:28:40 +0100

Richard L. Barnes <[email-masked]> wrote:
>
> So for example, an XMPP hosting provider's server xmpp1.provider.com
> might have a cert that has an SRVName SAN for
> _xmpp-server._tcp.customer.com.  The hosting provider could then
> provision that cert in a TLSA record under _port._tcp.xmpp1.provider.com
> in order to facilitate discovery.  But the SRVName would still be there
> for the application to use in authenticating the remote entity.

If the certificate matches the customer domain, why isn't the TLSA record
attached to the customer domain too?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher: Northwest 5 to 7, veering northeast 3 or 4. Moderate, occasionally
rough at first. Rain in south. Good, occasionally moderate or poor in south.