Subject: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-01.txt

From: [email-masked]
Date: Mon, 02 Nov 2015 14:06:17 -0800

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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-chacha20-poly1305/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tls-chacha20-poly1305-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-chacha20-poly1305-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Adam Langley <[email-masked]>
Date: Mon, 2 Nov 2015 14:12:34 -0800

>    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 [email-masked] https://www.imperialviolet.org

---

From: Brian Smith <[email-masked]>
Date: Mon, 2 Nov 2015 13:02:02 -1000

Adam Langley <[email-masked]> wrote:

> using the scheme that's currently in TLS 1.3.
>

Would it be possible to do something similar for the additional data, so
that there is no additional data in TLS 1.2, just like in TLS 1.3 for
application_data records?

This is the TLS 1.2 definition of additional_data is:

    additional_data = seq_num  +

                      TLSCompressed.type +

                      TLSCompressed.version +

                      TLSCompressed.length;

In particular, I think we could define the cipher suite to preprocess
the AAD so that if it were equal to this:

     (seq_num XOR client_write_iv)[4..] || 23 || 3 || 3 || HI(len) || LO(len)

then the AAD could be replaced with zero bytes of AAD; otherwise, the
AAD be equal to the input AAD. In other words, compress the AAD with a
very simple function prior to passing it to the RFC 7539
chacha20-poly1305 AEAD function.

This way, one Poly1305 invocation per record could be saved,
potentially, for application_data records, which is the common case.
An implementation that avavoids sending encrypted alerts and avoids
renegotiation could avoid writing code for the case where non-empty
AAD is needed, and could share the exact same code between TLS 1.2 and
TLS 1.3 for ChaCha20-Poly1305.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Martin Thomson <[email-masked]>
Date: Tue, 3 Nov 2015 09:26:30 +0900

> application_data records?

The construction in TLS 1.3 will have no AAD.  I believe that the rationale is:

seq_num is masked into the nonce
TLSCompressed(sic).type is under encryption
TLSCompressed.version is covered by key derivation via the handshake hash
TLSCompressed.length was included in the AAD in 1.2 in error

Unfortunately, I don't believe that all of the above is true for TLS
1.2.  Your proposed construction covers some of these things.  If you
are willing to rely on session hash, you might drop the version, which
leaves this with the type.  We have to authenticate the content type
somehow, and I like your hack for that.

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 2 Nov 2015 23:54:58 -0800

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 <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
Colm

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 03 Nov 2015 11:34:37 +0100

On Mon, 2015-11-02 at 23:54 -0800, Colm MacCárthaigh wrote:

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

I agree that protecting the length of the communicated data is
important, but there is nothing specific to this cipher. All modern TLS
ciphers today are stream ciphers (i.e., AES-GCM and AES-CCM (*)), so
they offer the same protection as chacha20 with respect to hiding the
length. Maybe we should add a note about that in the security
considerations.

regards,
Nikos

(*). More specifically their mode is a stream cipher mode

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 3 Nov 2015 10:25:57 -0600

> https://tools.ietf.org/html/draft-ietf-tls-chacha20-poly1305-01

Section 2,

%   1.  The 64-bit record sequence number is serialized as an 8-byte,
%       big-endian value and padded on the left with 4 zeroes.

I assume you mean zero octets/bytes, and not ASCII '0' (or EBCDIC, or ...)

"padded on the left" also has some potential for ambiguity (though not as much); something about "four zero octets are prepended to the stream" might be less ambiguous.

-Ben

---

From: Colm MacCárthaigh <[email-masked]>
Date: Tue, 3 Nov 2015 08:29:17 -0800

On Tue, Nov 3, 2015 at 2:34 AM, Nikos Mavrogiannopoulos <[email-masked]>
wrote:
> important, but there is nothing specific to this cipher.

I wouldn't contest that; I just think the I-D is over-selling ChaCha20's
side-channel resistance. I would argue that in real practical terms it is
less side-channel resistant than AES-CBC; but I think a reader would be
left with the opposite impression.

Still huge +1 on adding it; it's exciting to get a fast modern
well-designed cipher into TLS.

-- 
Colm

---

From: Brian Smith <[email-masked]>
Date: Tue, 3 Nov 2015 09:29:46 -1000

Brian Smith <[email-masked]> wrote:

> This way, one Poly1305 invocation per record could be saved, potentially, forapplication_data records, which is the common case.
>
>
This is still true, but...

> An implementation that avavoids sending encrypted alerts and avoids renegotiation could avoid writing code for the case where non-empty AAD is needed, and could share the exact same code between TLS 1.2 and TLS 1.3 for ChaCha20-Poly1305.
>
>
This isn't true, because of the Finished message. So, it is not quite as
good of an idea as I thought, but still it seems like it could be
worthwhile.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Adam Langley <[email-masked]>
Date: Fri, 6 Nov 2015 10:44:13 -0800

On Tue, Nov 3, 2015 at 11:29 AM, Brian Smith <[email-masked]> wrote:
>> This way, one Poly1305 invocation per record could be saved, potentially,
>> forapplication_data records, which is the common case.
>
>
>> renegotiation could avoid writing code for the case where non-empty AAD is
>> needed, and could share the exact same code between TLS 1.2 and TLS 1.3 for
>> ChaCha20-Poly1305.
>
>

My feelings on this are not strong either way but I tend towards
keeping it simple, which to me means that this cipher suite will use
the standard AD value for the TLS version in use.

Saving a single Poly1305 block per record isn't a big deal and it
looks like we'll get it anyway with TLS 1.3. So, for the moment, I'm
not planning on adding anything to that effect.

Cheers

AGL

---

From: Adam Langley <[email-masked]>
Date: Fri, 6 Nov 2015 11:11:29 -0800

> length. Maybe we should add a note about that in the security

I've added the following to the security considerations section in -02:

        It should be noted that AEADs, such as ChaCha20-Poly1305, are not
        intended to hide the lengths of plaintext. When this document speaks of
        side-channel attacks, it is not considering traffic analysis, but
        rather timing and cache side-channels. Traffic analysis, while a valid
        concern, is outside the scope of the AEAD and is being addressed
        elsewhere in future versions of TLS.

Cheers

AGL

---

From: Adam Langley <[email-masked]>
Date: Fri, 6 Nov 2015 11:12:44 -0800

> "padded on the left" also has some potential for ambiguity (though not as much); something about "four zero octets are prepended to the stream" might be less ambiguous.

Sorry, I missed seeing this for -02, but I now have locally, for the
next revision:

"The 64-bit record sequence number is serialized as an 8-byte,
big-endian value and padded on the left with four 0x00 bytes."

Cheers

AGL