On Fri, Apr 12, 2013 at 06:11:50PM +0100, Tony Finch wrote:
> > 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).
>
> 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.
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.
> 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.
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.
> > 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.
>
> 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.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
