Subject: Re: [saag] getting rid of fairly old stuff (was: Re: POODLE avant le chein)

From: Peter Gutmann <[email-masked]>
Date: Thu, 16 Oct 2014 08:28:27 +0000

Stephen Farrell <[email-masked]> writes:

>And just to clarify, my question isn't really about TLS, but about whether
>there's an IETF thing to be done here that might help. (And the answer for
>now is I'm not sure.)

I realise I'm slightly biased on this issue since I'm the author of the RFC,
but getting RFC 7366, "Encrypt-then-MAC for Transport Layer Security (TLS) and
Datagram Transport Layer Security (DTLS)", adopted as a matter of priority
would by a good start, that'd make 10-15 years of these attacks go away pretty
quickly.

Peter.

---

From: Jeffrey Walton <[email-masked]>
Date: Thu, 16 Oct 2014 10:42:45 -0400

> would by a good start, that'd make 10-15 years of these attacks go away pretty

+1

---

From: Ira McDonald <[email-masked]>
Date: Thu, 16 Oct 2014 11:12:42 -0400

Hi,

+1

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Thu, Oct 16, 2014 at 10:42 AM, Jeffrey Walton <[email-masked]> wrote:

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

---

From: ianG <[email-masked]>
Date: Thu, 16 Oct 2014 17:50:21 +0100

> would by a good start, that'd make 10-15 years of these attacks go away pretty

quote:

   The use of extensions precludes use with SSL 3.0, but then it's
   likely that anything still using that protocol, which is nearly two
   decades old, will be vulnerable to any number of other attacks
   anyway, so there seems little point in bending over backwards to
   accommodate SSL 3.0.

You're showing those unfortunate biases again, Peter!

iang

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 29 Oct 2014 09:24:36 -0400

> would by a good start, that'd make 10-15 years of these attacks go away pretty

What the draft does not state is what the security concerns are. And
this worries me because I remember that when MAC-then-Encrypt was
selected it was because people suggested there were vague security
concerns about doing the reverse.

Are we really getting more security or are we just swapping one set of
issues for another?

---

From: Watson Ladd <[email-masked]>
Date: Wed, 29 Oct 2014 06:45:42 -0700

> concerns about doing the reverse.

They were wrong: Encrypt then MAC was always clearly satisfying the
correct security definition, to the point where
draft-rogaway-ipsec-comments
in 1995 mentions this as a major mistake. You can read the comments
here http://web.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt.

(Of course, the IETF has gone and made the archival version vanish in
a maze of broken links)

> Are we really getting more security or are we just swapping one set of

Read "Generic Composition Revisited" (Rogaway,Shrimpton,Namprempre,
available from https://eprint.iacr.org/2014/206.pdf)

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 29 Oct 2014 16:02:49 +0100

> here http://web.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt.

That's an interesting story, so I take the bite and continue it a bit.
At the time Rogaway send these comments other cryptographers were
advising otherwise. For example Ferguson and Schneier and  in their "A
Cryptographic Evaluation of IPsec" argued for the 'The Horton
principle', i.e. "Authentication should thus be applied to the
plaintext (as it is in SSL [FKK96]), and not to the ciphertext.".

Moreover, few years later Krawczyk in the "The Order of Encryption and
Authentication for Protecting Communications (or: How Secure Is SSL?)"
proved that AtE is as good construction for practical reasons, and one
shouldn't bother switching (that was also his advice to the WG chair
at the moment if I remember well). What he missed though was that TLS
was not doing AtE the way he assumed. That was noticed by Kenny
Paterson who published "Tag Size Does Matter: Attacks and Proofs for
the TLS Record Protocol", and differentiated between two AtE variants
the: "Encode-then-MAC-then-Encrypt"  (EME the variant refered to as
AtE by Krawczyk) and "MAC-then-Encode-then-Encrypt" (MEE - the TLS
variant). The story after that goes with MEE being broken for
practical applications.

So indeed, some cryptographers had made an argument against AtE, and
based on results (the variant of AtE used in TLS is broken), they were
correct. Unfortunately "correctness", can only be said today that we
know that the MEE variant of AtE is broken. One cannot still argue for
the EME variant of AtE (which is proven secure by Krawczyk) vs the
EtA.

>> Are we really getting more security or are we just swapping one set of issues for another?

