Subject: Re: [Cfrg] [TLS] Salsa20 stream cipher in TLS

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Mon, 18 Mar 2013 19:23:41 +0000

Hi Simon,

On 3/17/13 6:51 PM, "Simon Josefsson" <[email-masked]> wrote:

>All,
>
>FYI, we have published -00 of a draft that describes how the Salsa20
>stream cipher can be added to TLS and DTLS, see:
>
>http://tools.ietf.org/html/draft-josefsson-salsa20-tls
>
>While we are not asking for WG adoption of this draft now, we are at a
>point where we would like to invite external review and solicit
>feedback.  

Some early feedback; copied CFRG.  It would be good to have review from
that community.

It is not exactly clear what problem is being addressed by this work.
Would be good to add a problem statement section.   In addition, it would
be good to provide the currently-unmet requirements to CAESAR (Competition
for Authenticated Encryption: Security, Applicability, and Robustness)
http://competitions.cr.yp.to/

Some more detailed comments, quoting from the draft:

   Recent attacks has indicated problems with CBC-mode cipher suites in
   TLS/DTLS and problems with the only supported stream cipher (RC4) in
   TLS has been known for a long time.  While AEAD cipher suites address
   these issues, concerns about performance are sometimes raised.

What are the performance concerns?   I suggest citing some relevant
performance data.

  Because the GenericStreamCipher definition in TLS does not provide
   any way to transport the Salsa20 nonce that is required for
   functionality and needed to provide the random access property, we
   let the output from the stream cipher operation be the concatenation
   of the IV and the encrypted data.

Please, define a Salsa20-based AEAD mechanism instead of a new TLS format!

>Some elements of the draft is still in flux.  For example,
>initial performance benchmarks suggests HMAC-SHA256 was a poor choice
>for the MAC so we are looking into UMAC and HMAC-SHA1 as alternatives.
>Still, all comments are appreciated.

If anything other than HMAC-SHA1 is used, that would underscore the value
of defining an AEAD algorithm.   If the main motivation for this work is
encryption that is computationally cheap, then it makes sense to pair the
algorithm with an authentication method with the same characteristics.

For security considerations, I suggest citing the analysis of Salsa20, and
adding a sentence or paragraph summarizing the best-known attacks.
Something like "Salsa20 has been analyzed by X independent teams, and the
best known attack breaks 8 of 20 rounds."

David

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

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 18 Mar 2013 21:42:13 +0100

> Hi Simon,

Hi David.  Thanks for quick review.

> Would be good to add a problem statement section.

Good idea, the document now contains this paragraph:

   The purpose of this document is to provide an alternative stream
   cipher for both TLS and DTLS that is comparable to RC4 in speed on a
   wide range of platforms.

There are other soft factors too.  In general the goal is to offer
something that can replace use of RC4 in TLS.  I'm guessing speed is one
reason people use RC4 in TLS today.

> What are the performance concerns?   I suggest citing some relevant

If there are implementations of this, we can benchmark them and compare
them against other cipher suites and include some numbers or pointers to
comparisons.  I believe Salsa20 is faster than for example AES GCM on
most platforms.

> Please, define a Salsa20-based AEAD mechanism instead of a new TLS format!

That paragraph has been removed from the current work in progress, it
was incorrect (the record sequence number will be used as nonce
instead).  I don't believe the AEAD mechanism works: there is no field
to put the MAC in it.

> algorithm with an authentication method with the same characteristics.

Yes -- only specifying HMAC-SHA256 was a mistake, and we have included a
HMAC-SHA1 variant in the working copy.  It is not clear to me whether
keeping HMAC-SHA256 is useful.

> best known attack breaks 8 of 20 rounds."

Good idea, the first paragraph of the security considerations is now:

   The security of Salsa20 is discussed in the Salsa20 security
   [SALSA20-SECURITY] paper.  The reader must consult cryptographic
   research to find out the current security status of Salsa20.  At the
   time of writing this document, there are no known significant
   security problems with Salsa20/12 or Salsa20/20.  As of early 2013,
   the best cryptanalysis breaks 8 out of 20 rounds to recover the 256-
   bit secret key in 2^251 operations, using 2^31 keystream pairs (see
   [SALSA20-ATTACK]).  For more background, see the eSTREAM report
   [ESTREAM].

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 18 Mar 2013 21:55:38 +0100

