Huge +1 to this I-D, just some minor comments: * I wonder if the document should be more forthright in specifying that the ChaCha20/Poly1305 implementations SHOULD actually attempt to use constant-time and constant-access patterns that the algorithm is designed to facilitate. If that's a selling point then I wonder if it's worth being specific about that. On that point: I'm curious if those properties are implementable in a variety of languages, or if it requires near-assembly (e.g. C) levels of precision. If it's the latter, then I wonder if it's legitimate to include those selling points.
* I think the statement "can be implemented easily without being vulnerable to software side-channel attacks" is too strong, unless one wants to really litigate what "software side-channels are". Unless I'm mistaken, as a stream cipher ChaCha20 is *more* vulnerable to a class of size-based side-channels than a block cipher would be. A simple form of attack would be to monitor connections to wikipedia and identify which pages a user is browsing; from observing just the size of requests and responses [*] it's pretty easy for an attacker to (offline) create a graph of HTML page sizes and the sizes of the images they load and then (in real time) to correlate things such that they can uniquely identify the page loaded. This attack is feasible with both stream and block ciphers, but it is far easier with a stream cipher. Similarly, the compressed map tiles attack that shows where an online maps user is browsing is much more effective with a stream cipher. [ http://blog.ioactive.com/2012/02/ssl-traffic-analysis-on-google-maps.html] These kinds of simple correlation attack are vastly more practical than the kinds of time and cache access side-channels that CBC verification is weak against. They are also inherently passive and undetectable. On the whole the I-D reads as if ChaCha20 is more side-channel resistant, but I think reasonable people could disagree about this - and it's worth some discussion in the security section. [*] Consider also that in the case of Wikipedia an attacker can control the size of a target page they may be interested in. On Mon, Nov 2, 2015 at 2:12 PM, Adam Langley <a...@imperialviolet.org> wrote: > On Mon, Nov 2, 2015 at 2:06 PM, <internet-dra...@ietf.org> wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Transport Layer Security Working Group > of the IETF. > > > > Title : ChaCha20-Poly1305 Cipher Suites for Transport > Layer Security (TLS) > > Authors : Adam Langley > > Wan-Teh Chang > > Nikos Mavrogiannopoulos > > Joachim Strombergson > > Simon Josefsson > > Filename : draft-ietf-tls-chacha20-poly1305-01.txt > > Pages : 7 > > Date : 2015-11-02 > > > > Abstract: > > This document describes the use of the ChaCha stream cipher and > > Poly1305 authenticator in the Transport Layer Security (TLS) and > > Datagram Transport Layer Security (DTLS) protocols. > > Dear all, > > I've submitted the above version of the ChaCha20-Poly1305 draft in the > hopes of getting consensus that it's basically what the group wants > and thus is suitable for early code-point assignment. > > The major change in this version is that the nonce is constructed > using the scheme that's currently in TLS 1.3. To recap: AES-GCM in TLS > 1.2 uses a four-byte, fixed nonce fragment with an explicit, > eight-byte value from the wire appended. ChaCha20-Poly1305 seeks to > eliminate these eight bytes in each record by using the TLS sequence > number. (On this I believe that we basically have agreement.) > > The TLS 1.3 spec already specifies that AEADs use the sequence number > and has a construction where a fixed value (from the handshake output) > is XORed with it. (See > https://tlswg.github.io/tls13-spec/#record-payload-protection.) This > draft apes that in the hopes that the TLS 1.3 construction doesn't > change before its final. > > > Cheers > > AGL > > -- > Adam Langley a...@imperialviolet.org https://www.imperialviolet.org > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Colm
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