That's a nice question with no easy answer. Of course once you fix a
known weak link, you get no guarantees about any other possible weak
links. In that particular case, the encryption part is fixed, at the
cost of the authentication part being in the clear. In theory it is ok
as long as the MAC algorithm is considered secure. In practice we have
no experience on what could happen when a MAC like HMAC-MD5 is broken.

regards,
Nikos

---

From: Watson Ladd <[email-masked]>
Date: Wed, 29 Oct 2014 08:42:42 -0700

> plaintext (as it is in SSL [FKK96]), and not to the ciphertext.".

No, they merely stated the principal, without looking at the
definitions and seeing which way works. Rogaway's statement that the
security was open was true. In 2000 it would be shown by Bellare and
Namprempre that MAC then Encrypt with randomized schemes was not
generically secure: one could provide a MAC and encryption scheme that
wouldn't work when composed one way.

> variant). The story after that goes with MEE being broken for

The Krawczyk paper appeared in the same year as the Vaudenay padding
attack oracle. I believe they were in the same volume of Eurocrypt
proceedings, but will have to look further to confirm. Furthermore, in
the ePrint version we find of Krawczyk we find.
"However, we note the fragility of this last statement: very simple
(seemingly innocuous) changes to the encryption function, including
changes that do not influence the secrecy protection provided by the
encryption when considered as a stand-alone primitive, can be fatal
for the security of the
implemented channels." This remark may have been added later, but
certainly not much more recently.

By 2003, it was clear that practical attacks on the TLS construction
existed (not just due to Paterson: timing attacks are due to several
different authors in addition, some of whom are cited in the TLS 1.1
RFC), and so TLS 1.1 gave advice on not leaking information through
timing channels, by reducing their size. However, the assumption that
this was sufficient was just wrong, and it wasn't noticed until Lucky
13, almost a decade later.

But all of this applies only to TLS: OpenPGP and S/MIME never even
tried to provide a composition of encrypt and MAC, and SSH also got it
wrong. The knowledge of these attacks diffused very slowly through
IETF standards. Even the bodo-cbc attack textfile didn't provoke
action by the TLS WG: completed in 2004, one can probably still read
it today and extract attacks.

TLS 1.0 also got CBC encryption wrong, hence BEAST. That was published
in 2004 by Bard. It shouldn't take a live demo for us to fix problems.

This also isn't the only broken old thing. PKCS 1.5 encryption
survives, as does PKCS 1.5 signatures. We don't know how to attack the
signatures, but we do know that implementations frequently get
verification wrong by parsing the result of a decryption, rather than
doing the comparison properly. And the encryption is very badly
weakened by Bleichenbacher style attacks.

These attacks, as well as the better replacements, have been around
for quite some time now, in some cases 20 or 19 years. But we still
haven't fixed the root problems, and instead act surprised when we
find the same bugs crop up again and again. Of course, it's not clear
that we can do better: RFC 6090 was incorrect, as the formulas were
not transcribed out of Chudnovosky and Chudnovosky, or Silverman and
in the process were incorrect. Luckily no one actually followed that
RFC.

There is also the case of MD5. From the beginning, concerns were
raised about the 2^64 collision search time. By 1996, collisions in
the compression function were known.

And then there is RC4, which finally, some 14 years after the
discovery that it is distinguishable from random, we are turning off.
My mutual fund still uses it though: I'll let you know when that
changes.

Once is an accident, twice is bad luck, but this...

> the EME variant of AtE (which is proven secure by Krawczyk) vs the

Encrypt then MAC is generically secure: this means that if it is
insecure, one of the two parts is not meeting its security goals. This
cannot be said, and was not said, and isn't true, for any other
possible combination. Even in "Generic Composition Revisited" one
needs the encryption and decryption processes to be bijective to get
anything other then Encrypt then MAC construction to be secure. The
EME variant is not generically secure: one needs to know certain
additional things about the encryption scheme being used.

Why are we trying to save other combinations then EtA? They aren't
more efficient, don't do anything EtA doesn't, and will fail in
practice because of gaps between what the proofs assume and what the
systems used provide, or even because of application level
implementation choices.

> no experience on what could happen when a MAC like HMAC-MD5 is broken.

If HMAC-MD5 is completely broken, we will have to migrate away from
it. But that is a simple matter of changing a ciphersuite, and we have
other options, unlike this batch of bugs.  At this point we will have
had lots of practice. Of course, it's another month: this means
another TLS problem.

Sincerely,
Watson Ladd

---

