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

Andrei Popov <Andrei.Popov@microsoft.com> Wed, 15 February 2017 20:01 UTC

Return-Path: <Andrei.Popov@microsoft.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 4AFB5129B31 for <tls@ietfa.amsl.com>; Wed, 15 Feb 2017 12:01:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.887
X-Spam-Level:
X-Spam-Status: No, score=-3.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 omKe-7kvPtq6 for <tls@ietfa.amsl.com>; Wed, 15 Feb 2017 12:01:37 -0800 (PST)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0128.outbound.protection.outlook.com [104.47.36.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 533F3129AA0 for <tls@ietf.org>; Wed, 15 Feb 2017 12:01:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Q4B0jZ80BrBuLGyMqeQYKIe4187ZhPuXZ9ajCevgT4s=; b=T3ePiDjjaz152tr4WNhCdRI2UHYMUArrUdQ9UVilVR8hF3ZkGj+O3bNgQBc56pugddFbiKc9Et7klQJ9IG5XkVFq1xVnex7tSeeQ0y6ce8I4TjV+iI1FPrBL8I0QM5xrmcFlyGKsjpgtLXGETCZiv9QlKNgB0m7MwgfPH9IvuWY=
Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0844.namprd03.prod.outlook.com (10.160.163.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Wed, 15 Feb 2017 20:01:17 +0000
Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0888.030; Wed, 15 Feb 2017 20:01:18 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: David Benjamin <davidben@chromium.org>, David Wong <davidwong.crypto@gmail.com>
Thread-Topic: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18
Thread-Index: AQHShfVLh43MYmEytkO14a3ComoThqFooDUAgAAGc4CAAAlfgIAAHR8AgAENgQCAAItuMIAAFxmAgAAA9wCAAAIHYA==
Date: Wed, 15 Feb 2017 20:01:17 +0000
Message-ID: <CY1PR0301MB08424704E884306DA56402268C5B0@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> <local-dd07e89e-e724@nylas-mail.nylas.com> <CAF8qwaB+CJof9sk7+Yt=iFdPeA6dTLeph9hsQ1d=HUCOHg2y5w@mail.gmail.com>
In-Reply-To: <CAF8qwaB+CJof9sk7+Yt=iFdPeA6dTLeph9hsQ1d=HUCOHg2y5w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com;
x-originating-ip: [2001:4898:80e8:a::1d2]
x-ms-office365-filtering-correlation-id: da620d03-a5a1-441e-b7c5-08d455dd67a1
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0301MB0844;
x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0844; 7:moubxxp0vfikNYBtQlgXQYlY4uyA/r4nd/ra5AEcJfbzEfRsx3FcIWnq2R7nLTXf57nIjTFsKhZygbSNzVy6YGm6NwOD6Vze+bbq2kAVakb/Dfnn7nImeREsqkGY6ztz4NNJdgBqZOOn6iE/w4hrfNJtsAP5wrYq98fMOMFsm1r7fU3GP8PJk9tHnvCULCHwv0NMQESUQ6zHQBmeeTZR9lhDdY18ap4d2t3TybbXGeMruPw3okn82xEdY/DQC48yo8RkO5EflJ3juRatxY4spwh/KHvlvAaeY/kUYjcCr5AtKHFFY+8nmvLGr8zb952MRXkbAW06sosNbIHulzWXuNu3US/bCHNpIg5kTjWoufY=
x-microsoft-antispam-prvs: <CY1PR0301MB0844A6B809DCEFA044E661558C5B0@CY1PR0301MB0844.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123564025)(20161123558025)(20161123560025)(20161123555025)(6072148); SRVR:CY1PR0301MB0844; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0844;
x-forefront-prvs: 021975AE46
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39410400002)(39860400002)(39850400002)(39840400002)(189002)(199003)(377454003)(24454002)(101416001)(105586002)(8936002)(106116001)(7736002)(3660700001)(6506006)(81166006)(4326007)(97736004)(790700001)(54356999)(102836003)(81156014)(76176999)(68736007)(2906002)(6116002)(6436002)(106356001)(50986999)(3280700002)(33656002)(8676002)(77096006)(25786008)(606005)(2900100001)(9686003)(55016002)(236005)(54906002)(10090500001)(99286003)(7696004)(6306002)(92566002)(229853002)(189998001)(38730400002)(86612001)(2950100002)(93886004)(53936002)(54896002)(5005710100001)(8990500004)(5660300001)(86362001)(122556002)(74316002)(6246003)(7906003)(19609705001)(389900002)(39060400002)(10290500002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0844; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB08424704E884306DA56402268C5B0CY1PR0301MB0842_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2017 20:01:17.8695 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0844
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/0c_qF8lTALWQtz0Aoa4WxlR-Co0>
Cc: Cas Cremers <cas.cremers@cs.ox.ac.uk>, "tls@ietf.org" <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 20:01:40 -0000

I agree with David: a different client auth mechanism is in the works for HTTP/2.

Cheers,

Andrei

From: David Benjamin [mailto:davidben@chromium.org]
Sent: Wednesday, February 15, 2017 11:52 AM
To: David Wong <davidwong.crypto@gmail.com>; Andrei Popov <Andrei.Popov@microsoft.com>
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

On Wed, Feb 15, 2017 at 2:49 PM David Wong <davidwong.crypto@gmail.com<mailto:davidwong.crypto@gmail.com>> wrote:
On Feb 15 2017, at 7:27 pm, Andrei Popov <Andrei.Popov@microsoft.com<mailto: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.

Post-handshake auth exists basically entirely to service HTTP/1.1 reactive client certificate which was previously hacked on via renegotiation. I think we should not make this feature any more complicated than absolutely necessary to support this mode, and we should not add more bells and whistles to it to encourage further use.

For the HTTP/1.1 use case, this is not necessary because it's reasonable for client/server to agree that the server will not send any more data for that request until it has processed the client's authentication messages.

David