[Lurk] lurk -- February 2018 draft; comments

<i.boureanu@surrey.ac.uk> Thu, 24 May 2018 14:40 UTC

Return-Path: <i.boureanu@surrey.ac.uk>
X-Original-To: lurk@ietfa.amsl.com
Delivered-To: lurk@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6A66D12DA6C for <lurk@ietfa.amsl.com>; Thu, 24 May 2018 07:40:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, 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=surrey.ac.uk
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id zWIdK9RUCIwz for <lurk@ietfa.amsl.com>; Thu, 24 May 2018 07:39:58 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0702.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::702]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4B761271DF for <lurk@ietf.org>; Thu, 24 May 2018 07:39:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=surrey.ac.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QUNexwN3Zjf16LYBwhQx3XxC56XZVZiJKDi7iwfdNGI=; b=Y8/DzyJlQ0QJ6BtY1pYZVfcsfvhLJlyzqUnQ6oAgiMk27f7OoDbDLgzcBPLQDLfsu+EXXuzZF15CuICZbyvw9GsvWBf7zG5aI6LJHedV76Dylo5/MgeMHIynwgpYUvsnJx7nMD2hUpGEP3wtI6zSdcNAp32KHizy8RYLNbcRsOQ=
Received: from VI1PR06MB1216.eurprd06.prod.outlook.com ( by VI1PR06MB1406.eurprd06.prod.outlook.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.776.16; Thu, 24 May 2018 14:39:54 +0000
Received: from VI1PR06MB1216.eurprd06.prod.outlook.com ([fe80::7832:9d78:6d76:eb5a]) by VI1PR06MB1216.eurprd06.prod.outlook.com ([fe80::7832:9d78:6d76:eb5a%14]) with mapi id 15.20.0776.019; Thu, 24 May 2018 14:39:54 +0000
From: <i.boureanu@surrey.ac.uk>
To: <lurk@ietf.org>
Thread-Topic: lurk -- February 2018 draft; comments
Thread-Index: AQHT820UMqcHpmmDM0WtAqG8ccGRTQ==
Date: Thu, 24 May 2018 14:39:54 +0000
Message-ID: <38CE10A0-6703-4465-9BD0-153787ED2039@surrey.ac.uk>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-mailer: Apple Mail (2.3273)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=i.boureanu@surrey.ac.uk;
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR06MB1406; 7:Xcm24pvYw811K13rfEbiTSs0GPTH7+qDGwRi/igbeWDUPeVoK19pHNglkmsjiIiH8DVmgTYTWvhE/NarFcjdjYXYMotyDdv7uXtNNUG2iN/pmOZ0Gl5GG67dzfTKMBAjbp4hJPWnCp8kmrTrIJPIA5XV7+1mNjEQYGntRVtbygPNUx2W9JIDboe9H62uX0VwfTLbSR9mRywWHaZtaCJcv4naXqrfAtL91xG6aNBI9nwP4mSBu3nFzMAbkUXi7MDv
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:VI1PR06MB1406;
x-ms-traffictypediagnostic: VI1PR06MB1406:
x-microsoft-antispam-prvs: <VI1PR06MB1406CB40F4CF8EEA27570F30AE6A0@VI1PR06MB1406.eurprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(116415991822766)(148501403981450)(17755550239193);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:VI1PR06MB1406; BCL:0; PCL:0; RULEID:; SRVR:VI1PR06MB1406;
x-forefront-prvs: 0682FC00E8
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(39380400002)(39860400002)(366004)(376002)(199004)(189003)(413944005)(8676002)(81156014)(476003)(2616005)(486006)(82746002)(6486002)(8936002)(6116002)(3846002)(81166006)(5640700003)(33656002)(6436002)(3280700002)(106356001)(14454004)(3660700001)(25786009)(2906002)(97736004)(7736002)(478600001)(2351001)(2900100001)(45080400002)(50226002)(606006)(105586002)(1730700003)(68736007)(5660300001)(86362001)(11609785009)(1860700003)(102836004)(57306001)(6306002)(6506007)(6512007)(54896002)(53936002)(74482002)(236005)(6916009)(53376002)(99286004)(26005)(316002)(53366004)(83716003)(786003)(2501003)(59450400001)(5250100002)(66066001)(186003)(36756003)(9984715007)(4068875011); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR06MB1406; H:VI1PR06MB1216.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: surrey.ac.uk does not designate permitted sender hosts)
x-microsoft-antispam-message-info: NfnuNaeIeeDVpAcljr6DaniTbYatQP9EWzjA6r4AOf6kxi2eWrDIE1fwJ0URe+e13kwVtB8IC75i/ItXhKrmfhPwPBhJg35H7fTTVciOn2o/iIM8vcvZsb68OOBEkK3vEsar+wgjNgx+h5Uf5fi1hXQmmWiUAq0U+2lc7BiB72GnoUUS0Cix+E9L5EbBt3af
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_38CE10A0670344659BD0153787ED2039surreyacuk_"
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 3f3d9b71-7189-46f2-a820-08d5c1843721
X-OriginatorOrg: surrey.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: 3f3d9b71-7189-46f2-a820-08d5c1843721
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2018 14:39:54.7277 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6b902693-1074-40aa-9e21-d89446a2ebb5
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR06MB1406
X-MS-Exchange-CrossPremises-AuthAs: Internal
X-MS-Exchange-CrossPremises-AuthMechanism: 04
X-MS-Exchange-CrossPremises-AuthSource: VI1PR06MB1216.eurprd06.prod.outlook.com
X-MS-Exchange-CrossPremises-TransportTrafficType: Email
X-MS-Exchange-CrossPremises-SCL: 1
X-MS-Exchange-CrossPremises-messagesource: StoreDriver
X-MS-Exchange-CrossPremises-transporttraffictype: Email
X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0;
X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent
X-OrganizationHeadersPreserved: VI1PR06MB1406.eurprd06.prod.outlook.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lurk/nFuNbEnJlJG7vZt4ByLyonDKWac>
Subject: [Lurk] lurk -- February 2018 draft; comments
X-BeenThere: lurk@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Limited Use of Remote Keys <lurk.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lurk>, <mailto:lurk-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lurk/>
List-Post: <mailto:lurk@ietf.org>
List-Help: <mailto:lurk-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lurk>, <mailto:lurk-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 May 2018 14:40:06 -0000

