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> Sat, 11 February 2017 01:49 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 BF2B2128874 for <tls@ietfa.amsl.com>; Fri, 10 Feb 2017 17:49:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level:
X-Spam-Status: No, score=-2.01 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 shG6fZyInOhu for <tls@ietfa.amsl.com>; Fri, 10 Feb 2017 17:49:19 -0800 (PST)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0094.outbound.protection.outlook.com [104.47.37.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B3321295E8 for <tls@ietf.org>; Fri, 10 Feb 2017 17:49: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=Q4Ms0cJfEYJdB4UeJmNVSvgS1YMHSvwg24A4h981Pzc=; b=kJzxt2AvtyfeRt6dWADnhE+CiHrHZ7bBxP9xx2o/MdzMnyn9J/rsNqyWIOaiXimBfHz/Kg+W2kXC4iI4jmhqRzMZOhBuPv8y21RnTDGzX+PQlbx+z/GiKLyXpKWsHToOxJOQEKqsmg9ycV7DOEMcSAJMpNpk2htUFh2Osd8Mvs0=
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; Sat, 11 Feb 2017 01:49:16 +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.026; Sat, 11 Feb 2017 01:49:17 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Sam Scott <sam.scott89@gmail.com>, Eric Rescorla <ekr@rtfm.com>
Thread-Topic: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18
Thread-Index: AQHSg5t3h43MYmEytkO14a3ComoThqFifUUAgAAoHQCAAA7VgIAAA92AgABRxbA=
Date: Sat, 11 Feb 2017 01:49:17 +0000
Message-ID: <CY1PR0301MB0842B2E974E5E5AF94EF706A8C470@CY1PR0301MB0842.namprd03.prod.outlook.com>
References: <CABdrxL53Fd7tY6+qF-p=acvCDa=hvbPov83XSd-Y8-gB3c33Ag@mail.gmail.com> <20170210172224.GA22473@LK-Perkele-V2.elisa-laajakaista.fi> <dade38c1-e5a3-4058-9291-c94ea14dfe91@gmail.com> <CABcZeBPxid8W-r4uUXewFg+cYtUssqQLOcjJ=2ueuyVqj4qZUA@mail.gmail.com> <a7d4852e-b74c-9a29-5872-e0b1e2bb31a5@gmail.com>
In-Reply-To: <a7d4852e-b74c-9a29-5872-e0b1e2bb31a5@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:9::1d2]
x-ms-office365-filtering-correlation-id: 94c03b14-044b-49ee-22fd-08d45220307d
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:Qpu408U6i5+JPr6oySGlQ3Q782kbgzuzbVJyJO0NWxOvZWqhW4Rt46HWtJ4894bF+ziWuahkDzSLrWdtaoiKa6pvScrxsmYdaZH3lcgUYfUg6nLWmo03rmBIxVjM5Lg/URmAcBNiuueLkRq7HLyBEvMCq0U/PP6hRQK804vxfPOx9vb3Fqz5YZ9Kx9fFGjimrTzW7UxA3UJKLzHDH/l9r8HFW9Z4ADo17N8EiWb+Opu3BrUVDxq4Bjp2D1MbC8TWHNhD5JJpk5EjLJ6n1NKBjO+jEvi/9vd+/A7oS0nzPfrLk52Z6MTnar+qOwu/OUT1jmlSnIWZlndTuG9aT3SYSLYW8nJJqJ32AKP5FjDLibNRF9YhoVMwKHnh4O4FBBYF1QfcDOKrpGII2kpn99w1aDcVjN8CwJqMCHYWiXQRZrg9+rPk53R4dILifxnLKjR3vE5/6F5LMBeEFdnhrg1XYAhI6bO0AEg3JIeSDfuFPVGbKJkkdLrrgLNJRRnyUya6ol6xMXliWzpNPX7mg0CkbvK4zWG8BwiTUkn8PvkxnGw=
x-microsoft-antispam-prvs: <CY1PR0301MB08444809C935330B13504DC88C470@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)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123564025)(20161123558025)(20161123560025)(20161123555025)(6072148)(6042181); SRVR:CY1PR0301MB0844; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0844;
x-forefront-prvs: 0215D7173F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(377454003)(189002)(24454002)(51914003)(5005710100001)(10290500002)(10090500001)(97736004)(122556002)(50986999)(76176999)(54356999)(92566002)(8990500004)(101416001)(2900100001)(6306002)(6246003)(55016002)(99286003)(38730400002)(53546003)(25786008)(54896002)(6436002)(606005)(5660300001)(7696004)(2950100002)(53936002)(9686003)(236005)(229853002)(189998001)(33656002)(106356001)(6506006)(106116001)(105586002)(39060400001)(77096006)(86612001)(81156014)(2906002)(8676002)(81166006)(102836003)(6116002)(790700001)(8936002)(86362001)(4326007)(3280700002)(7906003)(74316002)(3660700001)(93886004)(68736007)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0844; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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_CY1PR0301MB0842B2E974E5E5AF94EF706A8C470CY1PR0301MB0842_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2017 01:49:17.0940 (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/FJSMsqeSr8obt51uWJ_PrAAVGP0>
Cc: "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: Sat, 11 Feb 2017 01:49:23 -0000
What about Eric’s other point: Ø I am not sure that the regular TLS handshake guarantees these Ø properties either. The reason is that the server is permitted to Ø send data prior to receiving the client's second flight (0.5 RTT Ø data). With the server sending data prior to receiving the client’s second flight, it seems that property B is not there when using in-handshake client authentication as well? Cheers, Andrei From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Sam Scott Sent: Friday, February 10, 2017 12:53 PM To: Eric Rescorla <ekr@rtfm.com> Cc: tls@ietf.org Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18 Hi Ekr, That's a good summary of the situation. Indeed we weren't previously considering TLS as able to enforce the ordering of messages which does seem to mitigate our scenario for property A. We haven't really had a chance to take that into consideration for property B, but at a glance it does still seem to be an issue. As mentioned in my other email, one scenario we encountered this was if (using your message numbering as reference) messages 5 or 9 happened to be a NewSessionTicket. In this case, the client might be under the impression that they have a session ticket for a mutually authenticated channel. Thanks, Sam On 10/02/17 20:39, Eric Rescorla wrote: Cas, Sam, I thought I understood your concern here but maybe I don't. Say we have the following sequence of messages 1. C->S: ClientHello 2. S->C: ServerHello...ServerFinished 3. C->S: ClientFinished 4. C->S: App message 5. S->C: App message 6. S->C: CertificateRequest 7: C->S: Certificate...Finished 8: C->S: App message 9: S->C: App message As you indicate, there's some ambiguity from the client's perspective (property B) about whether messages 5 and 9 were sent by the server prior to or after receiving message 7, and also message 8. This ambiguity exists even without an attacker and may or may not be resolved at the application layer. An attacker can exploit this ambiguity by holding messages 7 and 8 and (as long as application semantics permit this). Where I get confused is about property A. As I understand your claim, an attacker can hold message 7 but deliver message 8 and therefore, even if the client knows that 9 was in response to 8, he doesn't know that the server received 7. As Ilari says, I don't believe that this is correct because TLS enforces message ordering. I agree that the specification doesn't explicitly say this, but it's implicit in the processing rules via the following: 1. The encryption for each TLS record depends on the record sequence number (RSN). 2. Records do not carry their RSN, so when you decrypt a message, you must use the last RSN + 1 3. When you fail to decrypt a message (which is what happens if you have the wrong RSN) you are required to tear down the connection (https://tlswg.github.io/tls13-spec/#record-payload-protection). For this reason, if the attacker removes message 7, then 8 will not be decryptable, and so ordering is preserved. As Ilari says, this isn't true in DTLS 1.3 which we'll presumably have to deal with one way or the other before standardization (my plan would be just to forbid post-handshake auth). Do you disagree with this? If so, perhaps you could explain. -Ekr P.S. I am not sure that the regular TLS handshake guarantees these properties either. The reason is that the server is permitted to send data prior to receiving the client's second flight (0.5 RTT data). See: https://tlswg.github.io/tls13-spec/#protocol-overview On Fri, Feb 10, 2017 at 11:45 AM, Sam Scott <sam.scott89@gmail.com<mailto:sam.scott89@gmail.com>> wrote: Hi Ilari, Thanks for the comments. Assuming the client sends a valid certificate that the server accepts, then the server cannot finish the handshake or begin processing incoming application data until authenticating the client. This *almost* gives us property (A). In practice, the client is aware that the server has successfully authenticated since the protocol continues. In the case that the server has implemented the reject option (rejecting a certificate but still continuing), and indeed rejects the certificate, then the server should send an alert message (or NAK of some form) for the property to hold in the initial handshake. However, even if we take the certificate reject + continue scenario into account for the initial handshake, then it is clear that this decision can only be made by the server in the initial handshake, while in the post-handshake client auth, an attacker can decide this (by dropping the message). The reason we don't believe an explicit ACK is needed is because upgrading to a new pair of keys explicitly provides this. Specifically, the client will send all subsequent data to the server under a new key. The server will not be able to decrypt this data until they receive the client authentication messages and upgrade the keys. This can be strengthened if the client's updated write key is computed using the authentication messages. We agree that TLS enforcing ordering of messages provides similar guarantees. However, we are analysing the specification as it is presented, which does not guarantee this. Thanks, Sam _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
- [TLS] Awkward Handshake: Possible mismatch of cli… Cas Cremers
- Re: [TLS] Awkward Handshake: Possible mismatch of… Ilari Liusvaara
- Re: [TLS] Awkward Handshake: Possible mismatch of… Sam Scott
- Re: [TLS] Awkward Handshake: Possible mismatch of… Andrei Popov
- Re: [TLS] Awkward Handshake: Possible mismatch of… Sam Scott
- Re: [TLS] Awkward Handshake: Possible mismatch of… Eric Rescorla
- Re: [TLS] Awkward Handshake: Possible mismatch of… Victor Vasiliev
- Re: [TLS] Awkward Handshake: Possible mismatch of… Eric Rescorla
- Re: [TLS] Awkward Handshake: Possible mismatch of… Sam Scott
- Re: [TLS] Awkward Handshake: Possible mismatch of… Eric Rescorla
- Re: [TLS] Awkward Handshake: Possible mismatch of… Andrei Popov
- Re: [TLS] Awkward Handshake: Possible mismatch of… Sam Scott
- Re: [TLS] Awkward Handshake: Possible mismatch of… Eric Rescorla
- Re: [TLS] Awkward Handshake: Possible mismatch of… Cas Cremers
- Re: [TLS] Awkward Handshake: Possible mismatch of… David Wong
- Re: [TLS] Awkward Handshake: Possible mismatch of… David Benjamin
- Re: [TLS] Awkward Handshake: Possible mismatch of… Ilari Liusvaara
- Re: [TLS] Awkward Handshake: Possible mismatch of… David Wong
- Re: [TLS] Awkward Handshake: Possible mismatch of… Andrei Popov
- Re: [TLS] Awkward Handshake: Possible mismatch of… Martin Thomson
- Re: [TLS] Awkward Handshake: Possible mismatch of… David Wong
- Re: [TLS] Awkward Handshake: Possible mismatch of… Martin Rex
- Re: [TLS] Awkward Handshake: Possible mismatch of… Cas Cremers
- Re: [TLS] Awkward Handshake: Possible mismatch of… Andrei Popov
- Re: [TLS] Awkward Handshake: Possible mismatch of… David Wong
- Re: [TLS] Awkward Handshake: Possible mismatch of… David Benjamin
- Re: [TLS] Awkward Handshake: Possible mismatch of… Andrei Popov
- Re: [TLS] Awkward Handshake: Possible mismatch of… Martin Rex