On Jun 1, 2012, at 8:05 PM, Matt McCutchen wrote:
I thought (and hoped) that TLSA was a generic protocol for
authenticating a TLS service at a given (DNS name, transport, port),
nothing more. I didn't realize that subsequent documents would attach
other semantics to TLSA RRsets. Nothing in the DANE doc anticipates
this. (The clause, "Unless there is a protocol-specific specification
that is different than this one", appears to me to refer to putting TLSA
RRsets at a different owner name, not giving them different semantics.)
I would oppose doing this, but it looks like I'm outvoted.
It was discussed on the DANE mailing list off and on over time, particularly
with respect to SRV-using protocols. You may disagree with it and hope for
different, but it should not be a surprise to you. We all know that a
TLS-on-defined-port protocol is not the same as a TLS-after-upgrade protocol
when the TLS handshake fails, and DANE by design gives a different way for the
TLS handshake to fail.
I think HASTLS might be a good idea, but the IETF still needs to have
the discussion of layering of these types of announcements.
I think IETF should have that discussion before the WG commits to Tony's
proposal for SMTP.
This draft is a great forcing function for the discussion. However, I will be
shocked if the discussion comes to a fixed result any time soon.
This approach is not going to work.
It will work fine for everyone who doesn't do the "cover every port
and assume that no future protocol will ever define how specific
applications will use TLSA".
It's true that there was no strong support for ensuring that covering
every port works.
s/no strong support/no noticeable support/
Though, if we intend to break it, section "A.2.1.3.
Provisioning TLSA Records with Wildcards" of the DANE doc should be
updated.
Disagree. The text in A.2.1.3 is still correct: it's only your interpretation
of "if the port is covered, it must offer TLS" that is wrong.
It's also true that I can't just expect the standard to support the
features I want without slogging through the process of building
consensus. For now, I can have fun deploying records with the
private-use certificate usage and implementing them in my client.
By all means let the mailing list know your experiences with that deployment.
If DANE is anything like DNSSEC, we have muffed and understated many important
features that will only be found by interesting deployment.
--Paul Hoffman