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

From: Warren Kumari <[email-masked]>
Date: Sun, 8 Jan 2012 20:45:46 -0500

Hi all,

http://trac.tools.ietf.org/wg/dane/trac/ticket/28

I believe that this should be a simple issue for us to open, discuss, reach consensus on and close.

AFAICT, we mainly just need to choose something.

W
---
Don't be impressed with unintelligible stuff said condescendingly .
    -- Radia Perlman.

Warren Kumari
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 8 Jan 2012 17:56:40 -0800

I propose (b) from the ticket. That is, run down the SRV chain fully and then use the final result as the input to the TLSA processing.

BTW, whatever we choose will get analyzed in IETF Last Call be a group of people who know more about SRV processing than we do, so if we pick the "wrong" one now, it will be easy to fix after IETF LC.

--Paul Hoffman

---

From: [email-masked]
Date: Mon, 9 Jan 2012 04:37:53 +0000

> I propose (b) from the ticket. That is, run down the SRV chain fully and then use the final result as the input to the TLSA processing.

	this makes the most sense.

/bill

---

From: Peter Koch <[email-masked]>
Date: Mon, 9 Jan 2012 09:19:29 +0100

> I propose (b) from the ticket. That is, run down the SRV chain fully and then use the final result as the input to the TLSA processing.

(b) [target/port of SRV is fed into TLSA processing] is the only choice that makes sense to me in the long run.

-Peter

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 9 Jan 2012 12:34:18 +0100

> I propose (b) from the ticket. That is, run down the SRV chain fully and then use the final result as the input to the TLSA processing.

+1.

Thinking about how this could actually work in a large distributed environment (think Google Apps), this is the reasonable choice. I know other drafts has chosen a different path, but that has/will lead to scalability problems (think about what happens when Google want to roll the key for aspmx.l.google.com).

Btw, this also applies to MX. IMHO,  the TLSA record is for the _server_ endpoint, not the service endpoint.

	jakob

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 9 Jan 2012 08:13:41 -0500

Neither option in the ticket is correct.  This is an application layer issue, not a DANE issue.

The client should look up the DANE record for the name it's trying to authenticate, which is defined by the application layer's needs.  For example, in the example in the ticket, the application might do TLSA to bob.com if the SRV record is signed with DNSSEC, and to alice.com if not.  (c.f., draft-ietf-xmpp-dna)

DANE simply defines an algorithm mapping (name,transport,port) tuples to certs.  We do not have to cover every case of how you get those inputs or how you decide which ones to use.  That's what application-layer protocols are for.

Suggest closing this with no action, or by adding explanatory examples of the many ways you can end up with a name/transport/port tuple.

--Richard

On Jan 9, 2012, at 6:34 AM, Jakob Schlyter wrote:

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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 9 Jan 2012 07:13:40 -0800

> Neither option in the ticket is correct.  This is an application layer issue, not a DANE issue.

DANE is run by applications.

> The client should look up the DANE record for the name it's trying to authenticate, which is defined by the application layer's needs.

Applications running TLS are not "trying to authenticate names": they are trying to bind a certificate to the name that they used to get to the TLS service.

>  For example, in the example in the ticket, the application might do TLSA to bob.com if the SRV record is signed with DNSSEC, and to alice.com if not.  (c.f., draft-ietf-xmpp-dna)

That expired draft does not seem to be coming to consensus in the XMPP WG. Discussion there a year ago indicates that some people there have the same opinions as some people here. 

> DANE simply defines an algorithm mapping (name,transport,port) tuples to certs.  We do not have to cover every case of how you get those inputs or how you decide which ones to use.  That's what app…

That's one view. Another is "well-used IETF protocols that make the algorithm mapping not straight-forward should be covered".

> Suggest closing this with no action, or by adding explanatory examples of the many ways you can end up with a name/transport/port tuple.

By the use of the plural "examples", it sounds like you want multiple, non-interoperable methods. I hope that is not what this WG wants.

--Paul Hoffman

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 9 Jan 2012 11:11:26 -0500

> DANE is run by applications.

So is TLS.  Does TLS define what names have to be in a certificate?  No, RFC 2818 does, for example, or RFC 6121.  

> That expired draft does not seem to be coming to consensus in the XMPP WG. Discussion there a year ago indicates that some people there have the same opinions as some people here. 

Nonetheless, there is a desire in the group to deal with secure delegation through SRV, which will impact which name you require a server to authenticate.   

> That's one view. Another is "well-used IETF protocols that make the algorithm mapping not straight-forward should be covered".

Another view is "That's a rat-hole I don't want to dive into." :)

> By the use of the plural "examples", it sounds like you want multiple, non-interoperable methods. I hope that is not what this WG wants.

Not that I want, but that there *exist* many ways that an application figures out which names to authenticate.  Just to pick a few examples off the top of my head:
-- HTTP uses names in URLs
-- XMPP uses SRV
-- SMTP/POP/IMAP use MX
-- LoST/HELD/possibly-ALTO use NAPTR

If this group wants to address all these cases, they'll have to consider what happens in each of these cases, including secure/insecure cases, chained delegation cases, etc.

But keep in mind that "non-interoperable" in this case *doesn't* *matter*, because you're talking about completely separate applications.  So there's no harm in not addressing the above cases, as long as any given application can figure out (interoperably) which host/transport/port it should plug into the DANE library.

I would suggest that if there is a concrete recommendation to be made here, then it's of the following character:
"
An application protocol using DANE MUST specify which names, protocols, and ports an implementation uses to locate DANE records.  Protocols that have requirements that servers authenticate particular names (independent of DANE) SHOULD use those names to locate DANE records.  For example, XMPP [RFC6121] requires that the server that is the target of an SRV record present a certificate containing the source name of the SRV.  In this case, clients should also use the source record to locate DANE records. 
"

---

From: Matt Miller <[email-masked]>
Date: Mon, 9 Jan 2012 09:16:31 -0700

> Nonetheless, there is a desire in the group to deal with secure delegation through SRV, which will impact which name you require a server to authenticate.   

I would say that draft-ietf-xmpp-dna expired not for lack of interest, but because there have been bigger issues for the XMPP WG to address.  There is still a desire (need) to handle secure delegation in XMPP.

> But keep in mind that "non-interoperable" in this case *doesn't* *matter*, because you're talking about completely separate applications.  So there's no harm in not addressing the above cases, as l…

^ This ^

> An application protocol using DANE MUST specify which names, protocols, and ports an implementation uses to locate DANE records.  Protocols that have requirements that servers authenticate particul…

I think this text addresses it best, in my opinion.

- m&m

Matt Miller - <[email-masked]>
Collaboration Software Group - Cisco Systems, Inc.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Jan 2012 09:44:25 -0700

On 1/9/12 9:16 AM, Matt Miller wrote:
>> I would suggest that if there is a concrete recommendation to be
>> made here, then it's of the following character: " An application
>> protocol using DANE MUST specify which names, protocols, and ports
>> an implementation uses to locate DANE records.  Protocols that have
>> requirements that servers authenticate particular names
>> (independent of DANE) SHOULD use those names to locate DANE
>> records.  For example, XMPP [RFC6121] requires that the server that
>> is the target of an SRV record present a certificate containing the
>> source name of the SRV.  In this case, clients should also use the
>> source record to locate DANE records. "
> 

WFM (other than s/6121/6120/).

Peter

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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 9 Jan 2012 09:39:42 -0800

> An application protocol using DANE MUST specify which names, protocols, and ports an implementation uses to locate DANE records.  Protocols that have requirements that servers authenticate particul…

The first sentence means that DANE cannot be used for any protocol. I know that's not what you mean, but this kind of sloppy wording doesn't help.

Counter-proposal with hopefully clearer words:

Clients of protocols that have requirements that servers authenticate themselves in TLS particular names MUST use those names to locate TLSA records.  For example, XMPP [RFC6120] requires that the server that is the target of an SRV record present a certificate containing the source name of the SRV; thus, SMTP clients would use the source record to locate TLSA records. If a protocol does not have a requirement for authenticating particular names, or has a requirement that includes many different names, the client MUST use the "reference identity" as defined in [RFC6125].

--Paul Hoffman

---

From: SM <[email-masked]>
Date: Mon, 09 Jan 2012 11:17:05 -0800

At 09:39 09-01-2012, Paul Hoffman wrote:
>The first sentence means that DANE cannot be used for any protocol. 
>I know that's not what you mean, but this kind of sloppy wording doesn't help.

Yes.

>Clients of protocols that have requirements that servers 
>authenticate themselves in TLS particular names MUST use those names 
>to locate TLSA records.  For example, XMPP [RFC6120] requires that 
>the server that is the target of an SRV record present a certificate 
>containing the source name of the SRV; thus, SMTP clients would use 
>the source record to locate TLSA records. If a protocol does not 
>have a requirement for authenticating particular names, or has a 
>requirement that includes many different names, the client MUST use 
>the "reference identity" as defined in [RFC6125].

It is still not that clear as the requirements have to be 
interpreted.  I suggest going for the intent the WG can agree upon 
for now and fine tune later.

Regards,
-sm

---

From: James Cloos <[email-masked]>
Date: Mon, 09 Jan 2012 15:44:07 -0500

>>>>> "PH" == Paul Hoffman <[email-masked]> writes:

PH> Counter-proposal with hopefully clearer words:

PH> thus, SMTP clients would use the source record to locate TLSA
PH> records.

Smtp should not be an example for this idea.  Smtp clients SHOULD
use the hostname associated with the A/AAAA lookup for TLSA lookups.

It may be reasonable, though, to include some text specifying that
the whole DNS chain should be verified in order to trust the TLSA RR.

Ie, given:

     example.com. IN MX mail.example.net

and:

     mail.example.net IN AAAA 2002:0A0B:0C0D::19
     _25._tcp.mail.example.net IN TLSA 1 0 1 abcdef...

then when sending mail to [email-masked] the client mta SHOULD
trust _25._tcp.mail.example.net IN TLSA only as much as it can trust
example.com IN MX.

That probably should apply equally for sip SRV lookups.

It seems, from the thread here, that rfc 6120 defines different
semantics for xmpp.

Perhaps the best choice, then, is to say that the clients should do a
tlsa lookup on the name they expect the server to specify during tls
negotiation, and that the whole dns chain from whatever the user
presents to the TLSA and A/AAAA RRs should verify.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 9 Jan 2012 13:30:33 -0800

OK, that was clearer, but not clear enough. And using a term that RFC 6125 says it is going to define but doesn't actually do so was probably a mistake. :-) It would probably be better to explain the semantics as we define the protocol. New proposal:

Add to the end of Section 1.1:
The TLSA record is used to make a certificate association between for a triple of domain name and transport protocol and port number where a TLS based service is assumed to exist. The triple is used to perform the lookup described in Section 3. The triple used for TLSA lookup may be different than what the application started with, such as if the application protocol uses SRV or MX records to find a server. Similarly, the certificate association returned in TLSA may have a domain name that is different than the domain name used in the TLSA query, depending on the application protocol's rules for TLS server identification.

Add to the Security Considerations:
The security properties of the TLSA record apply only to the triple of domain name and transport protocol and port number that was looked up. If TLSA is used with an application protocol that uses redirection to find a server (such as SMTP and XMPP), TLSA can only be used if every step of the redirection chain is protected by DNSSEC and processing stops for any step where the response is not secure.

--Paul Hoffman

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 10 Jan 2012 11:57:25 +0100

> The security properties of the TLSA record apply only to the triple of domain name and transport protocol and port number that was looked up. If TLSA is used with an application protocol that uses…

+1

	jakob

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 10 Jan 2012 16:07:58 +0100

LGTM

--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Jan 2012 07:43:23 -0800

In thinking about it more, I realized I over-stated the security problem. There is no problem for SMTP, but there is one for XMPP. The problem is that XMPP specifies that the identity in the TLS server's certificate must be that of the *beginning* of the chain, not of the server itself. This allows XMPP to have insecure redirections through SRV; as along as the client ends up at the correct server, even insecurely, TLS will bind the server to the original identity. SMTP (and probably other protocols) don't try to make this binding.

> The security properties of the TLSA record apply only to the triple of domain name and transport protocol and port number that was looked up. If TLSA is used with an application protocol that uses…

More accurate wording for the last sentence would be:

If TLSA is used with an application protocol such as XMPP that uses redirection to find a server and requires that the TLS server's identity match a host earlier in the redirection chain, TLSA can only be used if every step of the redirection chain is protected by DNSSEC and processing stops for any step where the response is not secure.

--Paul Hoffman

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 10 Jan 2012 11:09:45 -0500

> In thinking about it more, I realized I over-stated the security problem. There is no problem for SMTP, but there is one for XMPP. The problem is that XMPP specifies that the identity in the TLS se…

Of course, if this were true, it would leave SMTP open to poisoning attacks against MX records.  But SMTP actually does do the same thing as XMPP, just not normatively.

XMPP [RFC6120]
"
   The identities to be checked are set as follows:

   o  The initiating entity sets the source domain of its reference
      identifiers to the 'to' address it communicates in the initial
      stream header; i.e., this is the identity it expects the receiving
      entity to provide in a PKIX certificate.
"

SMTP [RFC3207]
"
   The decision of whether or not to believe the authenticity of the
   other party in a TLS negotiation is a local matter.  However, some
   general rules for the decisions are:

   -  A SMTP client would probably only want to authenticate an SMTP
      server whose server certificate has a domain name that is the
      domain name that the client thought it was connecting to.
"

>> The TLSA record is used to make a certificate association between for a triple of domain name and transport protocol and port number where a TLS based service is assumed to exist. The triple is us…

Editorial: An association needs to be between two things.  And it's bad to assume, especially in protocol design :)
"
The TLSA record is used to make an association between a certificate and a (domain name, transport protocol, port number) triple where a TLS service may exist.
"

> If TLSA is used with an application protocol such as XMPP that uses redirection to find a server and requires that the TLS server's identity match a host earlier in the redirection chain, TLSA can…

This seems like it would make deployability much harder than just saying "use the name you're looking for".  Wouldn't the same considerations apply to, say, CNAME?  And that applies regardless of the protocol.  So you're left only allowing DANE in a perfect world of universal DNSSEC.

By contrast, each implementation knows what name(s) it's trying to authenticate because it's going strcmp() to the names in the certificate (since current security mechanisms are based on name matching).  Just let it use those name(s) for finding TLSA.  That's all my proposed text did.

Revised proposed text follows, based on the above.  Seems like it should go in Section 3, actually.
"
The TLSA record is used to make an association between a certificate and a (domain name, transport protocol, port number) triple where a TLS service may exist.  

Applications using DANE need to choose carefully which domain names they use to locate TLSA records, since these domains are trusted to provide certificate association information; obtaining TLSA information from the wrong source can lead to clients accepting bogus certificates.  Applications that are seeking to authenticate a specific domain name MUST use that name to locate DANE records.  For example: 
   o An HTTPS client connecting to an HTTP URI would use the name in the URI [RFC2818]
   o An SMTP client connecting to an SMTP server would use the name for the mail domain is is seeking to reach (i.e., the domain used to locate the MX record) [RFC3207]
   o An XMPP server connecting to another XMPP server would use the 'to' address in the initial stream header [RFC6120]

This requirement holds even if the ultimate service is redirected to another domain, for example, via CNAME, MX, SRV, or NAPTR records.  Applications MAY also locate DANE records using the target names of these redirection records, if and only if the redirection records are protected by DNSSEC.  If a chain of redirections exists, then all records in the chain MUST be DNSSEC-protected.  
"

--Richard

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 10 Jan 2012 19:42:46 +0100

>      domain name that the client thought it was connecting to.

"the domain name that the client thought it was connecting to" could be interpreted as the domain name found at the right hand side of the MX record. For SMTP as deployed today, this makes sense - e.g., MX for kirei.se points to mail.kirei.se, and the TLS cert is CN=mail.kirei.se (not CN=kirei.se or the like).

	jakob

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Jan 2012 10:55:07 -0800

Personally, I would like this WG to not to re-open the entire discussion that led to RFC 6120, including all of the special cases and different security assumptions and so on. The resulting RFC is dense, confusing in many places, and much less helpful than any of us expected when the document started. It was a useful discussion, but mostly to show that what is "obvious" about host identity to one person is completely wrong to another.

Richard: you have a set of views that seems driven by the model that XMPP chose. That's great, and I think my current wording completely covers the XMPP case and does not penalize XMPP at all. You also have a view about how HTTP and SMTP and ... "should" do it, but your view is not universally shared; as far as I can tell, no one's is.

To me, it is inappropriate to use DANE as a wedge to enforce a particular view of server identity on any application protocol and to say "unless you change your protocol, you can't use DANE". If the protocol developers have not been moved to make changes by the publication of RFC 6120 (and I believe they have not), trying to exert pressure via DANE (which is supposed to be useful) is wrong.

--Paul Hoffman

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 10 Jan 2012 12:00:15 -0700

On 1/10/12 11:55 AM, Paul Hoffman wrote:
> Personally, I would like this WG to not to re-open the entire
> discussion that led to RFC 6120, 

I think you mean RFC 6125. 6120 is the core XMPP spec. 6125 is the
"certid" spec.

> including all of the special cases
> and different security assumptions and so on. The resulting RFC is
> dense, confusing in many places, and much less helpful than any of us
> expected when the document started. It was a useful discussion, but
> mostly to show that what is "obvious" about host identity to one
> person is completely wrong to another.

Which is why RFC 6125 ended up being so long. What seems simple isn't
always so.

Peter

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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Jan 2012 11:26:22 -0800

> I think you mean RFC 6125. 6120 is the core XMPP spec. 6125 is the

Completely correct, yes. We need more diffuse RFC numbers. :-)

> Which is why RFC 6125 ended up being so long. What seems simple isn't

In this specific case, RFC 6125 shows both that the topic is not simple *and* that different application protocol developers want to handle things differently.

--Paul Hoffman

---

From: James Cloos <[email-masked]>
Date: Tue, 10 Jan 2012 15:56:03 -0500

>>>>> "JS" == Jakob Schlyter <[email-masked]> writes:

JS> "the domain name that the client thought it was connecting to" could
JS> be interpreted as the domain name found at the right hand side of the
JS> MX record. For SMTP as deployed today, this makes sense - e.g., MX for
JS> kirei.se points to mail.kirei.se, and the TLS cert is CN=mail.kirei.se
JS> (not CN=kirei.se or the like).

Exactly.  And frequently the MX (legitimately) points to a hostname in
an entirely different domain.  In fact, that may be more common than not.

For smtp, the tlsa MUST to be /after/ the MX lookup.

-JimC

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Jan 2012 16:39:47 -0500

+1

What I think is appropriate is to state where DANE appears in the chain and
I think that as currently specified it very obviously binds to a host and
not to a service.

If someone wanted to use DANE RR to secure an Internet service the prefix
should be something like '_http._tcp.'

_http._tcp.example.com

We definitely need to have a mechanism to allow applications to resolve
Internet services instead of the host and port scheme. But that does not
mean that hosts and ports should go away any more than DNS made IP
addresses obsolete.

Whatever service mechanism is eventually decided will eventually resolve to
host and port and then IP address and port number which will ultimately be
resolved into a sequence of router destination ports.

This should not be a choice left to the application, it should be a
specified part of the Internet architecture. But the DANE group is
definitely not the place to design that mechanism and nor is DNSEXT.

On Tue, Jan 10, 2012 at 1:55 PM, Paul Hoffman <[email-masked]> wrote:

> Personally, I would like this WG to not to re-open the entire discussion
> that led to RFC 6120, including all of the special cases and different
> security assumptions and so on. The resulting RFC is dense, confusing in
> many places, and much less helpful than any of us expected when the
> document started. It was a useful discussion, but mostly to show that what
> is "obvious" about host identity to one person is completely wrong to
> another.
>
> Richard: you have a set of views that seems driven by the model that XMPP
> chose. That's great, and I think my current wording completely covers the
> XMPP case and does not penalize XMPP at all. You also have a view about how
> HTTP and SMTP and ... "should" do it, but your view is not universally
> shared; as far as I can tell, no one's is.
>
> To me, it is inappropriate to use DANE as a wedge to enforce a particular
> view of server identity on any application protocol and to say "unless you
> change your protocol, you can't use DANE". If the protocol developers have
> not been moved to make changes by the publication of RFC 6120 (and I
> believe they have not), trying to exert pressure via DANE (which is
> supposed to be useful) is wrong.
>
> --Paul Hoffman
>

-- 
Website: http://hallambaker.com/

---

From: Martin Rex <[email-masked]>
Date: Wed, 11 Jan 2012 02:31:01 +0100 (MET)

Paul Hoffman wrote:
> 
> There is no problem for SMTP, but there is one for XMPP.
>
> The problem is that XMPP specifies that the identity in the TLS
> server's certificate must be that of the *beginning* of the chain,
> not of the server itself.

You got this backwards.

SMTP server-to-server authentication security is fubar (beyond repair),
whereas the XMPP scheme described in rfc6125, to require the server to
present a certificate for the domain it is *SERVING*, rather than for
the hostname of the server where the service is running on
is the sensible and secure approach.

>
> This allows XMPP to have insecure redirections through SRV; as along as
> the client ends up at the correct server, even insecurely, TLS will bind
> the server to the original identity.

Correct.  The insecurity of the DNS SRV lookup is supposed to not impair
the authentication of the XMPP *service* to the user.  Authenticating
the particular server hostname on which the admin has installed a particular
instance of a service is a bad idea in absence of a secure directory
or secure naming service.

>
> SMTP (and probably other protocols) don't try to make this binding.

SMTP-AUTH between servers is de-facto an optional optimistic anonymous
encryption.

> If TLSA is used with an application protocol such as XMPP that uses
> redirection to find a server and requires that the TLS server's identity
> match a host earlier in the redirection chain, TLSA can only be used
> if every step of the redirection chain is protected by DNSSEC and
> processing stops for any step where the response is not secure.

Again, this is backwards.

XMPP redirection is safe with insecure SRV records.

SMTP-AUTH with MX redirection is always insecure and defining the
additional DNSSEC validations that would have to be performed
to make those MX indirections trustworthy is non-trivial.

Reason why server-to-server SMTP-AUTH is a security disaster:

 - necessity to fallback to SMTP without TLS for millions of domains

 - unavailability of STARTTLS for many large (Fre)email providers
   (@hotmail.com, @live.com, @gmx.de, @web.de)

 - use of TLS server certs with hostnames that are completely
   unrelated to the actual mail domain that is serviced
   (e.g.  @gmail.com:  gmail.com  IN MX 5   gmail-smtp-in.l.google.com)

The lack of support for virtual hosting in the base SSLv3 and TLS protocol
is probably one of the reasons why SMTP-AUTH got it wrong and why so
few sites on the internet are configured for HTTPS access.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Jan 2012 17:48:17 -0800

> XMPP redirection is safe with insecure SRV records.

...in the current XMPP model. Note that the sentence above starts "If TLSA is used with...". XMPP assumes a certificate that chains to a trust anchor who will do the identification. TLSA breaks that model: the DANE certificate association might be to a type 2 certificate, which would open an attack on XMPP if the redirection chain is not fully protected. Agree?

--Paul Hoffman

---

From: Richard L. Barnes <[email-masked]>
Date: Tue, 10 Jan 2012 21:44:26 -0500

After talking with Paul offline, I've come to realize that where we differ is basically with regard to how we regard the risk of DNS spoofing.  

The state of the art in SMTP and HTTP seems to be to follow CNAMEs and MXs and allow matching against the target domains, which makes deployment simpler, but leaves clients vulnerable to DNS poisoning against those records.  If a DANE client follows this pattern (looking up records based on target), it doesn't face any *new* risks, but the old spoofing risk persists.

The state of the art in XMPP is to regard SRVs as untrustworthy and require matching against the source domains, which makes deployment more challenging but protects against DNS poisoning.  If a DANE client follows this pattern (looking up records based on source or DNSSEC-protected target), then it has no spoofing risk.

All of which brings me back to my original point -- let the application decide.  HTTP and SMTP entities can use the target name for TLSA/matching, and XMPP entities can use the source name.  Let each application use the name it's trying to authenticate   My latest suggested text actually says pretty much that, except for the last paragraph, which I'm willing to compromise on in light of the above. 

Revised proposed text, with the MUSTs softened to SHOULD/RECOMMENDED and the second paragraph changed to be more of a cautionary note:
"
A TLSA record is used to make an association between a certificate and a (domain name, transport protocol, port number) triple where a TLS service may exist.  

Applications using TLSA need to choose carefully which domain names they use to locate TLSA records, since these domains are trusted to provide certificate association information; obtaining TLSA information from the wrong source can lead to clients accepting bogus certificates.  Applications that are seeking to authenticate a specific domain name SHOULD use that name to locate TLSA records.  For example: 
  o An HTTPS client connecting to an HTTP URI would use the name in the URI [RFC2818]
  o An SMTP client connecting to an SMTP server would use the name for the mail domain it is seeking to reach [RFC3207]
  o An XMPP server connecting to another XMPP server would use the 'to' address in the initial stream header [RFC6120]

In some cases, the name that an application seeks to authenticate is obtained by the client via a chain of DNS redirection records (e.g., MX, SRV, NAPTR).  When this is the case, it should be noted that if these redirection records are not protected with DNSSEC, then face the risk that a spoofed redirection record will cause them to accept bogus certificates.  Thus, if applications encounter redirection chains in which one or more records are not DNSSEC-protected, then it is RECOMMENDED that the application locate TLSA records only using the source domain or target domains of DNSSEC-protected records. 
"

---

From: Martin Rex <[email-masked]>
Date: Wed, 11 Jan 2012 03:50:41 +0100 (MET)

Paul Hoffman wrote:
> ...in the current XMPP model. Note that the sentence above starts
> "If TLSA is used with...". XMPP assumes a certificate that chains
> to a trust anchor who will do the identification.
> TLSA breaks that model: the DANE certificate association might be
> to a type 2 certificate, which would open an attack on XMPP if the
> redirection chain is not fully protected. Agree?

No, I believe the type (0,1,2) does not matter here.

What we need to authenticate is the "Service" rather than the
"Server Hostname" (where that service happens to run on at the moment).

For use with SRV records, we might have to make the TLSA record match
the left part of the SRV record (with the symbolic service name),
rather than the right part (with the numeric port number), in order
to provide a secure association for service names through DANE(TLSA)
for services/protocols that use DNS SRV to locate where exactly
(XMPP) service instances can be reached.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 11 Jan 2012 04:29:59 +0100 (MET)

Your message looks inconsistent to me.

Richard L.Barnes wrote:
> 
> The state of the art in SMTP and HTTP seems to be to follow CNAMEs
> and MXs and allow matching against the target domains, which makes
> deployment simpler, but leaves clients vulnerable to DNS poisoning
> against those records.

Correct and fairly useless practice in SMTP-AUTH (about MX)

Incorrect for HTTP(S) (about CNAME).

>   o An HTTPS client connecting to an HTTP URI would use the name

Correct for HTTP(S).

Example:

 ;; QUESTION SECTION:
 ;www.google.com.			IN	A
 
 ;; ANSWER SECTION:
 www.google.com.		604800	IN	CNAME	www.l.google.com.
 www.l.google.com.	300	IN	A	173.194.69.103
 www.l.google.com.	300	IN	A	173.194.69.99
 www.l.google.com.	300	IN	A	173.194.69.147
 www.l.google.com.	300	IN	A	173.194.69.105
 www.l.google.com.	300	IN	A	173.194.69.104
 www.l.google.com.	300	IN	A	173.194.69.106

Traditional HTTP(S) clients will be matching the URL "http://www.google.com"
to the Server certificate containing "www.google.com", and ignore
(and maybe not even notice) the CNAME indirection within DNS:
www.google.com --> www.l.google.com

-Martin

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 11 Jan 2012 07:52:52 +0100

> The state of the art in SMTP and HTTP seems to be to follow CNAMEs and MXs and allow matching against the target domains, which makes deployment simpler, but leaves clients vulnerable to DNS poison…

I suggest we remove the CNAME example, since (as Martin Rex pointed out) is wrong.

>  o An HTTPS client connecting to an HTTP URI would use the name in the URI [RFC2818]

This, on the other hand, is true (as it does not mention CNAME).

>  o An SMTP client connecting to an SMTP server would use the name for the mail domain it is seeking to reach [RFC3207]

Writing "An SMTP client connecting to an SMTP server would use the domain name for the SMTP server it is seeking to reach [RFC3207]" would be better IMHO.

	jakob

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 11 Jan 2012 07:52:54 +0100

On 10 jan 2012, at 22:39, Phillip Hallam-Baker wrote:

> What I think is appropriate is to state where DANE appears in the chain and I think that as currently specified it very obviously binds to a host and not to a service.

Actually, because the TLSA record appears together with a port number and transport using it with a service name would never make sense, as part of the TLSA domain name (port/transport) is found via a mapping function such as SRV/NAPTR.

If one would argue for looking up a service name using TLSA, one has to first look up possible ports/transports using SRV/NAPTR, then combine these host specific attributes with the service name. The TLSA domain name to look up would be a strange mess between service properties (the name) and server properties (port/transport).

> If someone wanted to use DANE RR to secure an Internet service the prefix should be something like '_http._tcp.'
> 
> _http._tcp.example.com

Yes, and looking up TLSA using a service would be another draft.

	jakob

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 11 Jan 2012 09:03:37 +0100

> In some cases, the name that an application seeks to authenticate is obtained by the client via a chain of DNS redirection records (e.g., MX, SRV, NAPTR).  When this is the case, it should be noted…

In SIP, there's an RFC on how to match a certificate with a SIP URI. 
http://tools.ietf.org/html/rfc5922

Basically we match the target SIP uri domain with 
a) the subject ALT NAMEs
b) if no subject alt names exist, the subject

We do not match the SRV records name with the certificate.

Just FYI. 
/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 11 Jan 2012 09:10:09 +0100

> We do not match the SRV records name with the certificate.

To comment my own posting :-)

The RFC adds a preference for matching SA URI records, not host names.

/O

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 11 Jan 2012 09:56:45 -0500

> In some cases, the name that an application seeks to authenticate is obtained by the client via a chain of DNS redirection records (e.g., MX, SRV, NAPTR).  When this is the case, it should be noted…

Richard,
My first reaction in reading you posts was that you are off the
deep end.
After going through the latest draft and your suggested text I think you 
have exposed an underspecification in the draft that needs to
be addressed.
Your text does not address the underlying problem.

Using the example in the tix:
http://trac.tools.ietf.org/wg/dane/trac/ticket/28

In case a)
  _port._tcp._jabber._tcp.jabber.alice.com IN TLSA <blob>
	 the zone with the SRV record and TLSA is MUST be signed thus
          no spoofing possible, if the DNS tree and record validate.

In case b)
  _xmpp-client._tcp.jabber.alice.com IN SRV 5 0 5222 jabber.bob.com.

The target zone (bob.com) MUST be signed or the DANE client will
NOT accept the TLSA record from it.
The question is is the zone with the SRV/URI/???
record (alice.com) signed, the current draft is silent on that.

Case c) is from DNS consistency point is the same as a).

In reading the document it DOES NOT say that records used to navigate to 
the TLSA RRset MUST also be validated.
This causes inconsistency as depending on the DNS traversal to the
TLSA record.

If the traversal is via NS/CNAME/DNAME records the TLSA RRset will
only be marked as validated if all links in the navigation
chain validate.

In the case of MX/SRV/NAPTR records there are multiple queries involved,
and naive TLSA implementation may say "I got validated TLSA that is
good enough for me", opening up the spoofing hole that Richard worries 
about.

My proposal is to add text that explicitly covers records in the DNS 
traversal and specify that any record that "points" to the TLSA RRset 
MUST also be validated.

    Olafur

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 16 Jan 2012 10:44:20 +0100

On Tue, Jan 10, 2012 at 07:42:46PM +0100,
 Jakob Schlyter <[email-masked]> wrote 
 a message of 20 lines which said:

> "the domain name that the client thought it was connecting to" could
> be interpreted as the domain name found at the right hand side of
> the MX record. For SMTP as deployed today, this makes sense - e.g.,
> MX for kirei.se points to mail.kirei.se, and the TLS cert is
> CN=mail.kirei.se (not CN=kirei.se or the like).

Today, almost no MTA tries to authenticate the peer is connects to. If
they were to start doing it, we would quickly discover that:

1) Noone really understands the host/service matching rule of X.509
for SMTP. (And RFC 6125 does not help.)

2) They are not implemented properly.

So, I'm afraid we have very little practical experience about
validation of names in SMTP-over-TLS.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 16 Jan 2012 14:57:18 -0500

> After going through the latest draft and your suggested text I think you have exposed an underspecification in the draft that needs to
> be addressed.
> In reading the document it DOES NOT say that records used to navigate to the TLSA RRset MUST also be validated.
> good enough for me", opening up the spoofing hole that Richard worries about.
> 
> My proposal is to add text that explicitly covers records in the DNS traversal and specify that any record that "points" to the TLSA RRset MUST also be validated.
> 
>   Olafur

Hey Olafur,

It actually sounds to me like we're more or less on the same page.  I think the distinction that's missing here is between application-layer redirection, which finds the right name for a service, and DNS-layer redirection, which finds the records for a name.  The discussion above applies to application-layer redirection, with which I wrongly included CNAME earlier in the discussion.  If I were to summarize your recommendations above:

1. Application-layer redirection records (MX/SRV/NAPTR/URI/etc) used to determine the name of a service MAY be DNSSEC-protected.  If they are not, then the client SHOULD use the source name (before redirection); otherwise it faces spoofing risks.
2. DNS-layer redirection records (NS/CNAME/DNAME) encountered in the process of a TLSA query MUST all have DNSSEC state "secure".

With that in mind, revised proposed text:
"
A TLSA record is used to make an association between a certificate and a (domain name, transport protocol, port number) triple where a TLS service may exist.  The resolution of TLSA records under a particular domain name MUST be secured with DNSSEC at all steps, including any DNS-layer redirection records, such as NS, CNAME, or DNAME records.

In some cases, the name that an application seeks to authenticate is obtained by the client via a chain of redirection records (e.g., MX, SRV, NAPTR).  When this is the case, it should be noted that if these redirection records are not protected with DNSSEC, then face the risk that a spoofed redirection record will cause them to accept bogus certificates.  Thus, if applications encounter redirection chains in which one or more records are not DNSSEC-protected, then it is RECOMMENDED that the application locate TLSA records using only (1) the source domain of any redirection, or (2) target domains of DNSSEC-protected redirection records.
"

---

From: Lawrence Conroy <[email-masked]>
Date: Mon, 16 Jan 2012 20:28:43 +0000

On 16 Jan 2012, at 19:57, Richard L. Barnes wrote:
...
> In some cases, the name that an application seeks to authenticate is obtained by the client via a chain of redirection records (e.g., MX, SRV, NAPTR).  When this is the case, it should be noted tha…

To which I reply:
Hi Richard, folks,
Your proposed text seems OK-ish (to this tyro), but ...
The sentence starting "When this is the case " is long and nested, so might do with a slight re-structure or breaking out the nesting?
Also, it's missing a word or two, IMHO, after "then" -- maybe use "then clients face"?

BTW, perhaps mention SIP in the list of applications above this paragraph (RFC3263 uses both NAPTR and SRV so it's germane to your point).
Finally, shouldn't the XMPP example say "the domain of the 'to' address"?

all the best,
 Lawrence

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 16 Jan 2012 15:55:16 -0500

Hey Lawrence,

Thanks for the feedback.

> Also, it's missing a word or two, IMHO, after "then" -- maybe use "then clients face"?

Good point, thanks.  Revised below.

> BTW, perhaps mention SIP in the list of applications above this paragraph (RFC3263 uses both NAPTR and SRV so it's germane to your point).

Could do.  Do you have a good reference to text in 3261/3263 that says what name to look for in a SIPS handshake?

> Finally, shouldn't the XMPP example say "the domain of the 'to' address"?

I was actually just quoting RFC 6120:
"
   o  The initiating entity sets the source domain of its reference
      identifiers to the 'to' address it communicates in the initial
      stream header; i.e., this is the identity it expects the receiving
      entity to provide in a PKIX certificate.
"
<http://tools.ietf.org/html/rfc6120#section-13.7.2.1>

But now that you mention it, that text only covers one half of the mutual authentication.  Revised below.

Revised suggested text:
"

Applications using TLSA need to choose carefully which domain names they use to locate TLSA records, since these domains are trusted to provide certificate association information; obtaining TLSA information from the wrong source can lead to clients accepting bogus certificates.  Applications that are seeking to authenticate a specific domain name SHOULD use that name to locate TLSA records.  For example: 
o An HTTPS client connecting to an HTTP URI would use the name in the URI [RFC2818]
o An SMTP client connecting to an SMTP server would use the name for the mail domain it is seeking to reach [RFC3207]
o An XMPP server initiating a connection to another XMPP server would use the 'to' address in the initial stream header [RFC6120]

In some cases, the name that an application seeks to authenticate is obtained by the client via a chain of redirection records (e.g., MX, SRV, NAPTR).  If a client accepts redirection records that are not protected with DNSSEC, then it faces the risk that a spoofed redirection record will cause it to accept bogus certificates.  Thus, if a client encounters a redirection chain in which one or more records are not DNSSEC-protected, then it is RECOMMENDED that the application locate TLSA records using only (1) the source domain of the redirection chain, or (2) target domains connected to the source entirely by DNSSEC-protected records.
"

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 16 Jan 2012 13:12:16 -0800

Not that I want you to make your convoluted wording even more complicated, but it is still unclear.

> A TLSA record is used to make an association between a certificate and a (domain name, transport protocol, port number) triple where a TLS service may exist.  The resolution of TLSA records under a…

What the heck does the second sentence mean? Why are NS records considered "DNS-layer redirection records"? How does an application know whether a DNAME record was used in resolution?

I propose that you are well down the rabbit hole. The earlier text I proposed covers exactly what the first sentence above says it should.

--Paul Hoffman

---

From: Lawrence Conroy <[email-masked]>
Date: Mon, 16 Jan 2012 21:24:52 +0000

Hi there Paul, folks,
unless you're addressing the never-ending topic of DNS API (outside DNSEXT), where did Application come from?
To an outsider, Richard's text says that resolution of TLSA records must handle DNAME/CNAME and so on. The application may not know that, depending on the API, but something sure should. One might argue that this is stating the bleedin' obvious, but it might be useful to spell it out -- implementers may not think this through.
As for NS being redirections, well ... you can host parent and child domains on the same server set, if you like a whole world of obscure pain. Otherwise, the zone cut does reflect a real cut, with potential for further queries -- purely within DNS level processing. The application won't see that, but I don't think Richard's text doesn't say that. Does it?

all the best,
 Lawrence

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 16 Jan 2012 13:51:46 -0800

> unless you're addressing the never-ending topic of DNS API (outside DNSEXT), where did Application come from?

The document talks about how applications make certificate associations. Issue #28 is specifically about application protocols that require an application to go through at least one round trip in the DNS to get the name of the host they want to contact.

> To an outsider, Richard's text says that resolution of TLSA records must handle DNAME/CNAME and so on. The application may not know that, depending on the API, but something sure should. One might…

I was, in fact, asking Richard to spell it out. My purpose is to show how far down the rabbit hole he has gone with his proposal.

> As for NS being redirections, well ... you can host parent and child domains on the same server set, if you like a whole world of obscure pain. Otherwise, the zone cut does reflect a real cut, with…

Richard's most recent proposal equates NS records with CNAME and DNAME records, calling them all "DNS-layer redirection". Many of us would find that equating difficult to understand. I suspect he was just being sloppy and didn't really mean it, but I want to be sure.

--Paul Hoffman

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 16 Jan 2012 17:10:22 -0500

Richard
we are close but there nits we do not agree on.
see in-line below.

On 16/01/2012 14:57, Richard L. Barnes wrote:
>> _port._tcp._jabber._tcp.jabber.alice.com IN TLSA<blob>
s/MAY/MUST/
If the source name is not DNSSEC protected why follow application-layer 
redirection records that can be spoofed?

> 2. DNS-layer redirection records (NS/CNAME/DNAME) encountered in the process of a TLSA query MUST all have DNSSEC state "secure".

There is only one case: All records used to navigate to the TLSA record 
MUST be validated as well as the TLSA record.

	Olafur

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 16 Jan 2012 17:21:57 -0500

> If the source name is not DNSSEC protected why follow application-layer redirection records that can be spoofed?

Well, the source name is the name *before* you go to the DNS.  So the idea of a "DNSSEC-protected source name" doesn't really parse.  For example, suppose you get  the following SRV without DNSSEC:

_foo._tcp.alice.com SRV foo.bob.com 1234

The source is "alice.com" or "_foo._tcp.alice.com" and the target is "foo.bob.com".  If you're going to look up TLSA under alice.com (with DNSSEC on NS, CNAME, etc.), then there's no risk.  OTOH, if you look up TLSA under foo.bob.com (even with DNSSEC), then you could be screwed by a spoofed SRV.

> There is only one case: All records used to navigate to the TLSA record MUST be validated as well as the TLSA record.

That's basically what I'm saying -- if you get something non-DNSSEC, ignore it and only use what you found securely.  The difference between this and Paul's proposed text is that Paul doesn't even allow you to use what you got securely; he would terminate processing entirely if anything non-secure was found.

--Richard

---

From: James Cloos <[email-masked]>
Date: Mon, 16 Jan 2012 17:25:53 -0500

>>>>> "RLB" == Richard L Barnes <[email-masked]> writes:

RLB>  o An SMTP client connecting to an SMTP server would use the
RLB>    name for the mail domain it is seeking to reach [RFC3207]

That is still wrong.  An MX should not have to have certs -- or
alternate names in one cert -- for every domain for hostname for
which it accepts incoming mail.  The overhead is excessive and
unworkable.  Not to mention that there is, in general, no "tcp
port 25" associated with the right-hand-side of the email address.

The TLSA lookup MUST be on the result of the MX lookup.  It
simply cannot be done any other way.

The client should note whether the MX lookup is verified secure
(including the case where there is no MX RR) and take that into
consideration when determining the security of the email delivery.

Given an email address such as [email-masked], a TLSA-like lookup
for, say, _smtp._tcp.example.org. MIGHT be an acceptable, additional
check.  But if done the client should not expect the cert to include
example.org in its CN or alternate name unless example.org. MX pointed
to a server w/in example.org.

We should not try to make things work worse than they do now.

It is perfectly reasonable and secure for an MX with one name to accept
mail for several seemingly unrelated domains and sub-domains.  A secure
MX lookup combined with secure TLSA and A/AAAA lookups and a matching
TLS certificate *is* sufficiently secure.

MTAs probably SHOULD keep note of secure destinations and complain when
that security is lost.  But expecting MXs to certify every zone for
which they accept incoming mail will not work.

-JimC

---

From: Martin Rex <[email-masked]>
Date: Tue, 17 Jan 2012 00:16:45 +0100 (MET)

> simply cannot be done any other way.

I'm just the opposite.

The TLSA lookup MUST be on the SOURCE (=EMail domain), doing it any
other way is going to be a real security problem.

When the SMTP client intends to deliver EMail to [email-masked]
then checking whether the server someserver.evilattacker.tv has a
server certificate for someserver.evilattacker.tv is a pretty
useless check, and entirely unrelated to the original problem
"which transport agent to trust for an EMail to @niceguy.tv"

then there are two conceivable reasonable checks:

   a) traditional PKIX-style: check whether the server determined
      by A/MX lookups has been officially authorized to serve/receive
      EMail for @niceguy.tv

   b) DANE-style:  check whether a _smtp._tcp.niceguy.tv TLSA record
      exits that authorizes the certificate presented by the server
      as authorized to serve/receive EMail for @niceguy.tv

There is another unrelated problem:  (Local) Smart Mail Relays.
The server endpoint identification of Smart Mail Relays
is an entirely different story, because it is independent
from the EMail address of the target recipient, and the configuration
parameter that is used to name the smart relay needs to be extended with
a parameter that can be used to match the certificate of the
Smart Mail Relay.

> We should not try to make things work worse than they do now.

The current scheme for mta->mta SMTP-AUTH is a complete lack of
authentication.  That part can not get any worse.

-Martin

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 16 Jan 2012 18:28:37 -0500

> port 25" associated with the right-hand-side of the email address.

The above quote is almost direct from RFC 3207, so if there's brokenness, look there.  

> simply cannot be done any other way.

You can do that, but if there's not DNSSEC on the MX, then you're vulnerable to spoofing on the MX.  Just sayin'.

--Richard

---

From: James Cloos <[email-masked]>
Date: Mon, 16 Jan 2012 19:00:32 -0500

>>>>> "MR" == Martin Rex <[email-masked]> writes:

MR> The TLSA lookup MUST be on the SOURCE (=EMail domain), doing it any
MR> other way is going to be a real security problem.

As I wrote, that will not work in practice.

Secure delivery from MTA to MTA does require that all of the DNS lookups
are secure.  If the MX lookup is verified (if there is no MX for the
given right-hand-side, a verified does-not-exist result will do) secure,
and the TLSA and A/AAAA lookups on the result of the MX lookup are also
verified secure, and the TLS cert matches the TLSA RR, and the TLS crypto
is done right, then that MTA->MTA delivery is full-path secure.

Every step is secure and verified; therefore that step of delivery is
secure and verified.

Putting the TLSA lookup before the MX lookup does not add any security.

One may even argue that it harms security, since it allows an attacker
to get the full list of target email domains from an MTA simply by
asking the MTA for its cert.  I don't know whether I'd make the argument
that that might harm security, but one could and I'm sure that some will.

The zone matching the r-h-s needs to be protected by dnssec either way,
as must the zone containing the result of the MX lookup.

