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

[Nikos Mavrogiannopoulos <[e-mail]>]

On Mon, Aug 26, 2013 at 6:49 PM, David McGrew <[e-mail]> wrote:

> Hi Nikos,
>
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.
>

Hello David,
 I don't think that this is the purpose of this draft. This draft merely
defines how to use salsa20 in TLS. There is a lot of controversy on whether
a cipher is fast/slow or whatever on a particular platform (depending on
the implementation, power usage), and personal taste :) If we'd try to
quantify those things in this draft it would take more effort and heat than
needed. If as you imply salsa20 is not as fast in some platforms, then
things are simple, it will not be used in those platforms. The intention is
to define salsa20 to be used in the platforms that is faster than AES.


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


I believe that you have misunderstood how the GenericStreamCipher operates
in TLS. No TLS implementation releases plaintext data that have not been
authenticated in GenericStreamCipher or any other mode. This was one of the
initial goals in TLS, and that is the reason that (unlike IPSec) there
aren't any ciphersuites that do not provide authentication.

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

That is a nice idea, and we can consider this option when this is done.
However, as you previously argued it would be good to have a
GenericAEADCipher that uses the TLS sequence numbers instead of another
explicit nonce to save bytes.



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

As far as I understand RFC5288 doesn't use a deterministic nonce. It allows
the implementer to use any nonce he likes. It merely suggests (with a MAY)
to copy the TLS sequence number as 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.
>

I don't quite understand your objection. Since each TLS record has a
distinct and unique sequence number (and thus nonce), it is pretty
straightforward to map each record on a different CPUs for encryption.
There is nothing non-obvious needed to clarify there (unless I don't
understand your point).

regards,
Nikos