Re: [Cfrg] Salsa20 stream cipher in TLS

["David McGrew (mcgrew)" <[e-mail]>]

Hi Jon,

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

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Mar 19, 2013, at 1:41 PM, Simon Josefsson <[e-mail]> wrote:
>
>> 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.
>
>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.

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

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