On 7/19/22 10:44 AM, Peter Saint-Andre wrote:
One more small note below...
On 7/19/22 10:30 AM, Rob Wilton (rwilton) wrote:
<snip/>
You may want to consider whether it is worth making it clearer, either
in the titles or the first intro paragraph, in section of 3.1.1/3.1.2
that the protocol version requirements are specifically about
implementations, and deployments are allowed/encouraged to restrict
deployments to later TLS versions where reasonable/appropriate.
Otherwise, I suspect that readers may well have both implementations
and deployments in their head when they read this section.
Good point. I'll look at the entire document again from this perspective
and see where we might add some clarifying text.
I found a good place for some amplifying text, at the end of the
following paragraph in the introduction.
OLD
These are minimum recommendations for the use of TLS in the vast
majority of implementation and deployment scenarios, with the
exception of unauthenticated TLS (see Section 5). Other
specifications that reference this document can have stricter
requirements related to one or more aspects of the protocol, based on
their particular circumstances (e.g., for use with a particular
application protocol); when that is the case, implementers are
advised to adhere to those stricter requirements. Furthermore, this
document provides a floor, not a ceiling, so stronger options are
always allowed (e.g., depending on differing evaluations of the
importance of cryptographic strength vs. computational load).
NEW
These are minimum recommendations for the use of TLS in the vast
majority of implementation and deployment scenarios, with the
exception of unauthenticated TLS (see Section 5). Other
specifications that reference this document can have stricter
requirements related to one or more aspects of the protocol, based on
their particular circumstances (e.g., for use with a particular
application protocol); when that is the case, implementers are
advised to adhere to those stricter requirements. Furthermore, this
document provides a floor, not a ceiling: where feasible,
administrators of services are encouraged to go beyond the minimum
support available in implementations to provide the strongest
security possible. For example, based on knowledge about the deployed
base for an existing application protocol and a cost-benefit analysis
regarding cryptographic strength vs. computational load, a given
service provider might decide to disable TLS 1.2 entirely and offer
only TLS 1.3.
See https://github.com/yaronf/I-D/pull/469/files
Peter
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
