Re: [Lurk] lurk -- February 2018 draft; comments

Daniel Migault <daniel.migault@ericsson.com> Mon, 11 June 2018 21:10 UTC

Return-Path: <mglt.ietf@gmail.com>
X-Original-To: lurk@ietfa.amsl.com
Delivered-To: lurk@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 489A9130ED0 for <lurk@ietfa.amsl.com>; Mon, 11 Jun 2018 14:10:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 CRjiImBbRMPp for <lurk@ietfa.amsl.com>; Mon, 11 Jun 2018 14:10:44 -0700 (PDT)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 213E6127598 for <lurk@ietf.org>; Mon, 11 Jun 2018 14:10:44 -0700 (PDT)
Received: by mail-lf0-x22a.google.com with SMTP id n15-v6so32703669lfn.10 for <lurk@ietf.org>; Mon, 11 Jun 2018 14:10:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=46FSpZynTOl2ajYJs6rxwUJWitEnqvnGSD1eLB6UeYU=; b=aSTL04TJpvPEGFDRNTo7qfbH2QNHvqIMPV1BR9hXVeGGNrsIh4jiDhGbyDyvFOaG72 rsVOjNXSfjXKckrY/Bng88lmHxiqNk3xTiTq/fyp3adYoaZlO5hGETGQif6IfZ9oU332 Il/MZPPwZe7uPNz9E0GwXqlkG7hsS53ahueFZdo7sgxAaBNsYG2nmHxi+6dzTYNMtw0z jocpFdEm1x1mlykVjimXG/XZKsHQHzauLfW9qW5xMvNZSuZHxuptnDFh6CwSX4z8UW7O kutSgurp12HnYiIxCztOzoJOiPHntiJ7TbZ5XAqy2QwadWCCDLAgDNMaNCCzil5dE0pH NXNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=46FSpZynTOl2ajYJs6rxwUJWitEnqvnGSD1eLB6UeYU=; b=uEv6Sq8cS8S0UYrrJcOve60XgrYHQ/0Kucr0icliN0b/Y1mgjRFDez1ogQRGTK/tpg SS3TkXeK2zBiH4bnY+DMW+OkyPmgNXcf45Xteo6Y8x2SBX2DdzckLnOz/kZoFF2ouTUN Jkv+HmTBWemxdq3a9ZJwnOnDSBpiSufzLhuArHlL5hoibS+73Ytw2mmVrQMbYlJKpSQS 3FdGwAexSqlGz55L8RFelkWAs2TjzvKbq2MYU70kEYghbDuOCt4iMG6GMzB9tRiqHhTE LDefcetohtB8ART1qJ9AMjVNBPOdGdPDU+qTuogRlCh4J3MgWrP77PZiYxYjRCwxaVTd d+jg==
X-Gm-Message-State: APt69E2iHZZHsdw9WIgKO4+am4KRY4t6TyROzBCUduzPG93jaQB7i1MG bpTFwT2En7PgqT/WqnnUuC4nrLvsfXhbUDvw6dc=
X-Google-Smtp-Source: ADUXVKKfHbMtFdHUOwXwy9p/JBpf13oBVDDuAud6RBNtLkZXmvYbQwO/WtgvOPqOQMO4PD4E05b9JhmlBVhOFZWkodg=
X-Received: by 2002:a2e:9cd8:: with SMTP id g24-v6mr491557ljj.141.1528751442384; Mon, 11 Jun 2018 14:10:42 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 2002:a2e:9857:0:0:0:0:0 with HTTP; Mon, 11 Jun 2018 14:10:41 -0700 (PDT)
In-Reply-To: <A9D6EECC-EEDB-4FEB-9FB7-52C02C8EDD7B@surrey.ac.uk>
References: <38CE10A0-6703-4465-9BD0-153787ED2039@surrey.ac.uk> <CADZyTk=xV_Lh6P6Nk_yUz0gpKwoR=MuiBDZEpnxyRd9MAdKk-g@mail.gmail.com> <70C67DB9-F1F3-4742-B700-62DB4CE6A118@surrey.ac.uk> <A9D6EECC-EEDB-4FEB-9FB7-52C02C8EDD7B@surrey.ac.uk>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Mon, 11 Jun 2018 17:10:41 -0400
X-Google-Sender-Auth: dn-P7cMhmjyoHVcmPwPzZC5SsAw
Message-ID: <CADZyTk=3+CmPD2GaybdaeMKy+yPWQ-tQc5rxGu7L1gMDab0feg@mail.gmail.com>
To: i.boureanu=40surrey.ac.uk@dmarc.ietf.org
Cc: LURK BoF <lurk@ietf.org>, stere.preda@ericsson.com
Content-Type: multipart/alternative; boundary="000000000000ac5af1056e642e21"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lurk/DTa6-Jm9sHx3tET64vJuaghsQiU>
Subject: Re: [Lurk] lurk -- February 2018 draft; comments
X-BeenThere: lurk@ietf.org
X-Mailman-Version: 2.1.26
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: Mon, 11 Jun 2018 21:10:49 -0000

