It is important to note that many (though not all) of the original proponents only seemed to care about http, where opportunistic tls never caught on.
Even with ipp, where existing software actually support it, the preference seems to be to use ipps:// (on the same port as ipp://) or https:// (on port 443) uris over using rfc2817 tls upgrade. But even so there were voices hoping for a mechanism to stipulate that tls SHOULD or even MUST be used for a given name+port. My impression at the time was that the consensus not to include language to that effect it rfc 6698 was not consensus that such a mechanism was undesireable, but just that it wasn’t generally enough wanted to warrant making it a part of the base specification rather than part of some more specific followup specification. Clearly there needs to be a way to say ‘Use TLS when contacting this server, even though the protocol takes extra steps to do so.’ The existence of a relevant, secure TLSA is not an unreasonable way for specific tls communities to do so. Even though the broader tls community may not need (or want) such a mechanism for their servers. Not only do I encourage rfc publication of some mix of the dane-smtp- with-dane and dane-srv drafts, but I do not agree that either is contrary to the consensus for publishing what is now rfc 6698. Once the details are worked out -- progress looks good -- that also applies to the smime and openpgp drafts. The only real question is whether dane-srv and dane-smtp-with-dane should be published as two rfcs or combined into one? (I’m leaning towards two, numerically adjacent.) -JimC -- James Cloos <[email protected]> OpenPGP: 1024D/ED7DAEA6
signature.asc
Description: PGP signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
