Re: [TLS] TLS and KCI vulnerable handshakes

Martin Thomson <martin.thomson@gmail.com> Tue, 11 August 2015 23:59 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 B9B261A01A8 for <tls@ietfa.amsl.com>; Tue, 11 Aug 2015 16:59:38 -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 DjeikaDumRnm for <tls@ietfa.amsl.com>; Tue, 11 Aug 2015 16:59:37 -0700 (PDT)
Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (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 1CFA11A0120 for <tls@ietf.org>; Tue, 11 Aug 2015 16:59:37 -0700 (PDT)
Received: by lahi9 with SMTP id i9so563135lah.2 for <tls@ietf.org>; Tue, 11 Aug 2015 16:59:35 -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=OmoMWActkM0vV2KlgYjgtxbGf1hgf9gA7WeldD4YhG8=; b=DYv/iP2flGws8l9OB0j6CnmKbgC5YUQEzpn+ha1eCkd2V8q5BjOd5jWm7bDuPAV/TI wLTGiKlJXJ+j8mGAxLaij2NId1gsr07hRHYdY7bXabIy5zr3nQqcIU+iKScDHeM7kFI7 INbvdUnp/7x+skPK0eY5mZ8G6AhTUjlm42B05iHitfvCMIFlzt4Y3D2Lnd8tQwm0Yi+i WN1+jysauYKk4SRi+KnmZlChnjv+e8PvjH9eTt8RSLeDdU/4jLqcEnGjUSDHUJgr9rs+ d5+Z3VuWikI7Z8vonGia/vqYUHAFFUnbU43CJlhuhtXjdTtnjYooL9ZJ9CvEDWUSl7G5 iIgQ==
MIME-Version: 1.0
X-Received: by 10.112.24.163 with SMTP id v3mr25107682lbf.101.1439337575413; Tue, 11 Aug 2015 16:59:35 -0700 (PDT)
Received: by 10.25.162.198 with HTTP; Tue, 11 Aug 2015 16:59:35 -0700 (PDT)
In-Reply-To: <55CA8783.8060201@rise-world.com>
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> <CABkgnnXnx7Fvt8oXNwMC3oLtXD4A4gFw6j-LWWuSkS3BasWqrg@mail.gmail.com> <55CA8783.8060201@rise-world.com>
Date: Tue, 11 Aug 2015 16:59:35 -0700
Message-ID: <CABkgnnX9pGxwPFvPw5VUUst7-DX7fAbPC90bAz1EztxZ7K9KpA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Clemens Hlauschek <clemens.hlauschek@rise-world.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/adkCS9ZzaSIChd1H6R7NV1PWSso>
Cc: Karthikeyan Bhargavan <karthik.bhargavan@gmail.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 23:59:38 -0000

On 11 August 2015 at 16:38, Clemens Hlauschek
<clemens.hlauschek@rise-world.com> wrote:
>> 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.
>
> There is no difference between an ECDH and an ECDSA, apart from
> (possibly) the KeyUsage Extension.

I'l try again.  Even if the certificate does not include that signal,
the software that accepts that signal might make assumptions or have
configuration that cause it to only be used in one way or another.
See NSS.

>> 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 :)
>
> Please elaborate. I do not see how this half-static behaviour
> constitutes any violations of the mentioned RFCs.

Both the above cited sections say very clearly that for fixed (EC)DH
cipher suites the client where the client has a fixed (EC)DH
certificate, the client MUST send an empty ClientKeyExchange.

Of course, you might say that this is simply a consequence of not
supporting fixed (EC)DH for client authentication, and then it's not
technically in violation.  The value of the ClientCertificateType from
the CertificateRequest is likely important here, but that field is
systematically ignored in practice (NSS ignores it).