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
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
