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

[Nikos Mavrogiannopoulos <[e-mail]>]

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. 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/


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 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 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. 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.


> 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