IETF Logo Mail Archive

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

David Wong <davidwong.crypto@gmail.com> Wed, 15 February 2017 19:49 UTC

Return-Path: <davidwong.crypto@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609AC129A7E for <tls@ietfa.amsl.com>; Wed, 15 Feb 2017 11:49:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.598
X-Spam-Level:
X-Spam-Status: No, score=-1.598 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, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 E3_ErlDH09ja for <tls@ietfa.amsl.com>; Wed, 15 Feb 2017 11:49:02 -0800 (PST)
Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 2CAE5129A7D for <tls@ietf.org>; Wed, 15 Feb 2017 11:49:02 -0800 (PST)
Received: by mail-wm0-x244.google.com with SMTP id r18so9852797wmd.3 for <tls@ietf.org>; Wed, 15 Feb 2017 11:49:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:from:to:cc:in-reply-to:references:subject:message-id :date:content-transfer-encoding:mime-version; bh=o3pQrmKdFk4hTLtIg/IpxQe+vUkM516qE0afGaDzUhg=; b=txNVY3co9dnBuAJ8lE4fFbZ3JsMu+c9duDRf9HSiuUFtSvSMMjr6Lfv/qWJRsr3CiE 4H5asTdqcVtJp0Rd2M3GcDT39eUG7tL98c2j46fsfe3hjRoK1siG7g5o/mbAZSyFSDjU q6pXkgtI1JQcjGELyV4cufgqjyT+fl234RpTlU4VIX4Ti+T579X/XKsy44zKa3iVQXyp hXjE7w+AqAk6WWxyPD8cdHZe7pWD6dh5g7IgfgWRHQsDlPJENkOibWChg7HyiOVABmrT D7Nf76xY2ZVJH9ejDpIdeKmF9RkGGqXn15oVCfxow+R8w2Grn4osNbxZUtbB9kYCl4vf 9D9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:from:to:cc:in-reply-to:references :subject:message-id:date:content-transfer-encoding:mime-version; bh=o3pQrmKdFk4hTLtIg/IpxQe+vUkM516qE0afGaDzUhg=; b=tRh1EO8bUOY5vtx44k/geIjtnTfZaBAImjgkbMd4zFOu1CpZmwZdrWIt69ySGtQG26 KrVu7cCahaNYF82ES4MuqxtIBbbcQ8PsRN5CKtdiTRIsZC913cIdoIyC1AiGaMIDV3ue +l2ZUNpoWdUYc4wugcw1P84jJmKKNP9gaTISp8jCS4u/IGUIFy0+B/7I8Nk1pL2trQ+3 tlF0cmGPHtAqX6la6fYMUEXVl92MQmc2NLxTQfYQUP+RfsoKSHowuScxck46ci/9W2E6 4TC9uihrQBMD/Y8zuuw8xrB5EP4e9oZeABHu6KDPXoKtG/7pociTIcZwHziyQVulalaX nTDQ==
X-Gm-Message-State: AMke39lJtyCJgvbHOnsIOg024g6jRbN6Tc1BEVoRsOk+elpV4mGrYebfTqhlSgePTzG/DA==
X-Received: by 10.28.188.213 with SMTP id m204mr9288437wmf.0.1487188140608; Wed, 15 Feb 2017 11:49:00 -0800 (PST)
Received: from little-david.home (LFbn-1-9943-152.w86-202.abo.wanadoo.fr. [86.202.61.152]) by smtp.gmail.com with ESMTPSA id p7sm6050283wrc.34.2017.02.15.11.48.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Feb 2017 11:49:00 -0800 (PST)
Content-Type: text/html
User-Agent: NylasMailer-K2
From: David Wong <davidwong.crypto@gmail.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
In-Reply-To: <CY1PR0301MB0842A7DE42636FD4FAD393F18C5B0@CY1PR0301MB0842.namprd03.prod.outlook.com>
References: <CABdrxL6qupAu+Ztxw7BU1e-eoy-kfJKRQq+ZZyoKokXHNZEoZQ@mail.gmail.com> <local-bdf4ca0e-d529@nylas-mail.nylas.com> <CAF8qwaBQOfW68BcyG_d6wNsGTT+e6XajEYd0OSjjDekEQOD2mw@mail.gmail.com> <local-a70c902a-5994@nylas-mail.nylas.com> <CY1PR0301MB08426CD005E640B9865D1BC38C580@CY1PR0301MB0842.namprd03.prod.outlook.com> <local-4715c433-f49c@nylas-mail.nylas.com> <CY1PR0301MB0842A7DE42636FD4FAD393F18C5B0@CY1PR0301MB0842.namprd03.prod.outlook.com>
Message-ID: <local-dd07e89e-e724@nylas-mail.nylas.com>
Date: Wed, 15 Feb 2017 19:48:59 +0000
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/UZ32-bPkFsIcIqWEiKGyN56Z0wI>
Cc: Cas Cremers <cas.cremers@cs.ox.ac.uk>, tls@ietf.org
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 15 Feb 2017 19:49:03 -0000

On Feb 15 2017, at 7:27 pm, Andrei Popov <Andrei.Popov@microsoft.com> wrote: 

Yes, I agree that it is useful to mention this in the spec.

 


It would be nice is to have two different PRs solving this issue. One mentioning this as a potential issue that the application must be aware of. I've seen things like that for example in rfc 5746: https://tools.ietf.org/html/rfc5746#section-5

>  While this extension mitigates the man-in-the-middle attack described in the overview, it does not resolve all possible problems an application may face if it is unaware of renegotiation. For example, during renegotiation, either the client or the server can present a different certificate than was used earlier. This may come as a surprise to application developers (who might have expected, for example, that a "getPeerCertificates()" API call returns the same value if called twice), and might be handled in an insecure way.

A second PR could try to tackle this by adding a new message, for example an "AcknowledgeClientAuthentication" message that the server would send to confirm (or not) the validation of the client certificate. I think this would add a bit of complexity for less "surprise". I'm not too keen on this, and I think this could be added as an extension instead, but I think it would be nice to have to see if it integrates nicely in the current draft.

David

v2.23.0 | Report a Bug | By Email