Re: [Uta] Robert Wilton's Discuss on draft-ietf-uta-rfc7525bis-09: (with DISCUSS and COMMENT)

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Peter,

Thanks.  Yes, I think that your proposed text would be a helpful clarification.

Regards,
Rob


> -----Original Message-----
> From: Peter Saint-Andre <[e-mail]>
> Sent: 19 July 2022 18:05
> To: Rob Wilton (rwilton) <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: Robert Wilton's Discuss on draft-ietf-uta-rfc7525bis-09: (with
> DISCUSS and COMMENT)
> 
> 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