Re: [TLS] A la carte handshake negotiation

Nico Williams <nico@cryptonector.com> Wed, 17 June 2015 03:59 UTC

Return-Path: <nico@cryptonector.com>
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 48B551B3AE6 for <tls@ietfa.amsl.com>; Tue, 16 Jun 2015 20:59:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, 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 RnokBZcLsy7D for <tls@ietfa.amsl.com>; Tue, 16 Jun 2015 20:59:54 -0700 (PDT)
Received: from homiemail-a85.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 257B01B3924 for <tls@ietf.org>; Tue, 16 Jun 2015 20:59:54 -0700 (PDT)
Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id EBEFEBBA08A; Tue, 16 Jun 2015 20:59:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=p/2THwyGAdpirM +/E2EHhjc5ci8=; b=PpPX8wMXiSHydaibe/cwPUa6/1qnRt2lRKLcq3m4DHIZrB RmdKh/O/mbGM8z1xLeBIXS+2xU7S8KWQYKQNgYaPZzMcpm8YHp7O/bY3qsVRu4qi 3lBuTfLqLhR4CSQmc5r2G3RGJ98Hhi6h8aCWGt+8qdrSWqhyF22icX1LfWmnQ=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPA id 86400BBA088; Tue, 16 Jun 2015 20:59:53 -0700 (PDT)
Date: Tue, 16 Jun 2015 22:59:52 -0500
From: Nico Williams <nico@cryptonector.com>
To: Dave Garrett <davemgarrett@gmail.com>
Message-ID: <20150617035951.GF6117@localhost>
References: <201506111558.21577.davemgarrett@gmail.com> <20150616233111.GD6117@localhost> <201506162029.18277.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201506162029.18277.davemgarrett@gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/av1-Fbkc3TzHlCYKjRK-jU7wRRw>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] A la carte handshake negotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Wed, 17 Jun 2015 03:59:55 -0000

On Tue, Jun 16, 2015 at 08:29:17PM -0400, Dave Garrett wrote:
> On Tuesday, June 16, 2015 07:31:12 pm Nico Williams wrote:
> >  - IMO the hash should be associated with the "handshake portion" of a
> >    cipher suite, not the bulk side.
> 
> The bulk cipher and hash are often directly correlated. (e.g. SHA384
> paired with AES-256) The signature algorithms extension lists hashes
> for each certificate type.

Ah, OK.

> >  - Anon ciphersuites...
> > 
> >    I'd much rather that the WG did NOT deprecate these!
> > 
> >    For opportunistic security and channel binding applications anon
> >    ciphersuites are just fine
> 
> The alternatives in the current draft proposal are raw keys with trust
> after anon connect and fully anon via PSK. The reason for wanting to

Raw (or certificated but unable to chain to any trust anchor of the
relying party's) works, but it's a waste of resources.

PSK with a fixed key is a pointless complexity.  We already have an
unauthenticated mode; there's no need to replace it with another more
complicated one.

> deprecate these suites is that this feature is under-maintained in the
> spec. There are currently no ECDHE AEAD anon suites. [...]

We've noted this and asked for them to be registered.  The missing
assignments does not mean that the feature is unmaintained as
implemented (it's in use), as as to the spec: we're maintaining it now,
and a la carte negotiation effectively fixes the missing cipher suite
assignment issue.

> Logically, anon is a globally pre-shared null key, so it makes sense.

Logically anon (really, unauthenticated) is just... not authenticated.

> The currently proposed anon PSK has no overhead. Anon PSK is just
> id="anonymous" and a NULL key. (EC)DHE is used as normal. The only
> difference in computation is that the pre-master secret with anon PSK
> is DHresult + 0x00010 (where `+` is concat). Tacking 5 bytes onto the
> end of the DH result, once a handshake, is essentially zero overhead.

Why do even that?

Nico
--