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

[David McGrew <[e-mail]>]

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.  

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

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.   

There is ongoing work on authenticated encryption which this draft is
not taking advantage of, e.g. [2].  This could be a missed opportunity;
if the IETF is publishing new authenticated encryption schemes for TLS,
they should improve on the existing schemes.  For instance, the
ciphersuites in the draft do not provide any misuse resistance; they
have the same properties with respect to IV/nonce misuse as does
AES-GCM.   Granted that many GCM implementations successfully avoid
misuse, but several observers have identified misuse resistance as a
desirable property for future AEAD methods.  (See for instance [3] and
RFC 5297.)   A draft using an AEAD method based on SALSA20 that provides
misuse resistance of some kind would be more useful, and would be less
likely to become obsolete in the near future.  

Some more minor points below:

The draft has no mechanism to allow multiple encrypters to work in
parallel, such as is provided in Section 6.2 of RFC5288.

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.  

Slide 16 shown at IETF87 presents the shorter MAC size as having less
data overhead as compared with existing ciphersuites.   This is true,
but if compactness is a goal, AEAD schemes with less overhead could be
used instead.   (Some are defined already at [3].) 

I don't have anything against SALSA20, nor am I the best person to
assess its quality as a pseudorandom function.   

David, speaking as a research group member and not a research group
co-chair

[1] Gueron, S.  AES-GCM for Efficient Authenticated Encryption - Ending
the Reign of HMAC-SHA-1?  Workshop on Real-World Cryptography, 2013.  

[2] http://2013.diac.cr.yp.to/

[3] http://hyperelliptic.org/DIAC/slides/DIAC-mcgrew.pdf

[4] IANA AEAD Registry,
http://www.iana.org/assignments/aead-parameters/aead-parameters.xhtml


On Thu, 2013-08-08 at 19:45 +0000, Igoe, Kevin M. wrote:
> The TLS WG has asked the CFRG for their opinion for a stream cipher,
> eSTREAM-SALSA20, and two MAC algorithms, UMAC and POLY1305, that have
> been suggested for use in TLS (draft-josefsson-salsa20-tls-02).  This
> was presented to the TLS WG at IETF-87, slides can be found at
> http://www.ietf.org/proceedings/87/slides/slides-87-tls-2.pdf.
> The SALSA family works on blocks of 512 bits, and forms a key stream
> in 512-bit blocks by applying a fixed map V^{512}->V^{512} to an input
> consisting of the key (either 16 octets or 32 octets), an 8-octet
> block counter, an 8-octet IV, and 16 constant octets.
>  
> SALSA20 was one of the five finalists for a software stream cipher in
> the eSTREAM contest run by ECRYPTII (see
> http://www.ecrypt.eu.org/stream/).
>  
> UMAC has been around since 1999 and is described in RFC 4418.
>  
> POLY1305 first showed up as POLY1305-AES, but all it needs from AES is
> a 16 byte block of output. Adapting this to SALSA is straightforward.
> The 1305 in the name reflects the fact that it uses arithmetic modulo
> 2^{130} – 5.  See http://cr.yp.to/mac/poly1305-20050329.pdf
> for a description of poly1305-AES.
>  
> Off the top of my head, the only objection I can see is that SALSA may
> be difficult to implement efficiently in hardware.  Hardware TLS
> acceleration can be useful at heavily utilized servers.
>  
> The most current attempt to attack SALSA that I could find is a 2012
> paper on the IACR
> e-print server.
>  
> ----------------+--------------------------------------------------
> Kevin M. Igoe   | "We can't solve problems by using the same kind
> [e-mail]  | of thinking we used when we created them." 
>                 |              - Albert Einstein -
> ----------------+--------------------------------------------------
>  
>  
>  
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg