Re: [TLS] A la carte handshake negotiation

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 12 June 2015 16:56 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCB71AC438 for <tls@ietfa.amsl.com>; Fri, 12 Jun 2015 09:56:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.7
X-Spam-Level: *
X-Spam-Status: No, score=1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-6q4R5vvHhH for <tls@ietfa.amsl.com>; Fri, 12 Jun 2015 09:56:00 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 231861AC3FD for <tls@ietf.org>; Fri, 12 Jun 2015 09:56:00 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0B8FF28494C; Fri, 12 Jun 2015 16:55:59 +0000 (UTC)
Date: Fri, 12 Jun 2015 16:55:59 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150612165558.GZ2050@mournblade.imrryr.org>
References: <201506111558.21577.davemgarrett@gmail.com> <201506121213.02446.davemgarrett@gmail.com> <20150612162236.GW2050@mournblade.imrryr.org> <201506121236.18304.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <201506121236.18304.davemgarrett@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/F3GLtWri1cCVcia1aox-haZ3Vj0>
Subject: Re: [TLS] A la carte handshake negotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jun 2015 16:56:01 -0000

On Fri, Jun 12, 2015 at 12:36:17PM -0400, Dave Garrett wrote:

> > I'm afraid I don't understand the above.  Also AECDH (ECDH_anon)
> > is not particularly rare:
> > 
> >     Jun 12 15:48:16 mournblade postfix/smtpd[25717]: Anonymous TLS connection established from xmpp.openssl.org[194.97.150.230]: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
> 
> Your quote is usage of:
> TLS_ECDH_anon_WITH_AES_256_CBC_SHA
> 
> AES CBC already cannot be used with TLS 1.3+, as it now requires AEAD ciphers only.

Indeed, there are at present no ciphersuite codepoints for AECDH
with AEAD.  That's why I'd like to see improvement in this space.
If the bulk cipher were negotiated separately, I'd expect that I'd
get the missing combinations "for free".

    $ openssl version
    OpenSSL 1.0.2a-dev xx XXX xxxx

    $ openssl ciphers -v AESGCM+kEDH
    DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(256) Mac=AEAD
    DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
    ADH-AES256-GCM-SHA384   TLSv1.2 Kx=DH       Au=None Enc=AESGCM(256) Mac=AEAD
    DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=DSS  Enc=AESGCM(128) Mac=AEAD
    DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
    ADH-AES128-GCM-SHA256   TLSv1.2 Kx=DH       Au=None Enc=AESGCM(128) Mac=AEAD

    $ openssl ciphers -v AESGCM+kECDHE
    ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
    ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
    ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
    ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD

The DH AEAD ciphersuite set includes two DH_anon members.  For ECDH
AEAD there are none.

> TLS_ECDH_anon_WITH_AES_256_GCM_SHA384 is in this expired draft:
> https://tools.ietf.org/html/draft-williams-tls-anon-ecdh-modern-cipher-01

Yes, I asked Nico to help fill the gap.  I guess this did not go
very far.

> The current proposal requires all suites for TLS 1.3+ to be the ECC
> variants, which is not currently doable for anon AES-GCM. What I'm saying
> is that we could use "DH_anon" suites instead of "ECDH_anon" suites in
> this scheme. Just properly publishing a "ECDH_anon" RFC would be preferable,
> however.

I still don't understand preclude as a matter of principle negotiation
of ECDH_anon with AEAD if DH_anon with the same bulk cipher would
be allowed.  Once we have separate negotiation of the key exchange,
surely ECDH_anon can be one of the supported key exchange variants,
and then take advantage of all the available bulk ciphersuites.

Or does this proposal simply compress the client HELLO message,
but the server is still ultimately selecting the same all-in-one
ciphersuite (thus requiring Nico's new code points for ECDH_anon
with AEAD)?

-- 
	Viktor.