The TLSA RR is keyed to a port number, not a service name.

[I need to leave for food; I'll send this now rather than come back to it after.]

-JimC

---

From: James Cloos <[email-masked]>
Date: Mon, 16 Jan 2012 19:02:58 -0500

>>>>> "RLB" == Richard L Barnes <[email-masked]> writes:

RLB> You can do that, but if there's not DNSSEC on the MX, then you're
RLB> vulnerable to spoofing on the MX.  Just sayin'.

If there is no dnssec on the MX, there also would be no dnssec on any
tlsa-like lookup on email address and the whole thing is insecure anyway.

-JimC

---

From: Martin Rex <[email-masked]>
Date: Tue, 17 Jan 2012 01:32:42 +0100 (MET)

James Cloos wrote:
>Martin Rex wrote:
> are secure.

That is a non-starter.  We really need to make SMTP authentication
work long before we get 100% DNSSEC coverage (which may never happen).

HTTP(S) has no dependency on DNSSEC and XMPP has no depedency on DNSSEC,
they can both work with PKIX alone.  The SMTP authentication should be
fixed independently of DNSSEC.

> The TLSA RR is keyed to a port number, not a service name.

Yes, but only if there is no DNS-based service indirection.

I would strongly recommend to use symbolic service names for TLSA lookup
whenever service discovery is being used (MX for SMTP, SRV for XMPP).
MX is a kind of subset of SRV because it can not change the tcp port (25).

And since XMPP uses SRV already, I would really appreciate when the 
use of a symbolic service name for TLSA lookups would be defined/standardized
in the current protocol document (for SRV and MX).

-Martin

---

From: Tony Finch <[email-masked]>
Date: Tue, 17 Jan 2012 00:35:06 +0000

> The above quote is almost direct from RFC 3207, so if there's

I think the text you are referring to is:

RFC 3207 does not make a clear distinction between host name and mail
domain, nor between mx owner and mx target.

The consensus (arising from several discussions on this topic over the
years) is that SMTP server authentication should be based on the server
host name (i.e. MX target) rather than the mail domain.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South Utsire: Mainly southwesterly 3 or 4. Slight or moderate. Fair. Good.

---

From: Tony Finch <[email-masked]>
Date: Tue, 17 Jan 2012 00:36:39 +0000

> work long before we get 100% DNSSEC coverage (which may never happen).

This isn't the right working group for that discussion.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty, Forth: Southwest 4 or 5, occasionally 6, backing south 6 or
7 later. Slight or moderate. Fair. Moderate or good.

---

From: Martin Rex <[email-masked]>
Date: Tue, 17 Jan 2012 01:49:52 +0100 (MET)

> domain, nor between mx owner and mx target.

"domain name" in that 3207 text very clearly refers to the EMail address,
because it is described as a tail match.

If it was meant to be a server name match, that match would be an
exact match (rfc2818 3.1 server endpoint identification) plus there
would be a requirement for DNSSEC on the MX lookup.

> host name (i.e. MX target) rather than the mail domain.

That is completely bogus and needs to be discontinued.

-Martin

---

From: Mark Andrews <[email-masked]>
Date: Tue, 17 Jan 2012 13:42:11 +1100

In message <[email-masked]>, Martin Rex writes
> would be a requirement for DNSSEC on the MX lookup.

No.  It is because MX records are out-of-scope for RFC3207.  RFC3207
describes what happens *after* a connection has been made not before.

If I have a MX record that says "connect to mail.server.example.net"
and I lookup the addresses for mail.server.example.net then I expect
to connect to mail.server.example.net.

If I have a client is configured to forward all mail to another
server as is done with smart host configurations or submission the
server you need to verify is the smart host / submission server not
the target of a MX record nor the RHS of the email address.

This logic goes all the way back to RFC 821.

   3.5.  OPENING AND CLOSING

      At the time the transmission channel is opened there is an
      exchange to ensure that the hosts are communicating with the hosts
      they think they are.

Mark

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

---

From: Martin Rex <[email-masked]>
Date: Tue, 17 Jan 2012 04:00:09 +0100 (MET)

Mark Andrews wrote:
> Martin Rex writes:

If MX-records are out-of-scope, then there is only the EMail address
left for which the above text suggests a tail match.

> to connect to mail.server.example.net.

This is clearly bogus if you want security, rather than only
sprinkling magic encryption pixie dust on the connection.

> the target of a MX record nor the RHS of the email address.

As I wrote in a previous EMail, the local(!) configuration that provides
the hostname of the smart relay will have to provide the reference for
matching the identity of the smart relay (because this is unrelated
to the EMail address).

But for delivering EMails to their target domain, matching the
certificate of the server to the target of the MX record just doesn't
make sense security-wise (notwithstanding that this is what is being
done if SMTP is delivering EMail insecurely in rfc821 fashion).

-Martin

---

From: Mark Andrews <[email-masked]>
Date: Tue, 17 Jan 2012 15:58:37 +1100

In message <[email-masked]>, Martin Rex writes
> left for which the above text suggests a tail match.

No.  You have the server name.  How you got the server name is out-of-scope.

> sprinkling magic encryption pixie dust on the connection.

RFC3207 is *part* of the solution.  DNSSEC is *part* of the solution.

There are mail domains where the MX records are signed today that
have verifiable CERTs presented when STARTTLS is issued.  This isn't
pixie dust.  This is 2012 reality.  Now stop living in 1900's.

"*.oz.au MX 0 munnari.oz.au" existed as MX record for many years.
It supported gatewaying 100's of thousands of email domains off the
Internet to ACSNet.  Doing this is *still* a valid use for wildcard
MX records.

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 17 Jan 2012 10:06:37 +0100

Guys,

I think this thread is spinning off, so we need to stop here.

> The security properties of the TLSA record apply only to the triple of domain name and transport protocol and port number that was looked up. If TLSA is used with an application protocol that uses…

is fine as is and Richard's text is overly too complicated.

It starts to look like we are solving problems outside the scope of the working group.  We are making association between certificate and domain name.  And the application _already_ know what (server) certificate it wants too look up.  So let's focus back and leave it to other protocol.  It's not our role to say how they MX should be looked up nor how the jabber client should handle DNS.  We just say - look for the TLSA with name you are going to search in the certificate.

Ondrej

---

From: Richard L. Barnes <[email-masked]>
Date: Tue, 17 Jan 2012 14:01:56 -0500

> What the heck does the second sentence mean? Why are NS records considered "DNS-layer redirection records"? How does an application know whether a DNAME record was used in resolution?

I just took the NS/DNAME/CNAME taxonomy from Olafur's message, because, well, he knows more about the DNS than me :)  And in fact, if you're using them in resolution of TLSA, then they do all need to be secure.  So something on the host needs to check whether they are.  As Lawrence points out, that can be either the DNS API or the application.

> I propose that you are well down the rabbit hole. The earlier text I proposed covers exactly what the first sentence above says it should.

Looking back at it again, I still find that your text unnecessarily restricts the applicability of DANE.  The only major difference between two proposals is what happens when you get an insecure redirection:
Hoffman: Fail
Barnes: Locate TLSA using any secure information you did find

IOW, your proposal means that DANE can only be deployed in a perfect world of universal DNSSEC, while mine accommodates some of the messiness of reality.  

--Richard

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 17 Jan 2012 14:52:34 -0500

> <snip/>
> It starts to look like we are solving problems outside the scope of the working group.  We are making association between certificate and domain name.  

This is right...

> And the application _already_ know what (server) certificate it wants too look up.  

... but the "(server)" here is wrong.

All that I'm objecting to is the conflation of names with servers.  The application knows what *name* it wants to authenticate, so let it use that name, regardless of whether it represents the server directly or not.

Insisting that the *server* name be used leads either to (1) spoofing vulnerabilities, or (2) a universal requirement for DNSSEC.  (1) is bad for security; (2) is bad for deployment.

--Richard

> So let's focus back and leave it to other protocol.  It's not our role to say how they MX should be looked up nor how the jabber client should handle DNS.  We just say - look for the TLSA with name you are going to search in the certificate.
> 
> Ondrej
>

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 17 Jan 2012 15:45:39 -0500

> IOW, your proposal means that DANE can only be deployed in a perfect world of universal DNSSEC, while mine accommodates some of the messiness of reality.
For the record I agree with Paul, any thing not signed or does not 
verify ===> hard Failure.

	Olafur

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 17 Jan 2012 21:52:56 +0100

> All that I'm objecting to is the conflation of names with servers.  The application knows what *name* it wants to authenticate, so let it use that name, regardless of whether it represents the serv…

I believe that one would want to look up "stuff" for either (a) hostname/transport/port or (b) service/protocol/transport, and the current draft describes (a).

- Some protocols does not (currently) use SRV and will be very happy with (a). Example:

    _443._tcp.www.kirei.se. IN TLSA

- You can do (b) by getting the hostname/transport/protocol triplet from SRV (or MX), then continue with (a). As a DNS person, this feels good. Example:

    _sips._tcp.kirei.se.      IN SRV 0 0 5061 sip1.kirei.se.
    _sips._tcp.kirei.se.      IN SRV 0 0 5062 sip2.kirei.se.
    _5061._tcp.sip1.kirei.se. IN TLSA ...
    _5062._tcp.sip2.kirei.se. IN TLSA ...

- You could also do (b) by first doing SRV (or MX), then lookup the TLSA record using the _service_ domain name combined with the transport & port from the SRV (hence requiring all servers serving the service use a common set of transport and port numbers, see example). That feels awkward to me as it is combining properties of the service name and the server hostname, but if that is what people want to do I'm not going to argue.

    _sips._tcp.kirei.se. IN SRV 0 0 5061 sip1.kirei.se.
    _sips._tcp.kirei.se. IN SRV 0 0 5062 sip2.kirei.se.
    _5061._tcp.kirei.se. IN TLSA ...
    _5062._tcp.kirei.se. IN TLSA ...

And please note that what is matched from the certificate association once looked up is not in scope here, I'm just talking about the lookup sequence.

I would actually be quite happy if we allowed both _port._transport.hostname and _protocol._transport.servicename for the TLSA lookup, but we might be way down the rabbit's hole for something like that.

	jakob

---

From: Martin Rex <[email-masked]>
Date: Tue, 17 Jan 2012 22:17:37 +0100 (MET)

Jakob Schlyter wrote:
> Richard L. Barnes wrote:
> > O. wrote:
> > All that I'm objecting to is the conflation of names with servers.
> > The application knows what *name* it wants to authenticate, so let
> > it use that name, regardless of whether it represents the server
> > directly or not.

I share Richard's concern here.  (He stated it more clearly than I did).

> 
> I believe that one would want to look up "stuff" for either
> (a) hostname/transport/port or (b) service/protocol/transport,
> and the current draft describes (a).

agreed. the current draft describes (a).

>     _443._tcp.www.kirei.se. IN TLSA

And it is independent of whether the server is located as

    aa)   www.kirei.se.   IN  A   0.1.2.3

    ab)   www.kirei.se.   IN CNAME  www.l.kirei.se.
          www.l.kirei.se. IN  A   0.1.2.4

    ac)   www.kirei.se.   IN CNAME  www.example.org.
          www.example.org IN  A   0.2.3.4

