On Jun 26, 2014, at 3:26 PM, Viktor Dukhovni <[email protected]> wrote:
> 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? Sure. However, when someone publishes a -00, and during the call for adoption says "and I intend to add a major change that wasn't even hinted at in the -00", I think it is worth the WG to pause a bit. > 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... Absolutely. However, if you're talking about changing the lookup mechanism, then it is no longer a simple change to the the base spec. Thus, my proposal to collect all non-TLS use of TLSA record in a different document. > 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. RFC 6698 already excludes non-TLS use throughout the document by talking about TLS as the only applicable protocol. > 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. I'm with you there up to the last bit. It will take much longer to come to consensus on a catch-all document than it will one that, like draft-gilmore-dane-rawkeys-00, is just about allowing raw keys for TLSA for TLS. --Paul Hoffman _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
