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

[Keith Moore <[e-mail]>]

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