On 5/1/20 12:27 PM, Ned Freed wrote:
IMO RFC7525 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.
Whether or not to ban SSL v2 and v3 is a tough call, but not for the
reasons
given in RFC 7525. Yes, these are weak mechanisms, but in the absence
of other
considerations weak is better than no security at all.
However, because of the way the negotations work supporting all of
these stuff
simultaneously has proven to be difficult to get right. The fact that
these old
versions can cause interop failures with later versions is arguably
sufficient
cause for a MUST NOT.
If we can enumerate those specific cases, and explain why they're MUST
NOTs, that seems like it would be a Good Thing.
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.
Shorter version: Once again the IETF is letting the best be the enemy
of the
good.
I have often observed tendencies in thinking about security that seem to
result in poor choices.
One is to assume that every application acts like the web, for example:
A human interacting with a UI on the client side, who is in the loop,
and who can react to security negotiation failures and make informed
decisions.
Another is to treat "secure" as a binary value, without even considering
that different users quite reasonably have different threat models.
(Anytime someone whom I don't have calibrated claims something is
"secure", a red flag goes up. At that point I generally ask them to
tell me what threats they have identified and what they've done to
address them. Then I'll have a better idea of what they mean. A few
people can answer such questions, but most go into infinite page fault,
or worse, just start trying to pile on more BS. And then I know to
treat the system as insecure.)
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.
AFAICT the draft hasn't been updated beyond what RFC 7525 says, so I'm
going to wait and see what those updates say before I decide if I can
support the change.
Yeah, I'm not entirely clear on the right way to go about this: is it to
adopt the document with the understanding that significant changes are
expected, or is it better to start with a new draft?
Keith
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
