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

From: [email-masked]
Date: Thu, 11 Jun 2015 10:03:17 -0700

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           : The ChaCha20-Poly1305 AEAD Cipher for Transport Layer Security
        Authors         : Adam Langley
                          Wan-Teh Chang
                          Nikos Mavrogiannopoulos
                          Joachim Strombergson
                          Simon Josefsson
	Filename        : draft-ietf-tls-chacha20-poly1305-00.txt
	Pages           : 7
	Date            : 2015-06-11

Abstract:
   This document describes the use of the ChaCha stream cipher with
   Poly1305 in 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-00

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: Dave Garrett <[email-masked]>
Date: Fri, 12 Jun 2015 23:55:45 -0400

After discussion earlier involving ECDHE_anon cipher suites, it occurred to me that it could be useful to define one for ChaChaPoly in this draft.

Is it viable to add a cipher suite name and codepoint for this? It didn't get brought up in the previous discussion on this list about which suites were desired here.

TLS_ECDHE_anon_WITH_CHACHA20_POLY1305

(preferably "ECDHE" instead of "ECDH" for consistency with newer suites, rather than the old anon suites)

At the moment, there are no AEAD ECDHE anon cipher suites currently standardized. The only AEAD DHE anon cipher suites are the two AES-GCM suites defined in RFC5288. TLS 1.3 requires AEAD, so this means it has very few anon choices, and no ECDHE anon yet.

Dave

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 14 Jun 2015 14:17:29 +0200

Dave Garrett <[email-masked]> writes:

> After discussion earlier involving ECDHE_anon cipher suites, it
> occurred to me that it could be useful to define one for ChaChaPoly in
> this draft.
>
> Is it viable to add a cipher suite name and codepoint for this?

What is the use-case?

/Simon

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 14 Jun 2015 13:46:39 +0000

> > Is it viable to add a cipher suite name and codepoint for this?

0.   Authentication other than via certificate-based PKI.  Establish
     anon TLS, and channel-bind the TLS-unique via GSSAPI or some
     other authentication method.

1.  Unauthenticated opportunistic TLS.

    * Server performs no unnecessary signature operations,
      since the client can't verify the signature anyway.
      (More precisely the client can't verify the authenticity
      of the server keys, so it can only determine that somebody
      signed the handshake, but no idea whether it is the intended
      server).

    * Servers can tell which clients are not verifying their
      identity, (definitely the ones the offer or negotiate "anon"
      ciphersuites).  This is useful information.

-- 
	Viktor.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 15 Jun 2015 22:57:48 +0200

>       signed the handshake, but no idea whether it is the intended

Both those use-cases can be achieved by chosing, say, ECDHE_ECDSA and
not verify the signature, right?

>       ciphersuites).  This is useful information.

I don't think you can necessarily infer that from what a client offers.
It may behave differently depending on which ciphersuite is chosen.

However, maybe we can do:

  TLS_ECDHE_anon_WITH_CHACHA20_POLY1305 = {0xTBD, 0xTBD} {0xCC, 0xA4}

I'd appreciate if others could weigh in their opinion on whether more
ECDHE_anon ciphersuites are important or not.

/Simon

---

From: Jeffrey Walton <[email-masked]>
Date: Mon, 15 Jun 2015 19:46:01 -0400

> Both those use-cases can be achieved by choosing, say, ECDHE_ECDSA and
That's a violation of the engineering requirements :) If you don't
need server authenticity, then you don't ask for it. If you ask for
it, then you have to validate it.

I know I'm splitting hairs, but I would reject that kind of check-in.
I fear a proliferation of
https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html.
It also creates a few extra rules, and we have to teach them to
developers, QA and auditors.

Jeff

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 16 Jun 2015 10:08:30 +0200

> it, then you have to validate it.

It may appear that way -- but implementing support for ANON ciphers is
more work than NOT implementing support for certificate validation.
Supporting ANON in standards, implementation, testing/QA etc carry a
cost.  We should strive towards offsetting costs with use-cases that can
motivate the costs.

> developers, QA and auditors.

Negotiating these ciphers and not verifying the signature is already
widely deployed (e.g., SMTP STARTTLS), so there is nothing new that
needs to be done.

/Simon

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 16 Jun 2015 10:46:22 +0200

> it, then you have to validate it.

Not really. Validation of certificates is outside the scope of TLS. You
may validate using PKIX, trust on first use, or not at all and still do
TLS.

Said that, I cannot think of many cases where you don't need server 
authenticity. Even the opportunistic encryption mentioned can use 
server authenticity, to verify using trust on first use for example.
However, if you rely on the anonymous ciphersuites for opportunistic
encryption you ensure that trust on first use _cannot_ be done.

For the use case (0) mentioned, for authentication with alternative 
PKI  methods, rfc7250 is more appropriate, rather than an anonymous 
ciphersuite.

For channel-binding using anonymous ciphersuites, is that defined 
somewhere? If that practice is already used and defined by IETF, 
adding an anonymous ciphersuite may make sense.

regards,
Nikos

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 16 Jun 2015 11:43:32 +0200

> adding an anonymous ciphersuite may make sense.

It is discussed in RFC 5802:

   If the external security layer used to protect the SCRAM exchange
   uses an anonymous key exchange, then the SCRAM channel binding
   mechanism can be used to detect a man-in-the-middle attack on the
   security layer and cause the authentication to fail as a result.
   However, the man-in-the-middle attacker will have gained sufficient
   information to mount an offline dictionary or brute-force attack.

In my view, using anonymous key exchanges with channel binding is a bad
idea.  It opens up for these attacks and there is no ways of detecting
them.  If ANON ciphersuites aren't used, there is at least a way to
detect MITM, and even if verification didn't happen directly, you can
log fingerprints for later auditing to prove what happened.

I believe more solid use-cases are needed to motivate ANON ciphersuites.
The use-cases presented so far does not strike me as fully fleshed out,
and there appears to be better ways of adressing them.

/Simon

---

From: Hubert Kario <[email-masked]>
Date: Tue, 16 Jun 2015 12:07:03 +0200

> cost.  We should strive towards offsetting costs with use-cases that can

From QA perspective it's easier to test a specific ciphersuite than to test 
some obscure option that disables signature verification that every 
application names differently.

A(EC)DH ciphersutes are well known and used configuration option, "disable 
signature verification on ServerKeyExchange" is not.

> widely deployed (e.g., SMTP STARTTLS), so there is nothing new that

this is true only in SMTP because of its legacy, it's not something we should 
encourage

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: [email-masked] (Martin Rex)
Date: Tue, 16 Jun 2015 18:24:14 +0200 (CEST)

> signature verification on ServerKeyExchange" is not.

There may be SSL/TLS implementations that do not implement any of the
DH_anon/ECDH_anon cipher suites.  Our implementation does not implement them.
So for use with SMTP+TLS (which we do support) DH_anon may simply not be an
option.

But we also do not allow application programmers to skip certificate
path validation (that is only possible at the low-level APIs and used
by the SMTP+TLS/STARTTLS code.

The problem that I have with DH_anon/ECDH_anon is that it is equal
to TLS with Alzheimer.  Not being able to authenticate the server
is a problem, but also being unable to re-recognize a previous
communication peer is significantly worse.

-Martin