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

[Keith Moore <[e-mail]>]

On 5/1/20 5:02 PM, Peter Saint-Andre wrote:

> On 4/30/20 8:59 PM, Keith Moore wrote:
>> IMO RFC7525
> That ship sailed in 2015.

IETF isn't bound by /stare decisis/.

> I don't think we ever said anything to the contrary. BCP does stand for
> *best* current practice, after all.

If BCP really means Best /Current/ Practice, and we have a better 
understanding (perhaps informed by experience with existing documents) 
of what best practice is today, than we did in 2015, we should be able 
to say so.

> 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".

I am interested in what text best informs protocol designers and 
implementors' decisions.   Particularly for a document with such broad 
scope, I suspect the words "evil" and "violation" have narrow applicability.

>> 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?
What is our goal anyway?  Is it to provide good advice to protocol 
designers and implementors, or is it to expect them to read between the 
lines and "just know" when to bend or break those rules? Serious question.
>> 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.

Stated that way, I don't think it is a very subtle distinction.

More generally, what I've realized after several discussions about use 
of TLS in specific protocols is that different protocols necessarily use 
TLS in subtly different ways, with different assumptions about threat 
models.   Different protocols also have different backward compatibility 
issues, different means of error recovery and reporting.   For email, 
for example, I found that message relaying and UA-MSP interactions 
required very different advice even though both relaying and message 
submission use very similar protocols.   I tried to write text that 
covered both and it just didn't work.

Granted it's easy to drown people with details, but it's also easy to 
provide advice that is so generic that it's poor advice for very many 
use cases.

>> 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.

Yes, but when the document says "don't use TLS x.y"  and that is applied 
to a protocol for which the likely fallback is cleartext, maybe it's not 
describing best current practice.

>>    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.
Yes.   what's the best way to capture that so that implementors are well 
advised?
>> 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?
No, I think that some change is needed.   The question in my mind is 
whether to start with this draft or with a clean slate.   I haven't 
formed an opinion about that yet.

Keith