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

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Tue, 19 Mar 2013 13:36:06 +0000

Hi Joachim,

On 3/19/13 9:06 AM, "Joachim Strömbergson" <[email-masked]> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Aloha!
>
>On 2013-03-18 21:45 , Adam Langley wrote:
>> I'm curious why you wouldn't pair Salsa20 with Poly1305, which is
>> the typical combination.
>
>Is poly1305 widely used?

I think that's the wrong question to ask when considering a MAC based on
universal hashing, since the security of such constructs is well
understood.  

>Would it be advantageous for adoption and
>approval of Salsa20 in TLS to also introduce poly1305?

If one of the motivations for adopting Salsa20 is that it is
computationally cheap (fast in software, small circuit, low power
consumption) then it definitely makes sense to pair it with an
authenticator with the same properties.  It will be important to make sure
that the performance is adequate on all of the processors under
consideration.   Many universal hash functions have a performance that is
closely linked to that of the 32,64, or 128-bit multiplication operation,
which varies widely across CPUs.

>
>My gut feeling is/was that trying to just provide a really good
>alternative to RC4 would be easiest to do and get adoption for.

Well, AES-GCM is certainly a good alternative to RC4 and CBC.  It is
security-conservative, already specified in TLSv1.2 and implemented in
many places, performs very well on dedicated hardware and performs
adequately otherwise, and is approved for use in FIPS-140.

David

>
>- -- 
>Med vänlig hälsning, Yours
>
>Joachim Strömbergson - Alltid i harmonisk svängning.
>========================================================================
> Joachim Strömbergson          Secworks AB          [email-masked]
>========================================================================
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
>Comment: GPGTools - http://gpgtools.org
>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
>iEYEARECAAYFAlFIYsYACgkQZoPr8HT30QEavwCg04uHLG2XSgTRHt2fL9NZdMft
>FM4AoIlRvzHPPzwnjHe4yKkYOjm9q6Bo
>=ddOd
>-----END PGP SIGNATURE-----

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 19 Mar 2013 21:41:16 +0100

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

> Although it may be possible to retrofit GenericAEADCipher into TLS 1.0 and
> 1.1, the existing implementations of the AES-GCM cipher suites restrict them
> to TLS 1.2, so there will still be interoperability problems.

Implementations could be fixed here, if we want to.  There may still be
interop problems, but there will always be interop problems so
implementations need to handle them anyway.

> Assuming we can solve the problems of using GenericAEADCipher and
> updating key expansion in TLS 1.0 and 1.1, new AEAD cipher suites can
> describe how they will be used in older versions of TLS from day one.
> So it still seems worthwhile to solve the problem of using AEAD cipher
> suites in TLS 1.0 and 1.1.

That may be useful, and would likely have helped adoption of AEAD
ciphers in TLS if it was done from the start.

I'm not sure why TLS 1.2 isn't negotiated more often by browsers.  If it
is an implementation issue, I'm not convinced specifying AEAD ciphers
for TLS 1.0 and TLS 1.1 will help: they just get another implementation
issue to implement that instead.  Admittedly, it is a different
implementation task, so it may be fixed earlier than the other issue,
but that is difficult to predict.  Generally, it might be better to push
browsers vendors to switch to TLS 1.2 more quickly, then the problem is
also solved.

/Simon

---

From: Jon Callas <[email-masked]>
Date: Tue, 19 Mar 2013 16:30:16 -0700

> browsers vendors to switch to TLS 1.2 more quickly, then the problem is

There are two reasons. Uncertainty about ECC, and uncertainty about GCM.

We can debate how much the ECC uncertainty is warranted, but lots of people have it. We can also debate the GCM issues, but GCM is tetchy to use properly. And yes, you could always use CCM instead. But most people don't know that CCM is part of TLS 1.2. I didn't know it I discovered it while writing this note.

The general opinion about TLS 1.2 is that that's the version for Suite B. That's not precisely true. I had that opinion for a while until I learned I was mistaken. However, if you have concerns about either ECC or GCM, then you have concerns about TLS 1.2. I don't know if you can do 1.2 without ECC or GCM.

	Jon

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Wed, 20 Mar 2013 09:55:26 +0000

Hi Jon,

On 3/19/13 7:30 PM, "Jon Callas" <[email-masked]> wrote:

>We can debate how much the ECC uncertainty is warranted, but lots of
>people have it. We can also debate the GCM issues, but GCM is tetchy to
>use properly.
>And yes, you could always use CCM instead. But most people don't know
>that CCM is part of TLS 1.2. I didn't know it I discovered it while
>writing this note.
>
>The general opinion about TLS 1.2 is that that's the version for Suite B.
>That's not precisely true. I had that opinion for a while until I learned
>I was mistaken. However, if you have concerns about either ECC or GCM,
>then you have concerns about TLS 1.2. I don't know if you can do 1.2
>without ECC or GCM.

TLSv1.2 barely mentions either GCM or ECC, much less requires their use.
RFC 5246 says: in the absence of an application profile standard
specifying otherwise, a TLSv1.2-compliant application MUST implement the
cipher suite TLS_RSA_WITH_AES_128_CBC_SHA.  No ECC or GCM ciphersuites are
mentioned in that RFC.  On the flip side, there are benefits in using that
version; v1.2 allows to use SHA256 in key derivation (PRF) and message
authentication (HMAC), allows the use of AEAD, and adds other fixes.

GCM does require a distinct nonce for each encryption operation, which
makes it vulnerable to "nonce misuse", or makes it tetchy as you say.
However, this property is a non-issue in TLS, since it is easy to use a
sequence number as a nonce, and session keys don't persist between
sessions.   For comparison, Salsa20 and UMAC, both recently mentioned on
this thread, would also have exactly the same distinct-nonce requirement,
and essentially RC4 does as well (in the sense that an application that
mis-manages the RC4 state would likely cause a loss of confidentiality).

David

>Version: PGP Universal 3.2.0 (Build 1672)
>Charset: us-ascii
>
>wj8DBQFRSPUpsTedWZOD3gYRAimEAJ0V1eXYxUqRHxWWNaX1GzZJIIz0ZgCfRBXF
>48rWFyQymJ1znyyvWCKO4MY=
>=Jh5v
>_______________________________________________
>Cfrg mailing list
>[email-masked]
>http://www.irtf.org/mailman/listinfo/cfrg

---

From: Jon Callas <[email-masked]>
Date: Wed, 20 Mar 2013 16:53:55 -0700

> mis-manages the RC4 state would likely cause a loss of confidentiality).

I apologize for note being organized in my typing. Let me try again.

Rightly or wrongly, there's a perception both on the implementation end and the deployment end that TLS 1.2 is the "Suite B" version of TLS, that it's mandatory to implement and mandatory to deploy. That this is a misperception is in fact what part of the problem is. I've held many of these misperceptions myself, and if someone as expert as I doesn't grok TLS 1.2, then how is the average developer or sysadmin going to understand?

TLS 1.2 needs some marketing that explains why people want it, and that needs to include reassurance that it doesn't require you to commit to ECC and GCM. Many people out there believe precisely this.

	Jon