Hi Mike,
> in C:
>
> if (complex_value_a = complex_value_b) {
> // we're in trouble....
> }
That's a pitfall of C ('=' is not '=='). You will be almost in trouble,
if the complex value is not 0.
But the discussion here is more about how often somethings should be
adapted again and again. The point from Ben are all very valid, but they
should have been raised at least 1 year ago. Now, the point is, if
"cryptographic hygiene" without "actual threat" (at least, this was not
explained) should modify the MAC again. If so, the question may be, when
this changes will end.
best regards
Achim Kraus
Am 10.10.20 um 19:29 schrieb Michael D'Errico:
On Fri, Oct 9, 2020, at 17:22, Benjamin Kaduk wrote:
[...] The behavior we should demand from our cryptographic
constructions is that the cryptography itself correctly returns
"valid" or "invalid" based on the input message, provided that
the application inputs the correct key material. (It should also
return "invalid" if incorrect key material is supplied, of course.)
The ability to produce two different messages for which the
cryptography returns "valid" violates this principle; even if we
do not see an obvious path by which a reasonable application
might supply those inputs to the cryptographic code, it is still
a flawed construction.
Hi,
I'd like clarification about this point, where the cryptography
should return values of "valid" or "invalid". This is a general
question, not specifically about this draft. (Please read at
least the next 2 paragraphs.)
I remember a long time ago, it may have been the renegotiation
info extension, where there was a lot of calculation being done,
there were two complicated values each side had to compute.
If they were equal, then everything was fine and the handshake
could proceed. If not, there was an insecure renegotiation
happening. (Or maybe it was the downgrade protection RFC,
I can't remember now.) But if the values were not equal, then
something bad was happening and the handshake should not
proceed.
The problem both Martin Rex and I discovered at nearly the
same time (posts to the mailing list within minutes of each
other) was that both sides could go through all the motions
faithfully calculating all of the values, correctly, and then
forget to compare them to see if the values were actually
the same. I noticed this because I wrote the code, and it
seemed like an easy thing to overlook.
I remember suggesting that we somehow incorporate the
calculated values into the derivation of the record layer keys
so the MAC would fail, or maybe into the Finished message
calculation so (if you remember to check that?) a failure is
noticed later. This suggestion was shot down by the author
unilaterally for what I perceived at the time to be petty
reasons.
I still believe that (D)TLS security should not rely on the
implementer to check whether two values are equal. This
is too easy to forget to do. Or you could do this in C:
if (complex_value_a = complex_value_b) {
// we're in trouble....
}
I have not looked at the TLS 1.3 draft beyond the hour or so
I've put in so far to see whether this reliance on checking is
in there too. I've also not checked whether the security
proof I was referred to has any games where the implementer
forgot to compare values. Or a game where everybody made
the same error and nobody noticed (forgetting to put the
HelloRetryRequest into the Tramscript-Hash for example).
Mike
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
