Hi Viktor, Meta-question: was this something the wg discussed or did they just follow your lead? If the former, that's grand and I'll stop when shown the archive URL for the thread (I do think I recall similar discussion, but not sure). If not, then let's use this thread to check - so if someone disagrees with Viktor and hasn't sent mail on this previously (if it was discussed already please don't re-raise stuff) it'd be good to hear about it now.
The reason I'm asking is the obvious one - this could be a surprise - if the user agent for some protocol shows foo.example.com (or has that in a configuration) but via DNSSEC/DANE/SRV we end up with a TLS session with bar.example.com and if we say that that is ok, then we're causing potential developer/deployer/user surprise, and also setting an upper bound for the level of TLS security that is only as good as domain-validated. That is a defensible position (esp for the DANE wg!) but might surprise some application developers etc. One other question: you mentioned SNI below. Is that very relevant here, given we're not talking about the web (that won't use SRV) and afaik most use of SNI is for the web. So, for which non-web applications is SNI sufficiently important to justify this (potential) level of developer surprise? Thanks, S. On 02/04/15 02:21, Viktor Dukhovni wrote: > 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. > _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
