Subject: [dane] draft-ietf-dane-srv-02 and CNAMEs

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 8 Apr 2013 14:58:18 +0000

In https://tools.ietf.org/html/draft-ietf-dane-srv-02#section-3.2 we have:

   The client SHALL construct the TLSA query name as described in
   [RFC6698] section 3, based on fields from the SRV record: port from
   the SRV RDATA, protocol from the SRV query name, and the TLSA base
   domain is the SRV target host name.

thus in case a target hostname in the SRV RR is a CNAME:

    _imap._tcp.example.com. IN SRV   0 0 143 imap.example.com.
    imap.example.com.	    IN CNAME mail.example.net.
    mail.example.net.       IN A     192.0.2.1

the associated TLSA RRset would be at:

	_143._tcp.imap.example.com.

rather than:

	_143._tcp.mail.example.net.

I would like to suggest that this choice is not robust:

    - It creates an unexpected difference between two previously
      equivalent configurations:

	; SRV target is an alias
	_imap._tcp.example.com. IN SRV   0 0 143 imap.example.com.

	; SRV target is the underlying host
	_imap._tcp.example.com. IN SRV   0 0 143 imap.example.net.

	In both cases the service end-point is the same, and a TLSA
	association may well be published by the example.net service
	provider.  However, the domain owner who decided to be flexible,
	and point at the provider through an alias misses out on the
	TLSA record.

    - It creates difficult to manage synchronization problems:

	If the domain owner is aware of the TLSA association not
	"following the CNAME", and decides to publish:

	  _143._tcp.imap.example.com. IN TLSA ?

	he cannot simply clone the provider's TLSA record, for this
	can change without coordination with the referring domain.
	Also the use of TA associations would be problematic, as the
	verifier would be looking for the wrong names in the service
	provider's certificate.

	Alternatively, he has to delegate to the service provider a
	a certificate + private key pair, and rely on SNI support in
	the server and all verifiers to make this work.  A service
	provider hosting a large number of domains would have to
	securely manage a large number of keys, carefully coordinated
	with the published TLSA records of the referring domains.

I think we can do much better than that, by eliminating the complexity:

  - When target hostname of an SRV record is a CNAME, the verifier MUST
    follow the CNAME (making sure each CNAME record traversed is DNSSEC
    validated).

  - The name used to construct the TLSA query domain is the final
    validated hostname.

  - The name verified in the peer certificate (when name checks are
    appropriate) is the final validated hostname.

This substantially reduces the chances of outages when SRV records
use indirection.  This also removes the need for SNI (which is not
universally supported) and the concomitant operational headaches
of moving key material across organizational boundaries.

Unlike browsers which expect to find the hostname from the URL
in the peer certificate (since CNAMEs are not assumed secure
pre DNSSEC), the TLSA verifier obtains all CNAMEs with DNSSEC
validation, and can safely follow these to the right base name
for the TLSA lookup.

Basing TLSA lookups on the canonicalized name substantially reduces
opportunities for errors (outages) and removes the associated need
for SNI support and cross-org key management headaches.

Please consider changing the draft accordingly.  The Postfix DANE
implementation follows CNAMEs (in MX RRs, but these as you well
know are simplified SRVs) before doing TLSA lookups.

I should note that I've read:

        https://tools.ietf.org/html/rfc6698#appendix-A.2.1

and have come to the conclusion that the content there serves to
explain the risks of mixing CNAMEs with TLSA records, and should
be viewed as "what to avoid" guide rather than "what to do" guide.

I don't see an explicit directive in 6698 to use one particular
base domain over another.  The various dangerous corner cases
brought to light in A.2.1 strongly motivate a preference for using
the real hostname (post all alias expansion) as the base domain
for TLSA records.

-- 
	Viktor.

---

From: Tony Finch <[email-masked]>
Date: Wed, 10 Apr 2013 19:29:47 +0100

> 	_143._tcp.mail.example.net.

Right. This is consistent with RFC 6698 section A.2. TLSA lookups need to
work the same way whether the client software is configured to use the
server host name directly, or if it is discovering the host name via a SRV
record. Also, client software can rely on standard resolver alias
processing, rather than having its own duplicate alias handling logic.

I think it would be unwise wrt. consistency with other specifications to
require weird behaviour in the face of a misconfiguration. RFC 2782 and
RFC 5321 say the targets of SRV and MX records must not be aliases.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 10 Apr 2013 22:31:24 +0000

On Wed, Apr 10, 2013 at 07:29:47PM +0100, Tony Finch wrote:

> record.

And even when configured to use the server hostname directly, if
that name is CNAME, using it as the base domain for TLSA records
opens a can of worms clearly described in 6698 to clarify the 
semantics of TLSA RRs in DNS:

	- Just because foo.example.com is a CNAME this implies nothing
 	  about _tcp.foo.example.com