the certificate will always be matched against www.kirei.se,
and there is *NO* dependecy that the address lookup (and any other
zones that might be crossed, such as example.org in (ac) are also
DNSSEC protected.  Security is maintained if they're not DNSSEC
protected.  Traditional PKIX identification is possible without
DANE and without DNSSEC on any zones.

>     _5062._tcp.sip2.kirei.se. IN TLSA ...

That looks like a bad idea to me, because it creates additional
dependencies (and huge complexity) for protecting all other lookups
(besides TLSA) and in particular for other zones that may be walked
during one any of the indirections.

> 
> - You could also do (b) by first doing SRV (or MX), then lookup the TLSA
> record using the _service_ domain name combined with the transport & port
> from the SRV [...]
>

That is not what I had in mind.

I rather believe this should be used:

_sips._tcp.kirei.se. IN SRV 0 0 5061 sip1.kirei.se.
_sips._tcp.kirei.se. IN SRV 0 0 5062 sip2.kirei.se.
_sips._tcp.kirei.se. IN TLSA ...
                     IN TLSA ...

This would *not* add any additional complexity nor require additonal DNSSEC
checks (in particular none for any other DNS zones) to the TLSA lookup and
validation, and it can be easily and safely used with normal PKIX validation.

For hosting scenarios in particular, you do not have to wait until
both you and your hoster have DNSSEC fully deployed, but instead you can
start using it with DANE as soon as you have DNSSEC in your zone,
and could choose and switch your hoster independent of their DNSSEC
deployment. 

-Martin

---

From: Matt Miller <[email-masked]>
Date: Tue, 17 Jan 2012 14:28:20 -0700

> and could choose and switch your hoster independent of their DNSSEC

I completely agree with Martin; he's put words to my thoughts better than I have (-:

- m&m

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 18 Jan 2012 00:10:33 +0000

On 17 Jan 2012, at 20:52, Jakob Schlyter wrote:
<snip>

To which I reply:

Hi Jakob, folks,

It CAN be slightly more complex; the example you've given is actually a fallback.
RFC3263 includes NAPTRs as well as SRVs (and a further fallback to A records and default ports), so I guess that you could have:

   kirei.se.            IN NAPTR 50   50  "s"  "SIPS+D2T"     ""  _sips._tcp.kirei.se.
   kirei.se.            IN NAPTR 50   60  "s"  "SIPS+D2T"     ""  _sips._tcp.frobit.se.
   _sips._tcp.kirei.se. IN SRV 0 0 5061 sip1.kirei.se.
   _sips._tcp.kirei.se. IN SRV 0 0 5062 sip2.kirei.se.

and ...
   _sips._tcp.frobit.se. IN SRV 0 0 5066 sip0.frobit.se.
   _sips._tcp.frobit.se. IN SRV 0 1 5062 sip2.kirei.se.

   _5066.frobit. IN TLSA ...

(Working out what certs get processed is left as an exercise for the student ;).

The processing and validation to get to the SIP server for kirei.se. could traverse zones (across and back again, or on to some other zone) and involve several separate DNS queries.
As you (and Olifur and ...) say, the application processing chain continues only if the application gets validated results to all its DNS queries.
If there are some CNAMES (or DNAMEs) as well, they will be handled at the DNS level -- the SIP SUA doesn't even need to see the intermediary records.
The DNSSEC processing seems straightforward. We're done, right?

This is similar to pretty much any application -- if the DNS queries return validated results, you're good to go.
If ANY of the results in the chain returned to the application is not validated, then the application has to decide what to do AT THAT POINT IN ITS PROCESSING.
That is up to the application. It is not up to the DNS query processing to decide. No special processing.

SO why are we still having this discussion?

all the best from a bemused
  Lawrence

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 17 Jan 2012 20:11:48 -0500

The problem with that position is that it makes rules out use cases that can be done securely without universal DNSSEC.  As Lawrence, Martin, and Matt have all pointed out, this includes things like SIP and XMPP.  And it rules them out for no technical  reason.

I agree that the proposed text I kept editing got weirder and weirder.  Let me try to propose something again, starting from Paul's text:
"
The TLSA record is used to make a certificate association between for a triple of domain name, transport protocol, and port number where a TLS based service may exist.  The triple used for TLSA lookup may be different than what the application started with, if the application protocol uses DNSSEC-protected SRV or MX records to find a server. Similarly, the certificate association returned in TLSA may have a domain name that is different than the domain name used in the TLSA query, depending on the application protocol's rules for TLS server identification.
"

IMO, this is underspecified, since there's no actual concrete guidance for what applications should do.  But the group seems intolerant of further specificity, so I'll leave it at that for now.  (Editorially, the above should go in Section 3.)

--Richard

On Jan 17, 2012, at 3:45 PM, Olafur Gudmundsson wrote:

> For the record I agree with Paul, any thing not signed or does not verify ===> hard Failure.
> 
> 	Olafur
>

---

From: Mark Andrews <[email-masked]>
Date: Wed, 18 Jan 2012 12:34:33 +1100

In message <[email-masked]>, "Richard L. Barnes" 
writes:
> > It starts to look like we are solving problems outside the scope of the 
> working group.  We are making association between certificate and domain 
> name.  
> 
> This is right...
> 
> All that I'm objecting to is the conflation of names with servers.  The 
> application knows what *name* it wants to authenticate, so let it use 
> that name, regardless of whether it represents the server directly or not.
> 
> Insisting that the *server* name be used leads either to (1) spoofing 
> vulnerabilities, or (2) a universal requirement for DNSSEC.  (1) is bad 
> for security; (2) is bad for deployment.
> 
> --Richard

Firstly, using a server does NOT require *universal* DNSSEC.  It
just requires that the zones involved be signed which they will be
99.999% of the time if you are using DANE.

In most cases all the records involved will be in the same zone.

e.g.
	example.com MX 0 mail.example.com
	mail.example.com A 1.2.3.4
	mail.example.com AAAA 2001::1.2.3.4
	_25._tcp.mail.example.com TLSA ...

Or in the outsourced case 2 zones if DANE is being used

	example.com MX 0 mx.provider.net
	mx.provider.net A 1.2.3.4
	mx.provider.net AAAA 2001::1.2.3.4
	_25._tcp.mx.provider.net TLSA ...

and if you are not using DANE, provider.net does not need to be
signed.  The presented CERT just has to be for mx.provider.net using
a well known CA.

Secondly, not everything is immediate client / server like HTTPS.
Email for one isn't.  It is store and forward.

One needs to pick the correct name for the type of service.  For
HTTPS it is the name the user entered.  For email it is the server
name in the MX record (as published or synthesized).

Mark

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Jan 2012 03:24:43 +0100 (MET)

> name in the MX record (as published or synthesized).

We should agree to disagree and discontinue the discussion of
whether or not mta-mta SMTP-AUTH server endpoint identification
is broken.

Ondrej indicated that this is outside of the charter of this WG
and the discussion is running in circles.

> 99.999% of the time if you are using DANE.

Your proposed scheme certainly would.

Keep in mind that a client with DANE will (attempt to) to use 100% of
the time and the DNS zone where it will succeed are at 0% today
and may be at ~5% in 5 years from now (long tail).

> 	_25._tcp.mail.example.com TLSA ...

I'm not aware that @gmail.com users have serious connectivity problems,
which means that todays SMTP relays have to deal with weird setup like
these, effectively they have to ignore the name in the certificate
entirely.  The check that you assert/suggest does NOT work today.

;; QUESTION SECTION:
 ;gmail.com.			IN	MX
 
 ;; ANSWER SECTION:
 gmail.com.	3600	IN	MX	5 gmail-smtp-in.l.google.com.
 gmail.com.	3600	IN	MX	10 alt1.gmail-smtp-in.l.google.com.
 gmail.com.	3600	IN	MX	20 alt2.gmail-smtp-in.l.google.com.
 gmail.com.	3600	IN	MX	30 alt3.gmail-smtp-in.l.google.com.
 gmail.com.	3600	IN	MX	40 alt4.gmail-smtp-in.l.google.com.

openssl s_client -no_ssl2 -starttls smtp -connect gmail-smtp-in.l.google.com:25

will obtain a Server certificate (under a well-know root) issued
to the server "mx.google.com".  That name in the server neither matches
the EMails target domain (@gmail.com), nor does it match the server
hostname that the MX record points to (gmail-smtp-in.l.google.com).

There are 100 Million DNS domains,  Even if only 1% of those are used
for EMail, you can not seriously expect every sysadmin on this world
to manually cope with every exception there is.  For the installed
base, matching of names from certificates in mta-mta SMTP-AUTH
delivery will reliably cause interop problems, that is a sad fact of life.

-Martin

---

From: James Cloos <[email-masked]>
Date: Tue, 17 Jan 2012 21:58:40 -0500

>>>>> "MA" == Mark Andrews <[email-masked]> writes:

MA> Or in the outsourced case 2 zones if DANE is being used

Note that it isn't only outsourced cases.  Corps often have multiple
unrelated domain registrations covering, eg, the corporate name, DBAs,
trademarks and even promotions.  Not to mention additional registrations
used for attempts at efficiency.  They may very well want email or voip
to any or all of those to reach a central (set of) server(s), and so the
MXs and NAPTRs/SRVs may all point to a single target zone.

Individuals may also have multiples, especially com/net/org sets, etc.

Richard's last proposal seems OK.  We should just specify the port/
transport lookup and allow the application protocols to determine
whether a given cert CN or alternatename should be accepted or refused.

Of course, one hopes that once dnssec and tlsa get more widely adopted
that agile, short-term certs will become more common.

-JimC

---

From: James Cloos <[email-masked]>
Date: Tue, 17 Jan 2012 21:59:37 -0500

>>>>> "RLB" == Richard L Barnes <[email-masked]> writes:

RLB> I agree that the proposed text I kept editing got weirder and
RLB> weirder.  Let me try to propose something again, starting from
RLB> Paul's text:
RLB> "
RLB> The TLSA record is used to make a certificate association between
RLB> for a triple of domain name, transport protocol, and port number
RLB> where a TLS based service may exist.  The triple used for TLSA
RLB> lookup may be different than what the application started with, if
RLB> the application protocol uses DNSSEC-protected SRV or MX records to
RLB> find a server. Similarly, the certificate association returned in
RLB> TLSA may have a domain name that is different than the domain name
RLB> used in the TLSA query, depending on the application protocol's
RLB> rules for TLS server identification.
RLB> "

That wording looks reasonable.

-JimC

---

From: Mark Andrews <[email-masked]>
Date: Wed, 18 Jan 2012 14:48:44 +1100

> delivery will reliably cause interop problems, that is a sad fact of life.

No.  I expect Google to correct their MX records/CERT so they are
*consistent*.  This isn't rocket science.  It's only sloppy
administation that has cause this *misconfiguration* to exist.

mx.google.com is a meaningless cert, supplying it is pointless.

All it would take is for Google, Microsoft and Yahoo to turn on
STARTTSL and verify the returned cert for the rest of the world to
fix their misconfiguration.  It's like IPv6, it requires a number
of the large providers to turn it on at the same time.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 17 Jan 2012 20:45:44 -0700

On 1/17/12 6:11 PM, Richard L. Barnes wrote:
> The problem with that position is that it makes rules out use cases
> that can be done securely without universal DNSSEC.  As Lawrence,
> Martin, and Matt have all pointed out, this includes things like SIP
> and XMPP.  And it rules them out for no technical  reason.
> 
> I agree that the proposed text I kept editing got weirder and
> weirder.  Let me try to propose something again, starting from Paul's
> text: " The TLSA record is used to make a certificate association
> between for a triple of domain name, transport protocol, and port
> number where a TLS based service may exist.  The triple used for TLSA
> lookup may be different than what the application started with, if
> the application protocol uses DNSSEC-protected SRV or MX records to
> find a server. Similarly, the certificate association returned in
> TLSA may have a domain name that is different than the domain name
> used in the TLSA query, depending on the application protocol's rules
> for TLS server identification. "
> 
> IMO, this is underspecified, since there's no actual concrete
> guidance for what applications should do.  But the group seems
> intolerant of further specificity, so I'll leave it at that for now.
> (Editorially, the above should go in Section 3.)

Richard, I assume that a spec could provide that further specificity for
a particular application protocol. I think it makes sense to say that
here, even if we don't provide guidance regarding the nature of that
further specificity.

Peter

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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 18 Jan 2012 16:09:20 +1100

> MXs and NAPTRs/SRVs may all point to a single target zone.

Which works fine.  You just put the host name matching the cert on
the RHS of the MX record and let the nameserver constuct the LHS.

	@ SOA ...
	@ NS ...
	@ MX 0 <NAME IN CERT>.
	@ A 1.2.3.4.
	@ AAAA 2001::1
	www CNAME @

Now since this is DANE and you want all those https connections to
be secure for www.*, tell me how you turn on DANE for www.* without
signing all the zones that contain the address records for www.*?

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 18 Jan 2012 11:59:54 +0100

This discussion reminds me of old joke:

Have you heard about the new Cray? It's so fast, it requires TWO halt instructions to stop it!

> The TLSA record is used to make a certificate association between for a triple of domain name, transport protocol, and port number where a TLS based service may exist.  The triple used for TLSA loo…

As I understand the wdiff (apart from editorial fixes and minor nits) you only have added {+DNSSEC-protected+} in front of SRV or MX records.

Just to clarify - as I understand the new wording:

The triple may be different, if DNSSEC was used.  Does that also imply - If DNSSEC was not used than you have to use the old triple?  And may the application use the "old triple" instead of "new triple" even if DNSSEC was used?

I am very uncomfortable with this, since it creates ambiguity for the implementations.  We should not build our protocol on top of the status of current DNSSEC deployment.  I think we already ruled that out when we said: "DNSSEC required" in Issue #36.  Let's not have this discussion again, please.

> IMO, this is underspecified, since there's no actual concrete guidance for what applications should do.
> But the group seems intolerant of further specificity, so I'll leave it at that for now.  (Editorially, the above should go in Section 3.)

My view is that there are already algorithms how to find a name the application will look for in the certificate.  And we should stick to just referring to that algorithm (since it may change in the future, etc.).

Or put I should put it in another way - there's no difference between existing TLS/PKI and DANE when doing SRV and MX records.  If you got spoofed when doing additional lookups you will connect to different server.  That's why I really think it is out of the scope of this WG.  We should work on finishing DANE and not on fixing other protocols (which may be bad) on the way (unless we absolutely have to).

Since this discussion again started to go in circles, I will send another email when I will ask just for +1/-1.

O.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 19 Jan 2012 19:40:21 -0800

While looking over the discussion, I tried to winnow out the parts that were not about Issue #28, and the parts that were no in the purview of this WG. After doing that and taking a deep breath, I think we (maybe) end up with the following.

The TLSA record is used to make an association between a certificate and a (domain name, transport protocol, port number) triple where a TLS based service is assumed to exist. The triple is used to perform the lookup described in Section 3. Most application protocols only use one domain name in their connection procedures. However, some application protocols such as XMPP [RFC6120] begin with one domain name and end up with a potentially-different domain name; in such cases, the application always uses the name with which it started for the TLSA lookup.

That is:
- Application protocols that do not begin with one domain name and end up with a potentially-different one are not an issue because they only have one name to deal with
- There are no security issues with using the first name for the other protocols like XMPP because of the DNSSEC requirements for the TLSA record regardless of the DNSSEC requirements for any other part of those protocols.
- The side-trip we took on CNAME/DNAME is not related to looking up TLSA records on the starting name.

Folks in the WG probably still disagree about what applications should do with the domain names in the certificates, but that's a discussion for RFC 6125 and is not addressed by TLSA at all.

Does this help?

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Fri, 20 Jan 2012 15:15:14 +1100

In message <[email-masked]>, Paul Hoffman writes
:
> While looking over the discussion, I tried to winnow out the parts that were 
> not about Issue #28, and the parts that were no in the purview of this WG. Af
> ter doing that and taking a deep breath, I think we (maybe) end up with the f
> ollowing.
> 
> The TLSA record is used to make an association between a certificate and a (d
> omain name, transport protocol, port number) triple where a TLS based service
>  is assumed to exist. The triple is used to perform the lookup described in S
> ection 3. Most application protocols only use one domain name in their connec
> tion procedures. However, some application protocols such as XMPP [RFC6120] b
> egin with one domain name and end up with a potentially-different domain name
> ; in such cases, the application always uses the name with which it started f
> or the TLSA lookup.
> 
> That is:
> - Application protocols that do not begin with one domain name and end up wit
> h a potentially-different one are not an issue because they only have one nam
> e to deal with
> - There are no security issues with using the first name for the other protoc
> ols like XMPP because of the DNSSEC requirements for the TLSA record regardle
> ss of the DNSSEC requirements for any other part of those protocols.
> Folks in the WG probably still disagree about what applications should do wit
> h the domain names in the certificates, but that's a discussion for RFC 6125 
> and is not addressed by TLSA at all.
> 
> Does this help?

No.  It is up to the protocol using SRV, or other record types, to
define which domain name is fed into the the TSLA lookup.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 20 Jan 2012 06:55:17 -0800

> define which domain name is fed into the the TSLA lookup.

Please say more. For example, if TLSA was released today, why would HTTPS need to be changed to say "use the one name that you are using"?

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Fri, 20 Jan 2012 17:30:20 +0100 (MET)

Mark Andrews wrote:
> 
> It is up to the protocol using SRV, or other record types, to

I actually can agree with that statement.

How to come up with a trustworthy domain name that is fed into
the TLSA lookup (as specified by DANE) is up to the application
protocol.

Similarly, how to secure any transformations on an original domain
name from a trustworthy source into something that is finally used
for the DANE TLSA lookup is up to the application protocol and outside
of the scope of DANE protocol.

Anyhow, I would appreciate at least a guidance in DANE protocol how
applications could avoid/obviate any complex protocol extensions before
being able to use DANE (or PKIX) securely, i.e. by doing what HTTPS
or XMPP do (not performing any translations on the domain name that
is used for the DANE TLSA lookup.

> signing all the zones that contain the address records for www.*?

You're misunderstanding DANE.  The address records for https://
connections do *not* need to be signed.  PKIX-based server endpoint
identification never had such a prerequisite, and neither will DANE.

DANE can be use as complementary to PKIX or as an alternative/substitute,
and DANE itself only needs DNSSEC validation of the TLSA lookup
in order to be secure.

-Martin

---

From: Warren Kumari <[email-masked]>
Date: Fri, 20 Jan 2012 14:36:47 -0500

> The TLSA record is used to make an association between a certificate and a (domain name, transport protocol, port number) triple where a TLS based service is assumed to exist. The triple is used to…

How would folk feel about adding something along the lines of:
"It is understood that this may not work for all current protocols. These protocols are encouraged to specify alternate lookup procedures or not deploy DANE".

If each protocol has to define it's own lookup procedure in order to use DANE we are basically dead in the water.

We also are not in a position (nor should we be!) where *we* can specify this for each protocol, so we could:
A: Go with the proposed text and solve this for most cases.
B: Simply say that this only works for "protocols only use one domain name in their connection procedures" and then go down the "Is protocol X (e.g SMTP) a 'one domain name" protocol?" rathole.
C: Go with the proposed text and then, for a few choice protocols specify alternate procedure (and maybe a registry to track this).

My preference would be for A.
B and C seems like they will end up being really messy (and painful) and would necessitate us understanding (and specifying things!) for other WG's protocols (at which point our friendly ADs will come knocking...)
In an ideal world we would wave a magic wand and every protocol designer would give us a thumbs up on the proposed lookup mechanism or a clear, concise alternate, but we don't live in an ideal world (but hopefully we can try make it just a little bit more ideal :-P)

W

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 20 Jan 2012 16:03:18 -0500

> The TLSA record is used to make an association between a certificate and a (domain name, transport protocol, port number) triple where a TLS based service is assumed to exist. The triple is used to…

My only major complaint with this text is that it unnecessarily forbids the use of DNSSEC-protected redirection records to redirect DANE.  For example, the following would be supported by the above text:
  _xmpp-server._tcp.a.com SRV jabber.b.com 522 [no DNSSEC]
  a.com TLSA ..... [with DNSSEC]
But the following case would be forbidden by the above text:
  _xmpp-server._tcp.a.com SRV jabber.b.com 5222 [with DNSSEC]
  jabber.b.com TLSA ..... [with DNSSEC]

ISTM that it would be good to have our text allow both of these cases.  They offer equivalent security properties, and different costs/benefits with regard to deployment.  For example, the second scenario above is what you would want to do if you wanted to outsource, say, XMPP services without having to update your DNS whenever your outsourcing provider changes certificates.

Which sort of brings us back to a point I made way back in the thread (and which Mark just revived): Apps know what names they're going after, so we should let them decide where to look for TLSA.  In the single-name case, it's obvious; in redirection cases, it will depend on where there's DNSSEC.  Plus, we obviously can't handle every protocol in this document; it will be helpful in many cases to have clarifying documents.  The trouble is how to say all this concisely :)

Suggested text, trying to maintain the simplicity of the original proposal (but probably failing):
"
The TLSA record is used to make an association between a certificate and a (domain name, transport protocol, port number) triple where a TLS based service is assumed to exist. The triple is used to perform the lookup described in Section 3. Many application protocols, such as HTTPS [RFC2818], only use one domain name in their connection procedures.  These applications simply use that domain to find TLSA records.  

Other application protocols such as SMTP [RFC3207], XMPP [RFC6120], and SIP [RFC3261] may begin with one domain name and end up with a different domain name.  In such cases, it is always safe for the application to use the name with which it started for the TLSA lookup.  If service delegation records (e.g., MX, SRV) are protected with DNSSEC, then applications may choose to use the "target" names of these records to locate TLSA records.

This document does not define a specific procedure by which applications to choose a domain name to use to find TLSA records.  For protocols where there is ambiguity, especially around redirection, there may be a need for further application-specific standards.
"

Couple of editorial things:
1. This should be in Section 3 (as I've said before!)
2. Examples would be helpful, e.g., for HTTPS, SMTP, and XMPP/SIP
3. The phrase "is assumed to exist" makes me squirm.  Who assumes?  Why are they assuming, instead of acting on real data?  In fact, the TLSA publisher is the owner of the TLS service, so they should know for real.  s/is assumed to exists/exists/

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 20 Jan 2012 13:20:37 -0800

On Jan 20, 2012, at 1:03 PM, Richard L. Barnes wrote:

> ISTM that it would be good to have our text allow both of these cases.  

Yes, if possible.

> They offer equivalent security properties, and different costs/benefits with regard to deployment.  For example, the second scenario above is what you would want to do if you wanted to outsource, say, XMPP services without having to update your DNS whenever your outsourcing provider changes certificates.
> 

It would be better to have our text have consistent and interoperable implementations.  It would also be good for out text not to make assertions about protocols such as RFC 3207 that we know are ambiguous.

What we really want is "look for the TLSA record down the redirection chain and grab the first one you see". That makes it easy for protocols where there is no redelegation chain, and also allows for the case you propose, as long as the redelegation chain is secure. So, much simpler than your proposal:

The TLSA record is used to make an association between a certificate and a (domain name, transport protocol, port number) triple where a TLS based service is assumed to exist. The triple is used to perform the lookup described in Section 3. Most application protocols only use one domain name in their connection procedures. However, some application protocols such as XMPP [RFC6120] begin with one domain name and end up with a potentially-different domain name through a chain of lookups; in such cases, the application uses the first name in the chain that has a TLSA record, as long as that is either the first name or a name reached through DNSSEC-protected redirection records.

--Paul Hoffman

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 20 Jan 2012 16:36:06 -0500

> It would be better to have our text have consistent and interoperable implementations.  

The "interoperability" we need is of the following form: For each protocol where DANE is used for authentication, there needs to be an unambiguous procedure a client to select a set of TLSA records to use.

The question for this group is whether we need to define in this document a uniform procedure followed by every protocol.  That is what your text is attempting to do.

IMO: Defining a uniform procedure for all protocols is not viable, due to the diversity of use cases.  In order for DANE to be deployable, we should specify guidelines to minimize ambiguity, especially for obvious cases like HTTPS.  But we should not attempt to resolve ambiguity that is created by application protocols' service discovery mechanisms.  Instead, we should define which options are safe (namely, DNSSEC-based indirection steps) ask the application communities to choose.  This is what my text is attempting to do.

--Richard

---

From: Matt Miller <[email-masked]>
Date: Fri, 20 Jan 2012 14:40:54 -0700

(I'm ignoring the non-DNSSEC cases...)

I've been pondering how I would want to implement this, and I think my current preference is something like:

_xmpp-server._tcp.a.com SRV jabber.b.com 5222 [DNSSEC] ==>
   a) _xmpp-server._tcp.a.com TLSA .... [DNSSEC], fallback to
   b) a.com TLSA .... [DNSSEC], fallback to
   c) _xmpp-server._tcp.jabber.b.com TLSA .... [DNSSEC], fallback to
   d) jabber.b.com TLSA .... , fallback to
   e) existing behaviors