Wan-Teh Chang <[email-masked]> writes:

> On Sun, Mar 17, 2013 at 3:51 PM, Simon Josefsson <[email-masked]> wrote:
>> All,
>>
> I am interested in this work. I am especially interested in your plan
> to allow the salsa20 cipher suites to be used in TLS 1.0 and TLS
> 1.1, which you stated in the first paragraph of the Introduction
> section.
>
> Since all of the new cipher suite names end in _SHA256, I
> infer the MAC algorithm is hmac_sha256. (The fact is
> not explicitly stated in the -00 draft.)

Hi Wan-Teh and thank you for the review.  Good catch, I have added a
paragraph explaining what the MAC algorithm should be.

> It is important to clarify how hmac_sha256 can be used in TLS 1.0 and
> TLS 1.1, because a naive implementor would see the old definition of
> MACAlgorithm in TLS 1.0 and 1.1:
>
>     enum { null, md5, sha } MACAlgorithm;
>
> and conclude that hmac_sha256 can't be used in TLS
> 1.0 and 1.1.

Right.

Would adding a set of cipher suites that use HMAC-SHA1 resolve this?  We
have added them already in our working copy for performance reasons.  It
is not clear whether there is any point in also having HMAC-SHA256, it
destroys the performance properties.

> I'm also interested in figuring out if these cipher suites
> can be used in SSL 3.0. The only difficulty I see is
> extending the SSL 3.0 MAC algorithm to hash=sha256
> (see the definition of the SSL 3.0 MAC in Section 5.2.3.1
> of RFC 6101) -- it is not clear what should be the size of
> pad_1 and pad_2 for hash=sha256.

I'm hoping that using HMAC-SHA1 here would solve this too, right?

> The reason I'm interested in SSL 3.0 is that web browsers,
> when talking to Google servers, which implement TLS/SSL
> version negotiation correctly, are still downgraded to SSL 3.0
> by network errors injected by certain network devices.

Having compability with SSL 3.0 would be nice.  The next version will
mention SSL 3.0 compatibility too.

/Simon

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Mon, 18 Mar 2013 21:11:57 +0000

Hi Simon,

>instead).  I don't believe the AEAD mechanism works: there is no field

I'm not sure what you mean about the lack of a MAC field.  It would not be
hard to define an AEAD algorithm based on Salsa20; I would be surprised if
there is not a submission to CAESAR using that cipher.  And using the AEAD
in TLSv1.2 is straightforward.   (Is the issue a desire to use Salsa20 in
older versions?)

>   [SALSA20-ATTACK]).  For more background, see the eSTREAM report

Looks good.

David

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 18 Mar 2013 22:17:12 +0100

Adam Langley <[email-masked]> writes:

> On Mon, Mar 18, 2013 at 4:42 PM, Simon Josefsson <[email-masked]> wrote:
> There's no field for the GHASH tag for AES-GCM either: the
> construction of the authentication is opaque to the user of the AEAD
> algorithm. If you were to define an AEAD for this then you could
> decide where you would like the MAC to know, but it's a property of
> the AEAD, not of TLS.

Right, agreed.  Equally, the content of the ciphertext for a
GenericStreamCipher is opaque to TLS, so we could put a nonce in there
if that was necessary (but we don't need to).  Having stream ciphers
expand data is a bit unorthodox, but from a TLS protocol point of view
it may work.  Some implementation assume there is no message expansion
for stream ciphers, but I haven't seen anything in the specification
that assumes or require that.

> I'm curious why you wouldn't pair Salsa20 with Poly1305, which is the
> typical combination.

That could be another option.  The only reason is that I haven't worked
with any implementation of Poly1305, so I'm not that familiar with it.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 18 Mar 2013 22:47:39 +0100

> in TLSv1.2 is straightforward.   (Is the issue a desire to use Salsa20 in

Yes.  If it is not possible to implement Salsa20 as a
GenericStreamCipher we'll reconsider.  Right now to me it seems Salsa20
is more similar to RC4 than to AES-GCM or other AEAD ciphers and there
is no advantage in specifying it as a GenericAEADCipher while the
advantage for GenericStreamCipher is potential compatibility with older
TLS versions.

/Simon