and hence a confusing mess.  For which the "cure" (worse than the
disease) is SNI.  There is a better way:

	- Follow the CNAME (paying attention to DNSSEC validation)
	  if the final target host is secure, use that as the TLSA
	  base domain, otherwise no TLSA records found.

The result is remarkably clean, suddenly no confusion and no need
for SNI and the complex key management headaches it leads to.

> Also, client software can rely on standard resolver alias

At least for SMTP, this is a non-issue, Sendmail, Postfix, ...
all do explicit DNS lookups bypassing the system nsswitch-like
mechanisms, these drag in non-DNS sources of address information,
to which we agreed earlier TLSA records do not apply.  And MTAs
have for a long time needed to be able to be able to do CNAME
chasing.

Also there is no "directly" with say MX records.  To send mail to
gmail.com, an MTA must use the MX records.  There is no plausible
relevance for discussing "direct" delivery via
alt1.gmail-smtp-in.l.google.com:

	gmail.com.    IN  MX   5 gmail-smtp-in.l.google.com.
	gmail.com.    IN  MX  10 alt1.gmail-smtp-in.l.google.com.
	gmail.com.    IN  MX  20 alt2.gmail-smtp-in.l.google.com.
	gmail.com.    IN  MX  30 alt3.gmail-smtp-in.l.google.com.
	gmail.com.    IN  MX  40 alt4.gmail-smtp-in.l.google.com.

Yes, none of gmail.com's MX hosts are CNAMES, but this is not universal.

> RFC 5321 say the targets of SRV and MX records must not be aliases.

What's weird is mandating SNI, that turkey won't fly.  So if SRV
and MX RRs must not be aliases, we are free to do as we please when
they are CNAMEs anyway, right?  If so, we should do the sensible
thing and compute the underlying hostname.

Then for consistency (since with SMTP MX records are optional and
one can send email to [email-masked] when cname.example.com
is an alias for mail.example.com which only has an A record) it
should be correct to avoid the SNI mess and resolve these also.

Please take me seriously.  If the DANE WGs specificications are to
be used (as opposed to simply published and widely ignored) they
should whenever possible specify the most robust choice of mechanisms.
If the specification enshrines fragile behaviour, the specification
is wrong.

SNI is a work-around to problems with shared TLS hosting uner the
legacy PKI.  It is better than nothing, but it still does not scale,
DANE should obviate not enshrine SNI.

The SRV and SMTP specifications will be much robust if they define
the most robust (with respect to key-management) treatment of CNAME
records.  Considerations of how a client application chases CNAMEs
are far less important here, client applications already need to
make new DNS queries for TLSA RRs, the CNAME chasing is trivial,
while key management (the crux of what DANE is about) is hard.

-- 
	Viktor.

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 12 Apr 2013 12:15:08 +0200

> thus in case a target hostname in the SRV RR is a CNAME:

According to RFC 2782, the SRV target hostname MUST NOT be an alias (aka CNAME).

	jakob

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 12 Apr 2013 15:37:40 +0000

> According to RFC 2782, the SRV target hostname MUST NOT be an alias (aka CNAME).

Thanks, appreciated. I am aware of this for MX records, so I am
not surprised by similar treatment of SRV records.

Standards notwithstanding, sometimes it will be a CNAME in practice.
Are you saying that because CNAME-valued SRVs violate 2782, it
would be wrong for draft-ietf-dane-srv to define any particular
treatment for these?

If so, perhaps I'm free to do CNAME chasing or anything at all,
since this case lies outside the scope of the standards.  Given a
choice of failing, doing something painful like SNI, or chasing
the CNAME, Postfix will chase the CNAME.

I should note that with SMTP, a non-MX destination (A or AAAA only)
is per 5321 equivalent to an implicit MX, but its base is perhaps
the target of the CNAME (second paragraph of):

https://tools.ietf.org/html/rfc5321#section-5.1

   The lookup first attempts to locate an MX record associated with the
   name.  If a CNAME record is found, the resulting name is processed as
          --------------------------------------------------------------
   if it were the initial name.  If a non-existent domain error is
   ----------------------------
   returned, this situation MUST be reported as an error.  If a
   temporary error is returned, the message MUST be queued and retried
   later (see Section 4.5.4.1).  If an empty list of MXs is returned,
   the address is treated as if it was associated with an implicit MX
   RR, with a preference of 0, pointing to that host.  If MX records are
   present, but none of them are usable, or the implicit MX is unusable,
   this situation MUST be reported as an error.

My reading of this is that:

	example.com.	IN CNAME example.net.
	example.net.	IN MX	(NODATA)
	example.net.	IN A 192.0.2.1

is implicitly (initial name now example.net):

	example.net.	IN MX 0 example.net.

and that the relevant TLSA records for this case would be:

	_25._tcp.example.net. IN TLSA 3 1 1 ...

