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
