IETF Logo Mail Archive

Re: [TLS] TLS and KCI vulnerable handshakes

Martin Thomson <martin.thomson@gmail.com> Tue, 11 August 2015 21:06 UTC

Return-Path: <martin.thomson@gmail.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 76FC71B2AB0 for <tls@ietfa.amsl.com>; Tue, 11 Aug 2015 14:06:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 OGeKMxY-R8Xr for <tls@ietfa.amsl.com>; Tue, 11 Aug 2015 14:06:34 -0700 (PDT)
Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B57E71B2AAE for <tls@ietf.org>; Tue, 11 Aug 2015 14:06:33 -0700 (PDT)
Received: by lbcbn3 with SMTP id bn3so26163387lbc.2 for <tls@ietf.org>; Tue, 11 Aug 2015 14:06:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o6C1K1UHmcxFOAAp3S8eb+8BJcIkUtd/aGcHu2Eismo=; b=B1Yk7P65mCQfTPYphdUbla452397Vcbukvu+3uE1xu8IxEveRPqzTPNsYnGgKTYU1v faZX56hDx7nc2ZD/aZSJIiMqADjM4sxhjUcJ6/yQR/XK216YIAQ2Hs2ae26+WCzfmJnk 3vEHDnrz3EqmFW1jTABQhUYDYV0UUjrz4I5ZohltrCy7Oyks/UsL+I1JvsUKZQdaupyz bcfP5IDqRDPCZ2ZFyeD7HvW5nU4vXfk+0gqBN0Oqa1BeL3pWk69JnPlb7We0XcB3kpr4 ZFt9p8n3B5Rpi517cMJhMq/HIVhpl7iLd5qtZvagx4t+p9wau+lc5b9GkiW9nUQh6fs7 HUrg==
MIME-Version: 1.0
X-Received: by 10.152.7.37 with SMTP id g5mr28997606laa.101.1439327192008; Tue, 11 Aug 2015 14:06:32 -0700 (PDT)
Received: by 10.25.162.198 with HTTP; Tue, 11 Aug 2015 14:06:31 -0700 (PDT)
In-Reply-To: <20150811190544.GA13734@LK-Perkele-VII>
References: <55C8CD7A.7030309@rise-world.com> <9A043F3CF02CD34C8E74AC1594475C73F4AD80F3@uxcn10-5.UoA.auckland.ac.nz> <9690882F-B794-4D1D-973F-DE7F90120CC3@gmail.com> <CABkgnnXruou6BbgZK8vWUeyb-gW5OTSZKPwPVPwZ826usNz9RA@mail.gmail.com> <20150811190544.GA13734@LK-Perkele-VII>
Date: Tue, 11 Aug 2015 14:06:31 -0700
Message-ID: <CABkgnnXnx7Fvt8oXNwMC3oLtXD4A4gFw6j-LWWuSkS3BasWqrg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/kD4Qy2g4QjjaujJBkIokvKKm8R8>
Cc: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>, Clemens Hlauschek <clemens.hlauschek@rise-world.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS and KCI vulnerable handshakes
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: <https://mailarchive.ietf.org/arch/browse/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, 11 Aug 2015 21:06:35 -0000

On 11 August 2015 at 12:05, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
>> I don't see how that would work.  A client that understands the cert
>> to be ECDSA won't pair the key with the server's ECDH share, they will
>> sign the session transcript with it.
>
> a) ECDSA certs are usable for ECDH (modulo KeyUsage) because there is
> no ECDSA-specific keytype in X.509.

Maybe I should have been clearer.  The certificate might not include a
(strong) signal that allows the client to distinguish between ECDSA
and fixed ECDH, but the client might be configured with that
knowledge.

I checked NSS and there doesn't seem to be any way that it could be
coerced into using the (EC)DH pair from a client certificate in a key
exchange.  Even though it supports some fixed (EC)DH suites.

NSS (incorrectly) adopts the posture that _ECDH_ suites are
half-static: the server share is in the certificate, but the client
side is fully ephemeral.  This is clearly in violation of RFC 5246,
Section 7.4.7 and RFC 4492, Section 3.2. I'm not going to worry about
that right now :)

v2.23.0 | Report a Bug | By Email