On Thu, Apr 02, 2015 at 01:16:06AM +0100, Stephen Farrell wrote:
> Appendix B: I'm not sure there's really going to be IETF
> consensus that it's better to have a TLS server cert for the
> hostname and not the service name.
The rationale in appendix B of SRV leaves what I think is the most
important reason for preferring the server hostname:
* That's what clients MUST send in the SNI extension!
DNSSEC/DANE authenticate the "redirect" from the service domain to
the target host (which may well in a hosting provider domain) and
the TLSA record promising TLS support and providing the authentication
material is associated with *that* name and not the service domain.
; hosted domain zone
_imap._tcp.example.com IN SRV 0 0 143 mail.example.net.
; hosting provider zone
_143._tcp.mail.example.net. IN TLSA 2 0 1 <digest>
The party promising TLS support is the provider, not the hosted
domain. And that's whose certificate the TLSA record is expected
to match.
Support for the service domain in the certificate is a concession
to interoperability with legacy or mixed deployments, where some
clients are still doing non-DANE PKIX. Though per Alexey's most
recent UTA draft, they should some day primarily be looking for
srvNAME altnames, rather than domain names in the certificate.
> If you can point at where
> it's recorded that the WG reached that consensus that may save
> us time later.
It is fundamental to the DANE TLSA model, that the certificate is
associated with the TLSA base domain. There really is no other
way to do it, without breaking the indirection, and forcing hosted
clients to publish TLSA RRs for the provider's servers, which
totally stinks because the coordination is unworkable.
> While this
> comment is about an appendix I suspect that if the wg change
> it's mind here, it'd also change other bits of the draft.
No change of mind is likely here, I for one, would oppose this
rather strongly.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
