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

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

Hi Nikos,

On 3/18/13 4:02 PM, "Nikos Mavrogiannopoulos" <[email-masked]> wrote:

>On 03/18/2013 08:23 PM, David McGrew (mcgrew) wrote:
>
>> 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.
>
>
>As I understand, the requirement, is a fast stream cipher that can be
>used for TLS and DTLS, and doesn't have the issues RC4 has [0].
>
>[0]. http://home.hiroshima-u.ac.jp/ohigashi/rc4/index.html

Yes, I'm well aware of the RC4 issues and I support its deprecation.

>
>> Some more detailed comments, quoting from the draft:
>
>> What are the performance concerns?   I suggest citing some relevant
>> performance data.
>
>
>The GCM mode does require special instructions to achieve performance
>close (but often not better) to RC4 in general purpose CPUs. The stream
>ciphers from the eStream competition outperform RC4 without any hw
>assistance.

The appropriate comparison would include both authentication and
encryption, so comparisons to "naked" stream ciphers are misleading.  And
I strongly encourage actual performance comparisons on target platforms.

>
>>   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!
>
>
>The GenericStreamCipher mode is sufficient for this mode. It just
>requires to define how to set the nonce. I think using the AEAD would
>complicate things rather than provide any practical advantage.

I respectfully disagree.

David

>regards,
>Nikos

---

From: Yoav Nir <[email-masked]>
Date: Fri, 22 Mar 2013 06:06:44 +0000

On Mar 22, 2013, at 1:23 AM, Martin Rex <[email-masked]> wrote:

> Adam Langley wrote:
>> On Thu, Mar 21, 2013 at 8:09 AM, Yoav Nir <[email-masked]> wrote:
>>> 
>>> Actually, we turned on TLS 1.2 by default for the speed advantage.
>>> iOS begins a TLS handshake with version 1.2, both in ClientHello
>>> and in the record layer. Only when the (shocked and flabbergasted)
>>> server closes the connection, does the iPhone try with something
>>> more sane like 1.0, and then even caches this for a short while.
> 
> Are you sure?
> 
> It would clearly be stupid behaviour on part of iPhone to send an
> initial ClientHello with { 0x03, 0x03 } at the record layer.

It would be, and it was. This was long ago, so it may have been fixed in iOS 6.

> 
> It should be sending this version in ClientHello.client_version alone.
> 
>> 
>> But you don't need to switch on TLS 1.2 to fix this, right? The server
>> just needs to implement version negotiation correctly.
> 
> The servers typically implement it correctly.  If iPhone is willing
> to talk a protocol version < TLSv1.2, then using TLSv1.2 on the
> Record Layer on the first ClientHello is a stupid bug. 
> 
> Only(!!) TLSv1.2 servers will ignore the record layer PDU version
> on the initial ClientHello (but for them this is currently entirely
> irrelevant, since there is no TLSv1.3 and no borked TLSv1.3 clients
> that tag PDUs incorrectly).
> 
> 
> -Martin
> 
> Email secured by Check Point