On 2/17/15 5:00 PM, Alissa Cooper wrote:
On Feb 17, 2015, at 3:53 PM, Peter Saint-Andre - &yet <pe...@andyet.net> wrote:
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.
Actually, we're not saying anything about the reasons why a community
might be modernizing its core specifications, our statement was about
wishing to modernize the security profile. There are no protocol police,
but if I were still an AD I'd strongly encourage any community working
on a bis effort for other reasons to apply these best practice
recommendations while they're at it. :-)
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.
Ok, fair enough. I would personally find it a little better to make that more
explicit in the document, but will not quibble over it.
Here is updated, proposed text for Section 5...
###
5. Applicability Statement
The recommendations of this document primarily apply to the
deployment of application layer services that are most commonly used
with TLS and DTLS on the Internet today. Examples include, but are
not limited to:
o Operators of web services that wish to protect HTTP traffic with
TLS.
o Operators of email services who wish to protect IMAP, POP3, or
SMTP traffic with TLS.
o Operators of instant-messaging services who wish to protect XMPP
or IRC traffic with TLS.
o Operators of realtime media services who wish to protect SRTP
traffic with DTLS.
This document does not modify the implementation and deployment
recommendations (e.g., mandatory-to-implement cipher suites)
prescribed by existing application protocols that employ TLS or DTLS.
If the 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]).
Designers of new application protocols developed through the Internet
Standards Process are expected to conform to the best practices
recommended here, unless they provide documentation of compelling
reasons that would prevent such conformance (e.g., widespread
deployment on constrained devices that lack support for the necessary
algorithms).
###
I somewhat fear that we're opening a can of worms with the final
paragraph, but so be it.
Peter
--
Peter Saint-Andre
https://andyet.com/
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