From: ianG <[email-masked]>
Date: Thu, 30 Oct 2014 00:26:03 +0000

> Are we really getting more security or are we just swapping one set of

My personal thought on this is that y'all are banging on the stable door
while the horse took off a few years back.  If we knew where it was, we
wouldn't want it back anyway, the poor nag's almost dead.

Encryption architecture has moved on from the late 1990s days of block
cipher + mode + padding + HMAC.  Although it wasn't clear at the time,
it is now very clear that the cryptographers threw these things over the
wall, leaving the software engineers to plug them together like lego or
constructor kit (meccano if elsewhere).

Since then, some time around mid 2000s, there has been a realisation
that the product has to be shipped back to cryptographers for repair.
The thing we want now is an authenticated encryption stream cipher.
Which means, it's up to the cryptographer to decide whether it is
encrypt-then-MAC or the reverse, converse, inverse, or perverse.  What
he says, we do.

Which in practical terms means we are in a three phase approach.

1.  lead all the lemmings suites to the cliff, pied piper mode.
2.  switch to ChaCha20/Poly1305 as a holding pattern.
3.  wait until CAESAR and implement the better one of that set.

iang

---

From: Yoav Nir <[email-masked]>
Date: Thu, 30 Oct 2014 07:31:45 +0200

> On Oct 30, 2014, at 2:26 AM, ianG <[email-masked]> wrote:
> 

What those cryptographers do is stick together a cipher, a mode, padding and a MAC function and call it an authenticated encryption.

How is that different from sticking together a cipher, a mode, padding and a MAC function and calling it a “ciphersuite”? That is what TLS always did, unlike IPsec that let you mix and match.

IMO the decision that AEAD was TLS 1.2-only was entirely arbitrary, and ciphersuites could have specified whatever processing we wanted them to.

Yoav

---

From: ianG <[email-masked]>
Date: Thu, 30 Oct 2014 18:48:00 +0000

On 30/10/2014 05:31 am, Yoav Nir wrote:
> How is that different from sticking together a cipher, a mode, padding and a MAC function and calling it a “ciphersuite”?

The 'why' and 'what' are no different, the 'who' and the 'where' is.

What we're now saying is that it is a cryptographer responsibility, not
a software engineer responsibility.  That's because /inter alia/
software engineers aren't good at making the MAC-then-encrypt decision,
whereas cryptographers have to be good at that.

> That is what TLS always did, unlike IPsec that let you mix and match.

ofc.  And, in TLS 1.5 you won't need to do that design, you'll just need
to choose one from amongst the 5 recommended set of CAESAR.  Which will
free up a lot of developer time to work on other things.  Hallelujah!

> IMO the decision that AEAD was TLS 1.2-only was entirely arbitrary, and ciphersuites could have specified whatever processing we wanted them to.

The way ciphersuites have been added could be said to be arbitrary, yes.

Back to the subject line:  How about taking away? ;-)  Here's a strawman
proposal:

   TLS 1.5 will deprecate all but 1 suite from the TLS 1.4 set.

iang

ps; I might be wrong on the numbers...

---

From: Derek Atkins <[email-masked]>
Date: Fri, 31 Oct 2014 12:29:43 -0400

>    TLS 1.5 will deprecate all but 1 suite from the TLS 1.4 set.

So we'll standardize on that in about 2020, and deployment will finally
get out around 2030 or so.  Not too bad!  :)

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Martin Thomson <[email-masked]>
Date: Fri, 31 Oct 2014 22:13:39 -0700

> IMO the decision that AEAD was TLS 1.2-only was entirely arbitrary, and ciphersuites could have specified whatever processing we wanted them to.

Indeed, but it is arguably a useful marker that distinguishes old from new :)

---

From: Watson Ladd <[email-masked]>
Date: Fri, 31 Oct 2014 22:52:27 -0700

> Indeed, but it is arguably a useful marker that distinguishes old from new :)

The important thing is to secure communications. To the extent this
decision prevented adoption of the only secure ciphersuites in TLS by
winding them up in a bunch of other protocol changes that didn't
affect security it was a bad one.

Did I say only secure one? Well, I was neglecting remote timing
attacks on AES encryption discovered in 2006, exploitable on almost
any system using the venerable rijndael.c, and the issues with GCM
without hardware support. Writing implementations that are fast and
not vulnerable is an exercise in vector unit abuse without hardware
support.

Sincerely,
Watson Ladd