To be honest, I'm not sure I'd want to do b) or c) right now (but I'm not sure I DON'T want to, either).

But what I think it really means is, maybe this should be left completely up to the individual protocols (or maybe even applications) to determine, and DANE should declare this problem out of scope.

- m&m

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 20 Jan 2012 14:37:00 -0800

> The "interoperability" we need is of the following form: For each protocol where DANE is used for authentication, there needs to be an unambiguous procedure a client to select a set of TLSA records…

Fully agree.

> The question for this group is whether we need to define in this document a uniform procedure followed by every protocol.  That is what your text is attempting to do.

Yes. Otherwise, we will get into the same situation that RFC 6125 had, where two seemingly-similar protocols have very different processing procedures. That might be OK for some people, but maddening for others.

> IMO: Defining a uniform procedure for all protocols is not viable, due to the diversity of use cases.  In order for DANE to be deployable, we should specify guidelines to minimize ambiguity, especially for obvious cases like HTTPS.  But we should not attempt to resolve ambiguity that is created by application protocols' service discovery mechanisms.  Instead, we should define which options are safe (namely, DNSSEC-based indirection steps) ask the application communities to choose.  

I'm OK with that, if the WG understands that a few years from now, people will bitch at us for not having done it right the first time. I agree that specifying for the obvious cases like HTTPS might be sufficient, even if it is not completely satisfying.

