On Thu, Jun 26, 2014 at 07:22:54AM +0100, Paul Hoffman wrote:
> Having read the author's message to the mailing list that he
> intends this draft to update RFC 6698 to apply to unnamed protocols,
> not just TLS, I rescind my support for the draft. I still fully
> support updating 6698 to cover "keying material" instead of
> "certificates" in the manner discussed in the -00 draft. I would
> also support a different draft that says "the TLSA record can be
> used in the following protocols in the following fashions".
Well, this is not last call, rather a call for adoption. Perhaps
we can come to rough consensus on this issue after the draft is
adopted?
I can, for example, see using TLSA RRDATA (with a different lookup
key than _port._proto) for cross-realm kerberos without prior manual
keying. Nico may publish a draft for that at some point...
Now to Paul's point, there will of course need to be a draft
specifying any such use-case. However, there is perhaps little
harm in allowing the TLSA RRDATA definition in 6698 to not explicitly
exclude other protocols.
To me the part that binds TLSA RRs to transport security is
_port._proto. The queryname for TLSA RRset is a transport
end-point, hence we're doing transport security.
If instead the DNS lookup were something like:
_pkcross.athena.mit.edu IN TLSA ?
then we're not doing transport security. To Paul's point however,
it is a bit less obvious that the various per-protocol specs will
always keep out of each other's way and avoid lookup key collisions
for unrelated services if the RRtype TLSA is SHARED, and only the
various _mumble prefixes differentiate distinct use-cases.
On balance I think it is reasonable to use TLSA RRDATA in more
situations, and support adoption of the draft, which will presumably
evolve to match rough consensus.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