Dear all,

I’ve had a look at a draft of Lurk that Daniel Migault sent me a while back; it was  dated February 2018.
Here come a mix of comments:

1. I like the aspect of termination of TLS be split into different services  (e.g., network + crypto); I think we should expand on this side.
We should expand both because it’s a nice idea and because I’m a bit worried of weird DoS attacks where one service is left in limbo.

2. I would do away with TLS 1.1.

3. I would introduce a version for TLS 1.3.

4. Let us focus on annex A1 (Lurk/TLS 1.2. RSA mode)

As you know there is this work: , "Content delivery over TLS: a cryptographic analysis of keyless SSL,” by K. Bhargavan, I. Boureanu, P. A. Fouque, C. Onete and B. Richard at 2017 IEEE European Symposium on Security and Privacy (EuroS&P), Paris, 2017, pp. 1-16.
And an attack was shown on Cloudflare’s "Keyless SSL” when run in RSA mode.

The attack rests on the fact that the client sends the “encrypted premaster secret” to the edge server who forwards this to the key server and the *answer the key-server gives back to the edge-server*.
As per Annex A1, it is not clear to me what does the key-server reply with, to the edge-server, in this step. This we need to make clear.

However, in this last step of the LURK handshake in TLS1.2. RSA-mode, the key-server should not *reply to the edge server with the premaster secret* .
Such a reply would be an issue. Namely, if one edge server E1 becomes corrupt this is what it can be used to do.
The attacker collects handshake data (which is over insecure channel) from one session —called session1-- between a client and an edge server E2; this collected data includes the  “encrypted premaster secret” of this session 1.
Then, the attacker used the corrupted edge server E2 to query the key-server on this  “encrypted premaster secret” of session 1. The key server would reply back to the corrupted E2 with the premaster secret  from session1. The attacker who controls E2 and has the handshake data from session1 can now obtain the channel key for session1 and therefore decrypt the record-layer of  session1.

In the work I mentioned above, there are several solutions to this and we can discuss them.
One solution I would suggest, and is very pertinent as a tightening of the design in LURK, is like so:
1. the key-server is involved in the handshake at the beginning and generates a nonce N_S which is sent to the edge server who sends it further to the client, as to is essentially used in the ServerHello from the edge-server to the client.

2. the edge-server sends to the key server (in the step attacked above) not just the “encrypted premaster secret” but also the nonce of the client and the encrypted Finished message by the client. (In this way the key-server can find his nonce N_S inside the finished message and the attacker above is counteracted).

3. the key-server answers with X, where depending on what we wish for then we make X be different things. My top preference would be that X be the "channel keys + the Server-Finished message”. In this way, the edge-server cannot do session-resumption. This is therefore inefficient in practice. So, if we want session resumption, then we can make X be pmk or msk. Of course, we can link this to the options of the handshake..

 (Also, there is the question as to whether we want RSA mode, but this is orthogonal to the above).

5. I did not look at the description TLS 1.2 DHE-mode.
But there we need to be able to describe well the beginning of the handshake as the work I mentioned above also exposes some weird cross-protocol attacks.
I.e.,  the edge-server is corrupted and makes the key-server sign a QUIC hash (with a long TTL inside) and then this edge-server can run for quite some time.
So, we need to pay some attention to this.

Speak soon.

Ioana Boureanu

Dr. Ioana Boureanu, FHEA

Lecturer in Secure Systems
Department of Computer Science
Surrey Centre for Cyber Security
University of Surrey, Guildford, GU2 7XH
Web: people.itcarlson.com/ioana<http://people.itcarlson.com/ioana>
Linkedin: goo.gl/540OHa<http://goo.gl/540OHa>
T.: +44 1483 683425