Re: [Cfrg] problems with draft-josefsson-salsa20-tls-02

[David McGrew <[e-mail]>]

Hi Nikos,

On Thu, 2013-08-22 at 22:57 +0300, Nikos Mavrogiannopoulos wrote:
> On Wed, Aug 14, 2013 at 11:32 PM, David McGrew <[e-mail]>
> wrote:
> 
> Hello,
> 
>  I believe your comments relate more to the ietf-tls rather than this
> list. In any case some comments are in-line.
>  
>         This draft lists two motivations: RC4 security is inadequate,
>         and the
>         performance of the symmetric cryptography in other
>         ciphersuites is
>         inadequate.  I agree with the first premise, and the authors
>         deserve
>         kudos for raising and starting to address the issue.
>         However, the
>         second premise is questionable.  The draft cites
>         [AEAD-PERFORMANCE], and
>         that reference shows that the performance of AES-GCM and
>         AES-CCM are
>         suboptimal in some scenarios, not that they are inadequate.
>          The draft
>         ought to cite some other work such as [1] to provide a broader
>         viewpoint
>         on ciphersuite performance and deployment considerations of
>         new
>         ciphersuites.   If it is the case that SALSA20 and UMAC (or
>         POLY1305)
>         compellingly outperform existing ciphersuites on some
>         particular client
>         environments and server environments, the draft should
>         document the
>         particulars.
> 
> 
> I thought that it was generally accepted that salsa20 (or any other
> estream candidate) outperform AES.  

If there is a compelling benefit to using these ciphersuites, it
deserves to be quantified.  

> There are benchmarks in the estream framework we can link to [0] if it
> is deemed necessary.
> 
> [0]. http://www.ecrypt.eu.org/stream/perf/

It definitely would be good to reference the ESTREAM performance
comparisons, but the draft should also explain what platform(s) are the
performance targets.   Is the goal of the draft to minimize CPU
utilization, and thus power usage, on mobile clients, without regard to
servers?   Or perhaps there is another goal; I'm speculating here.

An example of why better documentation of the benefits is needed: in the
ESTREAM performance tables that you cite above, AES CTR uses fewer CPU
cycles than Salsa20 on some platforms, while Salsa20 uses fewer cycles
on some other platforms. 

> 
> 
> 
> 
>         The security question that we should be considering is: are
>         the
>         authenticated encryption schemes defined in this draft sound?
>         The
>         strategy used in this draft is to rely on the "generic
>         composition"
>         framework provided by TLS: a new GenericStreamCipher is
>         defined and is
>         used at the same time as a TLS MAC algorithm, which is either
>         the
>         conventional TLS HMAC or the new TLS UMAC algorithm defined in
>         this
>         draft.   Thus, there is a merely a loose binding between
>         authentication
>         and encryption, and a potential opportunity for a side channel
>         attack
>         like the ones described in [CBC-ATTACK].  
> 
> 
> I don't understand why you think that. There is no padding involved in
> the salsa20 ciphersuites, so the padding based  [CBC-ATTACK] (or any
> other similar attack) do not apply. To my knowledge there is no known
> issue for the mode used in salsa20/hmac or salsa20/umac in the draft.
> 
> 
>         The draft recognizes the value
>         of resisting side channel attacks, but the loose binding
>         approach works
>         against that goal.  Instead of defining a GenericStreamCipher,
>         the draft
>         should define an AEAD algorithm, which would close the door on
>         that sort
>         of vulnerability.
> 
> 
> I don't quite understand that. Could you elaborate on the particulars?
> Why do you think that the TLS GenericStreamCipher is vulnerable to
> side-channel attacks (and the GenericAEADCipher is not?). I believe
> your comment is towards the general constructions (and more precisely
> you mean the GenericBlockCipher) rather than this particular
> ciphersuite.
> 

One of the important properties of a sound authenticated encryption
scheme is that the decryption operation does not release any
(potentially invalid) plaintext data until the authentication check is
complete.  The GenericStreamCipher does not require an implementation to
have this property.  Experience with AEAD has shown that implementers
are sometimes reluctant to comply with the requirement to not release
post-decryption, pre-verification plaintext, even when the specification
is quite clear on that point.  

>  
> 
>         One of the motivations for not using the TLS GenericAEADCipher
>         mechanism
>         is that it appears only in TLSv1.2.  However, the draft
>         proposes
>         extensions to both the GenericStreamCipher and MAC algorithms
>         used by
>         TLSv1.0 and TLSv1.1, and it would be no more intrusive to
>         those
>         protocols to define the use of GenericAEADCipher in them.
>          Using the
>         same AEAD mechanism for versions 1.0, 1.1, and 1.2 would
>         result in
>         smaller and less complex implementation.
> 
> 
> Only if you can work in clean slate. Unfortunately that doesn't happen
> in practice. In practice one would add the ciphersuite in an existing
> implementation that may not support TLS 1.2.

The point that I wanted to make is: instead of re-defining the
GenericStreamCipher and MAC algorithms for TLS v 1.0 and 1.1,
GenericAEADCipher can be added to those versions of the protocol.   That
would enable a TLS implementation that supports the current version of
the protocol to use its GenericAEADCipher for all three versions, and
relieve that implementation of the need to support an updated definition
for GenericStreamCipher and MAC.

> 
>  
> 
>         The draft has no mechanism to allow multiple encrypters to
>         work in
>         parallel, such as is provided in Section 6.2 of RFC5288.
> 
> 
> Actually RFC5288 needs this section because it uses a random nonce.

No, RFC5288 uses a deterministic nonce.

>  Since the salsa draft doesn't use a random nonce it doesn't require
> such a special provision for parallel encryptors. Parallel encryptors
> come for free in the salsa20 draft.
> 

No, each Salsa20 nonce MUST be distinct, and the draft makes no
provision to ensure that they can be distinct when multiple encrypters
are in use.  Rather than being "for free", the draft provides no way to
allow for an implementation to use parallel encryptors and to maintain
security.  

regards,

David

>  
> 
>         Previous AEAD work has chosen to not use the sequence number
>         provided by
>         TLS (and other protocols) because of a lack of assurance that
>         those
>         values will be unique.  This draft does use those sequence
>         numbers,
>         which enables its ciphersuites to have less data overhead, but
>         introducing a potential vulnerability through mismanagement of
>         sequence
>         numbers by TLS implementations.
> 
> 
> TLS ensures that sequence numbers are unique. All of the TLS 1.x
> documents mention specifically:
> 
>  "Sequence numbers are of type uint64 and may not exceed 2^64-1.
> Sequence numbers do not wrap".
> 
> 
> 
> regards,
> Nikos
> 
> 
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg