Subject: Re: [TLS] padding bug

From: Peter Gutmann <[email-masked]>
Date: Fri, 20 Sep 2013 13:29:35 +0000

Eric Rescorla <[email-masked]> writes:

>Of course, this naturally raises the question of whether this document will
>be accepted by the TLS WG.

It seems to be accepted by everyone except the WG chairs, who point to:

>However, as I think recent discussion indicates, there are a number of
>proposed approaches and there isn't really consensus to adopt this particular
>one

Can you provide concrete examples of this lack of consensus?  It's already
present in deployed implementations (as I mentioned a while back, the response
of one SSL library developer was "this should have been done ten years ago").
So lets reverse this, if the WG chairs think that there are viable alternative
approaches could they please point to *currently active RFC drafts* (not an
expired six-month-old text but a current draft) with authors willing to
actively champion their approaches on the list?

If this isn't possible, can we just go ahead and adopt it?  This is a decade-
old problem with a fairly trivial fix, and yet the NSA doesn't even need to
resort to BULLRUN-style subversion if the WG chairs are determined to block
its adoption.

Peter.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Sep 2013 08:52:50 -0700

On Fri, Sep 20, 2013 at 6:29 AM, Peter Gutmann <[email-masked]>wrote:

> Can you provide concrete examples of this lack of consensus?

These messages from Nikos look negative to me:
http://www.ietf.org/mail-archive/web/tls/current/msg09809.html
http://www.ietf.org/mail-archive/web/tls/current/msg09520.html

This looks like "meh" to me:
http://www.ietf.org/mail-archive/web/tls/current/msg09826.html

Privately, I've also heard objections to attempting to prolong the
life of CBC as a primitive. Perhaps those who expressed this
would speak up on the list?

 It's already
> actively champion their approaches on the list?

We have drafts for AEAD w/ CBC:
http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-01

And I have heard a variety of suggestions for pushing AEAD down into
TLS 1.2 (there's no technical problem here). If we were to do that, the
draft would presumably be trivial and then we could simply directly
adopt the McGrew draft.

If we were to abandon CBC entirely we would mostly want some
new stream ciphers. E.g.,

http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-01
http://tools.ietf.org/html/draft-josefsson-salsa20-tls-02

So, certainly if we wanted to to adopt a "triage and selectively replace"
strategy, we have the drafts to do it. In addition, we do have a

Pad then encrypt then MAC draft that is recent.
http://tools.ietf.org/html/draft-pironti-tls-length-hiding-01

That is not to say that the WG could not also adopt your draft, but as I
said
above, it's not the only alternative.

We think this would benefit from F2F discussion and I would invite you or
someone else in favor of this draft (or another approach) to present in
November in Vancouver. If there is WG consensus for this, we can adopt
it then.

Best,
-Ekr

P.S. I am about to go mostly offline through Monday night. Apologies in
advance for slow/non-response.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Sep 2013 08:56:01 -0700

> TLS 1.2 (there's no technical problem here). If we were to do that, the

This should say below TLS 1.2.

-Ekr

---

From: Adam Langley <[email-masked]>
Date: Fri, 20 Sep 2013 12:27:22 -0400

> http://www.ietf.org/mail-archive/web/tls/current/msg09826.html

I think that "meh" is probably a reasonable summary of my post, yes.

If we accept that making any change costs about the same, because the
cost overwhelmingly consists of the amount of time that we have to
wait for deployment, then I'd very much like a better change than
warming up CBC's corpse again.

There is one case where this might not be the case however: an Acme
TLS stack that is basically unmaintained but might be able to hack in
an extension like this. Although I can certainly believe that
something like that exists, nothing is coming to mind but I find cases
of ten year old copies of OpenSSL pretty often.

So I've no objection to this ID, but nor am I esp excited by it.

Cheers

AGL