Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - was: DSA should die)

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Tue, 14 April 2015 05:49 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
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 CCF801B33DB for <tls@ietfa.amsl.com>; Mon, 13 Apr 2015 22:49:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 QU_7Y400cBSV for <tls@ietfa.amsl.com>; Mon, 13 Apr 2015 22:49:06 -0700 (PDT)
Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A7DA1B33DA for <tls@ietf.org>; Mon, 13 Apr 2015 22:49:06 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 177F3699E1; Tue, 14 Apr 2015 08:49:04 +0300 (EEST)
Date: Tue, 14 Apr 2015 08:49:03 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Message-ID: <20150414054903.GA7186@LK-Perkele-VII>
References: <CAK9dnSyKf7AY11h1i1h+SudRc-NmTZE5wC682YKhNsxnfV5ShQ@mail.gmail.com> <201504131200.00384.davemgarrett@gmail.com> <874mokug5y.fsf@alice.fifthhorseman.net> <201504131325.20590.davemgarrett@gmail.com> <871tjoue8v.fsf@alice.fifthhorseman.net> <D1517606.23FD5%uri@ll.mit.edu> <87vbgzubj6.fsf@alice.fifthhorseman.net> <20150413185505.GA1016@LK-Perkele-VII> <87mw2bu596.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <87mw2bu596.fsf@alice.fifthhorseman.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/kJEuhyjbNDNnlPAOr36vYpMNDK8>
Cc: tls@ietf.org
Subject: Re: [TLS] Negotiate only symmetric cipher via cipher suites (was: Ala Carte Cipher suites - was: DSA should die)
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: Tue, 14 Apr 2015 05:49:08 -0000

On Mon, Apr 13, 2015 at 04:45:25PM -0400, Daniel Kahn Gillmor wrote:
> On Mon 2015-04-13 14:55:05 -0400, Ilari Liusvaara wrote:
> > On Mon, Apr 13, 2015 at 02:29:49PM -0400, Daniel Kahn Gillmor wrote:
> >
> >> What do you think an implementation should do when a peer tries to
> >> negotiate the combination above?  Require an RSA-PSS signature from the
> >> server over some material derived in part from the PSK key agreement
> >> mechanism?
> >
> > To me it seems like that combo is quite insecure, unless one handles it as
> > a special case (in which case it is just equivalent to PSK in security,
> > just wastes time with a certificate).
> 
> Can you explain why it's "quite insecure"?
> 
> It doesn't seem any worse than normal (non-DHE) PSK other than the cost
> of signing and verifying.  I suppose that it also proves that an
> attacker has access to both the PSK and the secret key material
> belonging to the cert.

If it is really PSK with RSA-PSS, then it is semi-OK (but see below).

The problem here is:
- If PSK is considered authentication algorithm, then pure PSK has NULL
  key agreement. Which is quite dangerous with any authentication that
  can't provode key material (like any signature algorithm).
- If PSK is considered key agreement algorithm, then what is DHE-PSK
  (since DHE is key agreement).

> So, for example, you could give a dozen clients the same PSK (maybe to
> provide them with indistinguishability from each other to a network
> observer?), but clients that want to be sure they're talking to the
> server (instead of each other) can rely on the server's cert.

Due to how key derivation works with pure PSK, the clients can MITM
each other. And if it is supposed to be DHE-PSK+RSA-PSS, wouldn't
something like using HMAC for client auth work?

> > As list, the key exchange methods TLS v1.2 actually supports (after merging
> > some non-significant distinctions) are:
> > - RSA [going away]
> > - RSA_EXPORT [you have deimplemented this already, right?]
> > - DH_CERT [going away]
> > - DHE_CERT [supported]
> > - DHE_ANON [???]
> > - KRB5 [going away]
> > - PSK [???]
> > - DHE_PSK [???]
> > - RSA_PSK [going away]
> > - SRP [???]
> > - SRP_CERT [???]
> 
> I think this list mixes up key exchange with authentication, which was
> what Dave was trying to tease apart.  For key exchange, there is no
> difference between DHE_CERT and DHE_ANON and DHE_PSK -- they're all DHE.
> the ANON/CERT/PSK parts would be negotiated separately in the
> authentication side of things (via the signature_algorithms extension).

TLS v1.2 also has PSK identity hint, in which server first gives a hint
before client selects the final identity (which obviously is 2RTT process).

To me it seems (DHE-)PSK is quite special.

> (And if we're using supported_groups, the distinctions between different
>  flavors of DHE (FFDHE2048, ECDHEP256, ECDHEX25519, etc) are hardly
>  non-significant, but i guess that's a slightly different discussion.)

What would the difference from TLS standpoint be (apart from some keysize
parameters)?


-Ilari