Re: [TLS] CCS and key reset and renegotiation

[Jeffrey Walton <[e-mail]>]

On Thu, Jun 5, 2014 at 11:25 AM, Watson Ladd <[e-mail]> wrote:
>
> On Jun 5, 2014 8:12 AM, "Salz, Rich" <[e-mail]> wrote:
>>
>> Have folks seen this yet?
>>
>> http://ccsinjection.lepidum.co.jp/blog/2014-06-05/CCS-Injection-en/index.html
>>
>> I think it adds weight to my concern about using ChangeCipherSpec to do
>> key reset.  I still prefer the trade-offs of having a “slow the TLS but keep
>> the TCP layer open” and starting over.  Much simpler to prove it’s correct.
>
> What can change when that happens? Furthermore, rekeying is a matter of
> getting more PRF output: how does that introduce security concerns.
>
> I don't see why the incompetence of implementors should govern our
> decisions. If something cannot be implemented correctly it must be removed,
> but why is rekeying such a thing?

I'm reading two points in that last statement: first, some
implementers are incompetent; and second, the TLS WG does not make bad
decisions.

For the first point, I think its too easy to blame an implementer.
Perhaps there's a gap that needs to be addressed for implementers. Has
the TLS WG considered providing a comprehensive test framework to
ensure their designs are realized in an implementation?

The working group is in a unique position to offer the best and most
complete set of tests. They are in that position because they
understand what they want, they know why they want it, and they know
what they rejected. So a testing framework with positive and negative
self tests would probably be very helpful to implementers. And that's
all implementers, and not just the ones that are labeled incompetent.

Plus, the implementers should *NOT* be asked to create their own test
cases. That's simply bad engineering, and the problem has been known
for years. Gutmann and Anderson talk about in their respective books
on security and engineering. Those books are 10 or 15 years old, so
its not bleeding edge knowledge.

For the second point, Authenticate-then-Encrypt has proven to be
problematic for years. I would not blame the implementers or call them
incompetent for subtle problems in the construction. Especially when
it took a formal analysis by practicing cryptographers to uncover and
present the problems [0].

The problems with Authenticate-then-Encrypt have been known since at
least 2000 [0]. I question why the folks responsible for the standard
did not acknowledge the problem and provide safer or better
alternatives more expediaently. Nearly ten [1] or fifteen years [2] to
address the [re-occuring] problem seems a bit excessive to me.

The folks responsible for the standard are collectively smarter people
than the folks implementing the standard and using the standard. We
(the dumb users) need the group to act expediently when gaps are
uncovered.

For completeness, CompSci 101 mistakes are an implementers problem.

-----

[0] H. Krawczyk. The Order of Encryption and Authentication for
Protecting Communications,
http://www.iacr.org/archive/crypto2001/21390309.pdf
[1] J. Salowey, et al. AES Galois Counter Mode (GCM) Cipher Suites for
TLS, http://tools.ietf.org/html/rfc5288
[2] P. Gutmann. Encrypt-then-MAC for TLS,
http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-00