Re: [Uta] Adoption call for draft-sheffer-uta-rfc7525bis-00

[Peter Saint-Andre <[e-mail]>]

On 4/30/20 8:59 PM, Keith Moore wrote:
> IMO RFC7525 

That ship sailed in 2015.

> and this new draft both suffer from dubious assumptions and
> make poor recommendations because of those assumptions.  In particular,
> there are many cases for which using an old version of TLS is suboptimal
> and it shouldn't be considered as secure, but it may still be better
> than deprecating old versions of TLS that might be the only ones
> supported by the peer.

I don't think we ever said anything to the contrary. BCP does stand for
*best* current practice, after all. There are many reasons why a piece
of software or hardware can't do what's currently best, but that doesn't
make it evil or in "violation".

> People do not always have the luxury of upgrading their clients and
> servers to versions that support the recent TLS.    Some legacy hardware
> has firmware that cannot be upgraded because no upgrades are
> available.   Service providers do not always have the leverage to insist
> that their customers upgrade, or the luxury of abandoning customers. etc.

For sure.

> I therefore find it difficult to make good advice of the form "don't use
> TLS version x.y" that is appropriate across all applications and all
> usage scenarios. 

Does a BCP necessarily apply to all applications and all usage
scenarios? That strikes me as an impossible goal. Am I missing something?

> Again, there's an important difference between "don't
> use TLS x.y" and "don't consider TLS x.y secure".

That's a subtlety which might be lost on the intended audience for this
document.

> I also think it's odd that there are recommendations like this that say
> "don't support TLS x.y" but say nothing about not supporting cleartext
> for protocols that still have a cleartext mode. 

The title of RFC 7525 is "Recommendations for Secure Use of TLS and
DTLS" - not "Recommendations for Secure Use of Internet Protocols". This
document assumes that you're using TLS/DTLS and provides guidelines for
how to do so most (or more) securely while striking an appropriate
balance between aspiration and reality.

>  Even SSL 1.0 is
> probably better than cleartext (at least from a security perspective, if
> not from a support burden perspective) as long as it's not trusted to be
> secure.

Yes, "as long as". There's the rub.

> So in summary, either I don't support adoption of this draft, or I
> support adoption of this draft only to the extent that it can be
> significantly changed.

Are you suggesting that it's better to stick with RFC 7525 and not
update it? Or even that the IETF should not have published a BCP on this
topic in the first place? You're welcome to submit an I-D proposing that
the IETF change RFC 7525 to Historic.

Peter