> This is what my text is attempting to do.

It misses by overstating, I believe. But I hear that mine overstates as well.

--Paul Hoffman

---

From: Scott Schmit <[email-masked]>
Date: Sat, 21 Jan 2012 15:51:27 -0500

On Fri, Jan 20, 2012 at 01:20:37PM -0800, Paul Hoffman wrote:
> It would be better to have our text have consistent and interoperable
> implementations.  It would also be good for out text not to make
> assertions about protocols such as RFC 3207 that we know are
> ambiguous.
> 
> What we really want is "look for the TLSA record down the redirection
> chain and grab the first one you see". That makes it easy for
> protocols where there is no redelegation chain, and also allows for
> the case you propose, as long as the redelegation chain is secure. So,
> much simpler than your proposal:
> 
> The TLSA record is used to make an association between a certificate
> and a (domain name, transport protocol, port number) triple where a
> TLS based service is assumed to exist. The triple is used to perform
> the lookup described in Section 3. Most application protocols only use
> one domain name in their connection procedures. However, some
> application protocols such as XMPP [RFC6120] begin with one domain
> name and end up with a potentially-different domain name through a
> chain of lookups; in such cases, the application uses the first name
> in the chain that has a TLSA record, as long as that is either the
> first name or a name reached through DNSSEC-protected redirection
> records.

I think this is the most secure way to specify this without making each
application protocol specify how it is to be done.

I'll point out, however, that the text could be read as applying to
CNAMEs, which this WG previously stated should not get this kind of
treatment, I think primarily because DNS resolution libraries don't give
that kind of visibility to facilitate the lookup.

Also, a downside of the approach is the latencies involved in
determining that there is no TLSA record at all--every step of the chain
must be checked.

We could specify the most-common case and let the applications decide
the rest, but that feels like punting to me and will ultimately make
DANE harder to deploy due to the inconsistent decisions made by various
applications.

If we pick the hostname, we end up requiring DNSSEC to be secure at
every step in the chain to remain secure. This may make DANE
undeployable in the near term for some sites. In the long term, however,
this is hopefully not a huge problem. It seems like generating
appropriate certificates for the hosts could be challenging in some
cases (if a.com & b.com delegate to c.com, how does c.com get a
certificate saying it's good for both?), but this isn't new and has been
resolved somehow. This gets simpler if SPKI matching is used.

If we pick the starting domain name, you don't need universal DNSSEC,
but updates to the TLSA records will always require coordination between
the hosts and the domain. That said, it's not terribly different from
the coordination required to set up the SRV records, but the TLSA
records will change more often (due to key rolling). This will be better
in the near term, but the operational complexity will never go away.

Another downside of this would be the confusion caused by this scenario:

_tlsservice._tcp.example.com. SRV 0 0 1234 foo.example.com.
_tlsservice._tcp.example.com. SRV 0 0 5678 bar.example2.net.
_tlsservice2._tcp.example.com. SRV 0 0 5678 foo.example.com.

The above implies that the proper TLSA records would be:

_1234._tcp.example.com TLSA [stuff for foo.example.com:1234/tlsservice]
_5678._tcp.example.com TLSA [stuff for bar.example2.net:5678/tlsservice]
_5678._tcp.example.com TLSA [stuff for foo.example.com:5678/tlsservice2]

The more I think about it, the more I like keeping the record with the
hostname, with "first record in the chain" as a second choice.

-- 
Scott Schmit

---

From: Mark Andrews <[email-masked]>
Date: Sun, 22 Jan 2012 10:46:07 +1100

In message <[email-masked]>, Scott Schmit writes:
> >=20
> >=20

One size does not fit.  You are wasting the working groups time trying
to make one size fit all.

> treatment,

It really depend on the protocol and its rules with respect to
CNAMES.  For HTTPS, CNAME is used like a SRV or MX record.  This
really is *wrong* from a DNS perspective.  This "decision" is still
causing operational problems today as it does not work for name at
the apex of a zone.

> I think primarily because DNS resolution libraries don't give

Actually most libraries *do* return the canonical name.  It the
applications that choose to ignore that the canonical name differs.

> DANE harder to deploy due to the inconsistent decisions made by various

DANE is no harder to deploy regardless of which name the application
chooses to use.

Getting a secure application may be harder, but deploying DANE
isn't.  Also it is *not* the DANE wg job to fix these applications.

> If we pick the hostname,

We do *not* get to make this choice.  This choice is out of scope
for DANE.  DANE's job is to say how to get to the TLSA record *once*
the application has the name, port and transport.  It is *not* DANEs
job to describe how the application goes from its inputs to that
name.

> we end up requiring DNSSEC to be secure at
> --=20

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 26 Jan 2012 09:21:19 +0100

> I'm OK with that, if the WG understands that a few years from now, people will bitch at us for not having done it right the first time. I agree that specifying for the obvious cases like HTTPS migh…

I sense we are still going in the circles.  Would it be acceptable
for WG (and ADs) to say something like (in simple terms):

"Use the first name unless the protocol specifies otherwise."

And then create RFCs for different protocols as an inter-WG effort?
Say one RFC for MX, one for XMPP, one for SIP and one to rule them all?

I know that what I am suggestion is basically just postponing
the argument, but I have a feeling if we continue this we may
never agree and get DANE protocol out.

O.
P.S.: People will bitch at us anyway...

---

From: Scott Schmit <[email-masked]>
Date: Thu, 26 Jan 2012 08:16:34 -0500

> Say one RFC for MX, one for XMPP, one for SIP and one to rule them all?

+1 I can live with that. I'm a little nervous that there may not be energy
around creating these other documents, but I guess if there isn't then
the first name must be acceptable to everyone (or DANE's not going to
get deployed for them anyway).

-- 
Scott Schmit

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 26 Jan 2012 06:31:29 -0700

> get deployed for them anyway).

At least we'll find out who the customers are. ;-)

I'd volunteer to work on the XMPP spec -- we definitely want to use the
output of the DANE WG.

Peter

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 26 Jan 2012 13:35:01 +0000

Hiya,

> never agree and get DANE protocol out.

If following that plan you should probably also discuss whether
to recharter the DANE WG to do that, or whether its better to
handle those documents either in other WGs or as individual
submissions. Any of those could work, depending on what the
WG prefer.

S.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 26 Jan 2012 06:43:53 -0700

> submissions. Any of those could work, depending on what the

Given that there might not be active working groups for some of these
documents (e.g., MX), I think it would be more productive to work on
them all in DANE, coordinating with active WGs where appropriate.

Peter

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

---

From: Matt Miller <[email-masked]>
Date: Thu, 26 Jan 2012 08:02:34 -0700

+1

- m&m

---

From: Matt Miller <[email-masked]>
Date: Thu, 26 Jan 2012 08:03:24 -0700

> I'd volunteer to work on the XMPP spec -- we definitely want to use the

Since you've already volunteered to work on the XMPP spec, I volunteer to help (-:

- m&m

---

From: Warren Kumari <[email-masked]>
Date: Fri, 27 Jan 2012 18:36:28 -0500

Hi all,

Thank you all very much for all of your input and discussions on Issue #28 (Interaction of SRV and TLSA records).
While we would like to have settled on a one size fits all, it doesn't seem like we are going to be able to get consensus on that, so:

Unless we hear strong objections, we are going to go with the scheme that had (rough) consensus:  "use the first name that has a TLSA record, unless there is a protocol specific exception" scheme. This solutions solves the vast majority of cases, and still allows protocols that need special handling the ability to define it.

*After* we have launched the protocol doc, we will discuss:
1:  Rechartering DANE to work on the "Using DANE to work with Protocol_foo" documents (where foo is, for example, MX, SIP, XMPP / whatever)
2: Handing off these documents to other working groups (assuming they exist and are willing to work on this)
3: Individual submissions
or some combination of the above.

Our AD is supportive of this plan (the "After we have launched…" bit), but we will need to get the current work ( -protocol- ) completed before starting on the new docs. We are also NOT opening up the "Which one (or combination) of 1, 2, 3 are we going to do, and for what protocols" yet. We have enough to do and opening yet another can-of-worms^W discussion will just distract us further.

Again, we thank you for all of the work and passion that has gone into Issue #28 (and all the others), and for minimizing the drama.

Ondrej and Warren.

-- 
With Feudalism, it's your Count that votes.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 28 Jan 2012 12:09:41 -0800

> Unless we hear strong objections, we are going to go with the scheme that had (rough) consensus:  "use the first name that has a TLSA record, unless there is a protocol specific exception" scheme.…

Good stuff. Jakob and I have found an easy way to put this into the next draft.

--Paul Hoffman