-- 
	Viktor.

---

From: Tony Finch <[email-masked]>
Date: Fri, 12 Apr 2013 17:11:53 +0100

> the CNAME, Postfix will chase the CNAME.

That would be wrong. The specification is quite clear that the query name
for the TLSA record is constructed from the target name in the SRV or MX
record. Whether the target is an alias or not is immaterial.

>    name.  If a CNAME record is found, the resulting name is processed as

Oh blimey. Thanks for pointing that out.

In this situation I think the right thing would be to look for the TLSA in
the same place as when connecting to a host, as in RFC 6698 section 3.
That is, just add _25._tcp to the start of the domain.

The reason I think this is right is that in the absence of MX records you
should get the same behaviour when you specify (per Sendmail and Postfix
notation) a relay host as "[hostname]" (i.e. without MX lookups) or as
"hostname" (i.e. with MX lookups).

Tony.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 12 Apr 2013 16:25:58 +0000

> record. Whether the target is an alias or not is immaterial.

It may be contrary to the current draft specification, but I am quite
sure that it is not "wrong", my contention is that either the
specification is wrong (if it is to be understood to say anything at
all about the illegal use of CNAMEs in SRV records) or it is simply
not pertinent since CNAMEs are illegal.

If you feel that the specification needs to addresses the CNAME
case, please make it handle key management in a sensible way (i.e.
by obviating the need for SNI, rather than further enshrining the
SNI work-around in new standards).

> "hostname" (i.e. with MX lookups).

I read 6698 section 3 as a warning about the perils of mixing TLSA
RRs and CNAMEs, not an imperative to use the left-side of a CNAME
as the base domain for TLSA.  DANE, properly defined, obviates the
need for SNI (an abominable work-around to support HTTPS virtual
hosting).

Therefore, even with explicit non-MX destinations:

    transport:
	example.com	smtp:[mail.example.com]

Given a DNSSEC-validated chain of CNAMEs from mail.example.com to
some underlying hostname, the base domain used by Postfix for TLSA
will be the target host of the CNAME chain.  If the CNAME chain is
NOT DNSSEC validated, Postfix will not look for TLSA RRs.

This behaviour is substantially more robust (is not predicated on
SNI and does not introduce a requirement for cross-organizational
transfer of key material and corresponding synchronization with
DNS changes).  Therefore, it is the right behaviour, and standards
that say otherwise need revising.

-- 
	Viktor.

---

From: Tony Finch <[email-masked]>
Date: Fri, 12 Apr 2013 18:11:50 +0100

> not pertinent since CNAMEs are illegal.

That part of the spec is carefully written so that it works the same way
whether you allow CNAMEs or not. My aim was to avoid arguments about
specifying behaviour in situations that violate other standards.

> SNI work-around in new standards).

You can't avoid the need for SNI by fiddling around with CNAMEs on the
target side of the SRV record, because SNI is used to deal with the
mismatch between the SRV query domain and target host name. It is possible
for server admins to avoid the need for SNI-based certificate selection if
they set things up the right way (and I need to explain that better in the
spec) but clients have to support SNI because they don't know enough about
the server setup.

> as the base domain for TLSA.

RFC 6698 section 3 doesn't say anything about CNAMEs: it says how to
construct a TLSA query name given a host name. The usual behaviour of
TLS clients is not to chase CNAME chains to canonicalize hostnames.

> NOT DNSSEC validated, Postfix will not look for TLSA RRs.

That disagrees with the behaviour described in RFC 6698 section A.2.

Tony.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 12 Apr 2013 19:55:59 +0000

> spec) but clients have to support SNI because they don't know enough about

If the SRV query domain is correctly specified, SNI is unnecessary.
The server's default certificate (used when the client sends no
SNI data) must either match the EE criteria from a "[13] x y"
association or must include a certificate signed by a TA which
names the underlying server.

If SMTP is to use DANE TLSA, the required mechanisms must be
operationally robust.  The robustness requirement precludes SNI,
since this involves synchronized key exchange and DNSSEC updates
between multiple parties.

> TLS clients is not to chase CNAME chains to canonicalize hostnames.

That is a legacy of the days before DNSSEC, when CNAME chasing was
subject to man-in-the-middle attacks.  So a web browser had no
choice but to use what the user typed.  With DNSSEC and DANE this
is no longer necessary.

> That disagrees with the behaviour described in RFC 6698 section A.2.

This thread is in essence a bug report for the specifications in
question, so the disagreement is not surprising.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 14 Apr 2013 16:58:18 +0000

> That is, just add _25._tcp to the start of the domain.

Well, 5321 tells us to pretend the domain has an implicit MX record:

	host. IN MX 0 host.

but CNAMEs are illegal on the right side of MX records, so logic dictates
that we must start with a non-CNAME host.

-- 
	Viktor.