On Wed, Apr 10, 2013 at 07:29:47PM +0100, Tony Finch wrote:
> Viktor Dukhovni <[email protected]> wrote:
>
> > 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.
>
> 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.
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
> processing, rather than having its own duplicate alias handling logic.
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.
> 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.
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 protected] 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.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
