Re: [TLS] Fwd: Re: AD review of draft-ietf-tls-dtls-connection-id-07

[Achim Kraus <[e-mail]>]

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
>