On 2/17/15 4:33 PM, Yaron Sheffer wrote:
On the other hand, if we're
expecting new or updated application protocol specs to conform to
or take
into account the recommendations in this document, I think that
should be
made more clear.
Given that other folks have been confused on this point, I tend to
agree.
I propose that we add the following text after the bullet points at
the start of Section 5 ("Applicability Statement"):
This document does not modify various details (e.g., cipher suites)
prescribed by application protocols that use TLS or DTLS. If the
implementation and deployment community that uses such an application
protocol wishes to modernize its usage of TLS or DTLS to be
consistent with the best practices recommended here, it needs to
publish a document that explicitly updates the existing application
protocol definition. One example of such a document is
[I-D.ietf-uta-xmpp].
Thanks Peter. I think this is good, but does not get to Pete’s point
about new protocols. And in that case if the expectation is that new
protocols will conform to this BCP’s recommendations, that should be
made explicit I think.
Right, that is a somewhat separate issue from the paragraph above (which
should say "prescribed by existing application protocols"). We also had
an ordering issue with the email threads here, and I agree that we need
to have some text about new protocols, too. I'll propose something
separately about those.
The text above also slightly skirts the case where an existing
protocol is being updated for some other reason besides modernizing
its TLS/DTLS usage. So if the Foo protocol required support for weaker
ciphers than what the BCP requires/recommends, and someone writes
Foobis for the purpose of making non-TLS-related updates, do we expect
Foobis to conform to the BCP? Or continue to require support for
weaker ciphers for interoperability purposes? Or both? Or leave it up
to the consensus at the time of Foobis publication? Would be good to
clarify that case further I think.
In fact I think the text addresses exactly this case, by making the
update conditional on "the community... wishing to modernize [the
protocol's] usage of TLS". In other words, what works for one community
may not work for another, e.g. for reasons of interoperability.
I agree with Yaron here. One example that came up during WG discussion
of this document was certain IoT protocols, since the relevant devices
might not have support for all of the necessary algorithms. Instead of
building in an explicit carve-out for those protocols, we felt it was
better for those communities to decide how they wanted to proceed.
Peter
--
Peter Saint-Andre
https://andyet.com/
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