If I am correct we also nee to send the complete handshake_messages that is
in our case ClientHello...Client Finished.

Yours,
Daniel

On Mon, Jun 11, 2018 at 6:37 AM, <i.boureanu=40surrey.ac.uk@dmarc.ietf.org>;
wrote:

> Hi Daniel, Hi all,
>
> I am replying to my pb I singled in myself in my last email, as per the
> below.
>
>
>
> On 7 Jun 2018, at 22:59, Boureanu IC Dr (Computer Science) <
> i.boureanu@surrey.ac.uk>; wrote:
>
>
> Hi Daniel and all,
>
> *Daniel*, thanks for the below. I am going to come back onto the attack I
> spoke of in here, on the 24th and your answer/countermeasure
>
> Let me recall the attack I described on the 24th of May:
>
> <ioana>
>
> 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.
>>
>> </ioana>
>
> Recall again, my "24th-of-May” attacker *Adv1* did two things in a
> sequence: (a) first,  *Adv1 *eavesdropped some handshake between an
> edge-server E1 and  a client and collected the data; (b) then, *Adv1 *corrupted
> an edge-server E2 and used this corrupted E2 to query the key-server on old
> data, replaying from the collection in the session in point (a).
> To this, you said:
>
> <daniel>
>
> The current protocol prevents an exchange to be replayed by generating the
> server_random as the output of a hash function. server_random = hash( M )
> and the operations performed by the edge server as well as by the key
> server. A passive attacker would observed server_random but could not
> reverse M. In addition, the server_random carry the time and the key server
> does not respond when the server_random is out of a windows. Note that this
> latest time control may also be performed in your case.)
>
> </daniel>
>
>
> *@some fix, indeed: *
> *1.* I agree that,* in the current version of the draft that you speak of
> above*, because  the edge-sever sends to the key-server* S* and *pfs* and
> NOT  *server-random, *my attacker above cannot collect S  from a session1
> of the handshake run on the insecure channel that is between the client and
> the edge-server, so *my 24th-of-May attacker cannot replay *the whole
> message from session1. I.e., my "24th-of-May” replay attacker is missing S.
>
> *@some attack still exists:*
> *2*. What the “7th-of-June” attacker *Adv*2  :) can do is this:
> (a)  first,  *Adv2 *eavesdropps some handshake in a session session1
> between an edge-server E1 and  a client and collected the data, namely *encrypted-pmk1
>  *and *client-random1, **server-random1 *+ *Adv*2 recored the time when
> this was done; let’s say that *Adv2* does this today
> (b) *Adv2* has a lot of time on his hands and computation power, so he
> spends his time, for some weeks even, trying to find a collision *S’ * for
> the hash *pfs* such that it gives the same *server-random1 *he collected
> (c) then, *Adv2 *corrupts an edge-server E2 and uses this corrupted E2 to
> query the key-server on *client-random1+ newly found **S’ + e*
> *ncrypted-pmk1 *
>
>
> This attack by me above is counteracted if the edge-server sends the
> client Finished to the key-server. In this way any S’ found as a collision
> for pfs(S) after months of computing is of no use as the Client Finished
> collected from the past would not match.
>
> I.e., now in the draft we have:
>
> CLIENT                        EDGE-SERVER
>  KEY-SERVER
> ————>
>
>
>
>                        TLS12 Request Header
>                        TLS12MasterRSARequestPayload
>                            key_id
>                            client_random
>                            S
>                            pfs
>                            EncryptedPremasterSecret
>                        -------->
>
>
> *and if we had*
>
> CLIENT                        EDGE-SERVER
>  KEY-SERVER
>
>  Client Finished
> ————>
>
>
>
>
>                           TLS12 Request Header
>                            TLS12MasterRSARequestPayload
>                            key_id
>                            client_random
>                            S
>                            pfs
>                            EncryptedPremasterSecret
>  [I.B. ADDED:] *Client Finished*
>                        -------->
>
>
> that would be much better.
>
> I argued this addition in different context and I think we should have it.
>
> Best,
> Ioana
>
>
> Yes, I know, you’d say that this is not a super-big threat, but this is my
> answer to the *"S, server-random:=pfs(S)” * trick on the edge-server side.
> One can think of what the *pfs* function should be to minimise the risks
> above, but… still...
>
> In all honesty, all these are forward-secrecy attacks, which are due to or
> inherent to  building something on TLS in RSA mode.
>
> *@my solution, still*
> *3. *One way in which I see that we can protect again these is the
> following: the key-sever produces the “*server-random*” to be send to the
> client and the key-server accepts a query on an "*encrypted pmk” *only in
> some time-window from when it generated that “*server-random*”. The
> key-server is sent the *Client Finished message *too on a query on a
> given "*encrypted pmk”**, *and the key-server only processes the query if
> it sees that it is on the *server-random* that it sent some milliseconds
> before.
>
> In other words, this point *3 *of mine, just above equates still what I
> said on the 24th in terms of solutions to the pb.
> You can revisit that as well, further down in this email.
>
>
> *@also (in any case, and almost irrespective of these attacks):*
> *4.* At the step where *S*, *encrypted pmk* etc are sent from the
> edge-server to the key-server, we should have the *edge-server send the *Client
> Finished message* to the key-server* too, so that the key-server can
> verify the *Client Finished message* against the *client_random* too.
>
>
> Chat soon.
>
> Best,
> Ioana
>
>
> On 26 May 2018, at 01:08, Daniel Migault <daniel.migault@ericsson.com>;
> wrote:
>
> Hi Ioana,
>
> Thanks for the feed back. I agree with you that the document should be
> focused on TLS 1.2. This is especially true as the designation of the
> extension is "tls12". We are also planning to design an extension for TLS
> 1.3 by next IETF in Montreal.
>
> My understanding of step 1 and 2 is to prevent a passive attacker to send
> a request to the key server. The key server is bound to a specific TLS
> handshake, by providing an random nonce involved in the handshake (and
> checking that random nonce has effectively been used in the exchange). More
> specifically, a recorded TLS handshake can only be replayed if the nonce
> provided by the key server matches the recorded one.
>
> The two drawback I see with this proposed mechanism are that it requires
> two interactions with the key server ( one to send the ServerHello, and one
> to retrieve the keys). Then, the handshake_message as well as the Finished
> message needs to be send to the key server. The advantage is on the other
> hand an explicit binding to a TLS handshake.
>
> The current protocol prevents an exchange to be replayed by generating the
> server_random as the output of a hash function. server_random = hash( M )
> and the operations performed by the edge server as well as by the key
> server. A passive attacker would observed server_random but could not
> reverse M. In addition, the server_random carry the time and the key server
> does not respond when the server_random is out of a windows. Note that this
> latest time control may also be performed in your case.)
>
> I believe that the two mechanisms achieve the same goal with a different
> perspective. Explicit biding, versus unability to replay a query based on
> cryptographic hash function. While the mechanism is not described in the
> appendix, I am wondering if you see any reason to change the mechanism.
> That said agree that the appendix should be clarified and updated.
>
> Regarding 3) we effectively prove the master secret. This provides session
> resumption for efficiency reasons.
>
>
> Regarding extended master, the current design does not prevent anti replay
> mechanism as the edge server provides the hash of the session. In this
> case, there is probably a trade off between perfect forward secrecy versus
> efficiency.  I would be happy to know which direction we should take. pfs
> would require sending the handshake messages to the key server so the key
> server can generate the server_random and the session hash.
>
> Thanks you for your feed backs!
>
> Yours,
> Daniel
>
>
> On Thu, May 24, 2018 at 10:39 AM, <i.boureanu=40surrey.ac.uk@
> dmarc.ietf.org> wrote:
>
>> 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.
>>
>> Best,
>> 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
>> Linkedin: goo.gl/540OHa
>> T.: +44 1483 683425
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Lurk mailing list
>> Lurk@ietf.org
>> https://www.ietf.org/mailman/listinfo/lurk
>>
>>
> _______________________________________________
> Lurk mailing list
> Lurk@ietf.org
> https://www.ietf.org/mailman/listinfo/lurk
>
>
>
>
> _______________________________________________
> Lurk mailing list
> Lurk@ietf.org
> https://www.ietf.org/mailman/listinfo/lurk
>
>