Subject: Re: [TLS] Verify data in the RI extension?

From: "Blumenthal, Uri - 0662 - MITLL" <[email-masked]>
Date: Fri, 27 Nov 2009 08:42:05 -0500

Stefan ignited my curiosity.

What is the reason we're exchanging the verify_data value?

If only to "save" the old-style calculation - I vote against it, for the reasons (security) that Stefan outlined. And we're making a big change anyway...

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Sent: Fri Nov 27 05:02:44 2009
Subject: Re: [TLS] Verify data in the RI extension?

Pasi,

On 09-11-27 10:16 AM, "[email-masked]" <[email-masked]> wrote:

> Stefan Santesson wrote:
> 
>> To me it seems obvious that the best security design is to NOT
>> exchange this data if the objective is to verify that the parties
>> already hold the data.
>> 
>> It's feels like "I want proof that you hold this value, so I'm going
>> to send it to you".
> 
> <not wearing AD hat>
> 
> In many cases (such as cipher suites with NULL encryption, or some
> apps that use channel bindings) the verify_data values are already
> public. So the objective is *NOT* to prove that "I know this value";
> the objective is to verify that both ends have the same value.
> 

This is what I meant by "holding the value". The evidence thereof is
degraded if you exchange the value instead of just making sure that, as you
say, "both ends have the same value".

> <wearing AD hat>
> 
> About the obviousness of the best security design, it's safe to say
> that when it comes to design style and preferences, people often
> disagree. I think we're reaching "good enough" here -- if people have
> serious concerns that the latest draft does not work, those are
> important, but as AD, I'm not going to give much weight to "it could
> be nicer" type of arguments in a situation where timely publication
> is important. 
> 

Well, I don't bring this up just because it would be a bit nicer.

I bring this up since NOT exchanging verify_data seems to offer:

1) better security 
2) simplicity - allows the signaling to be identical for all handshake
exchanges regardless of protocol version.
3) better compatibility/easier migration towards future versions of TLS

Sending the verify_data seems to offer no advantage other than to preserve
the old (and agreed to vulnerable) Finished calculation instead of fixing
it.

I just genuinely interested to understand why we would choose the less
secure and more complex option, alternatively whether I got everything
totally wrong. 

/Stefan

> Best regards,
> Pasi

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: "Blumenthal, Uri - 0662 - MITLL" <[email-masked]>
Date: Fri, 27 Nov 2009 11:36:12 -0500

"Just say no!"

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Sent: Fri Nov 27 11:17:24 2009
Subject: Re: [TLS] Verify data in the RI extension?

At Fri, 27 Nov 2009 16:27:03 +0100 (MET),
Martin Rex wrote:
> 
> Eric Rescorla wrote:
> > 
> > I also share David Hopwood's concern about ambiguity in the handshake
> > hashes stream created by having data which is not properly formatted
> > injected into the hash
> > (http://www.ietf.org/mail-archive/web/tls/current/msg04857.html),
> > so I don't think the particular approach in Martin's draft is
> > really satisfactory.
> 
> That problem can be trivially fixed.
> 
> We just memorize the non-encrypted Client.Finished and Server.Finished
> handshake messages in full, rather then just the contained verify_data.

Woah, that's scary....

We're going to take the exact messages that previously appeared on the
wire and inject them into the handshake hashes in order to *reduce*
ambiguity in the hash input stream? I mean, maybe that's OK, but it
sure isn't obviously OK.

-Ekr