Return-Path: 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 0A62112E041 for ; Sat, 26 May 2018 11:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 yXruozm-lZmx for ; Sat, 26 May 2018 11:14:05 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (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 B200B127522 for ; Sat, 26 May 2018 11:14:04 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id y15-v6so14124200wrg.11 for ; Sat, 26 May 2018 11:14:04 -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=25ooYKwFXTz8bLvBwPejKx3x1Lw3+FwKG1Ev9PbW1c8=; b=CWB17fhCJau8GoqUAbw9gpM4KYR5WegINRMHpsqgidM8VIC/nSK19YqEgCSKPVfZ0/ EEaB/u1ZpONJuLEwaS1Y5r1qN2Lojt4jM/wTCVJvsqdad0UPhECI3XdWjHRJunVnhZQZ XtxvVkINLoWFkq7UhOXU0GNcOcXVA476AJjsm0mjDocMrAUOe0VOAuXrw6zD5wchOpEs mvL5vUFjShDwzfAHtYwbzEJnpJzAoqSn68Dmpee83JbwRELCkPYYthYKnpjHupUSS5Oi d/korp+S5tCLBDm3JF4Sk2HERmgimlUlE4ugjV7jkmBrk8HnIeNkqRol4yfGcezh+sYw PuYg== 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=25ooYKwFXTz8bLvBwPejKx3x1Lw3+FwKG1Ev9PbW1c8=; b=R4li+klbS0yBX15u39RS0Ypv1DSrua/GNMLHBvMgSEIn7COEM1/xP2SLV/rKnDYXh9 37YF28oTEXf+VrNDMdjEc5Alyl9JnTquYQ5oQV80NSztohM66mLeGe5zHNqwyRMH+pKf LPViP6Sr2+aS+iSzRVbt3J7na3tmkaKihFscQ4+tL39wbb4mx4yBZCw/aUe44EkPkniE 4Hf5pPImyrrwM6c8m8G8PyHKxSmxvs/gT/Q95J6XEkAa2aukciyGFRaxSckaIzFJv+bj 6W6MZi6WnzLB65XGSO+fuS+Q27P2en7WGc7iOWfYkdU0CW7JRu3ZxwdclFDTVqEKjxpc 2xMg== X-Gm-Message-State: ALKqPwf6r1Zni4JNvC4GaPDCvmxMBhtHsm90HR0iO90wk7FSOCq7Lo5P hpBSnJxibGky1P59ls5VbUucsORjDw/skQGxa/atUQ== X-Google-Smtp-Source: ADUXVKLFgmXpexRewaUhrRSkfIbT05dv8E8RwAk9ojgDXBHHHqmRSYtrwZZFMndzIwuH/piyofOQVSCjAphg7VU03aQ= X-Received: by 2002:a19:b54d:: with SMTP id e74-v6mr3967177lff.118.1527358443161; Sat, 26 May 2018 11:14:03 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 2002:a2e:510a:0:0:0:0:0 with HTTP; Sat, 26 May 2018 11:14:02 -0700 (PDT) In-Reply-To: References: <38CE10A0-6703-4465-9BD0-153787ED2039@surrey.ac.uk> From: Daniel Migault Date: Sat, 26 May 2018 14:14:02 -0400 X-Google-Sender-Auth: 2_cwfL6EGfSgVpskgTD7nreIqPY Message-ID: To: i.boureanu=40surrey.ac.uk@dmarc.ietf.org Cc: LURK BoF Content-Type: multipart/alternative; boundary="000000000000731038056d1fd9e8" Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2018 18:14:09 -0000 --000000000000731038056d1fd9e8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ioana, The current working version is available here: https://github.com/mglt/draft-mglt-lurk-tls12 The txt and mkd version are in sync. Feel free to update the text. To briefly respond to your comments: * TLS1.1 has been removed from this document. * The way we implement PFS is described in section 4.1.1 "Perfect Forward Secrecy". * For the extended master secret, I do not thing the current design is acceptable as there is no PFS. I will send an update email to notify the list of the changes performed on the version available on the git. Feel free to update the document on github! Yours, Daniel On Sat, May 26, 2018 at 6:25 AM, wrote: > Hi Daniel, > > > > Thanks for this. > Please see my answers below. > > > On 26 May 2018, at 01:08, Daniel Migault > 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". > > > If this were me, I would consider altogether removing TLS 1.1=E2=80=A6, = unless > there is some very stringent and very well motivate use-case for ot. > > We are also planning to design an extension for TLS 1.3 by next IETF in > Montreal. > > > Good. That=E2=80=99s great. > > > My understanding of step 1 and 2 is to prevent a passive attacker to send > a request to the key server. > > > He is not just passive: first he is passive, then he is active =E2=80=94q= uerying > the key-server on an old KE_C =3D enc_pkS(premaster-secret) > > The key server is bound to a specific TLS handshake, by providing an > random nonce involved in the handshake (and checking that random nonce ha= s > effectively been used in the exchange). > > > That was one of my suggestions for remedies to the above! > I did not see this in the Feb. draft. > > More specifically, a recorded TLS handshake can only be replayed if the > nonce provided by the key server matches the recorded one. > > > And that cannot happen, as I presume the channel between the key-server > and the edge-server is secured... > > > 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 o= ne > to retrieve the keys). > > > Correct. I wrote this in my initial comments. But without this nonce N_S > contributed in the ServerHello from the key-server to the edge-server, th= e > querying on an old KE_C is just unstoppable. > > 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. > > > Not sure what the 1st sentence means, but the 2nd is the crux of the doin= g > this proxied handshake securely: one needs to bind the server in the > ServerHello message. > > In fact I do not remember as I write this, if the edge-server only sends > KE_C back to the Server at the end of the handshake, but I would make th= e > edge-server send to the key-server [N_C , KE_C , enc(k_C;Client-Finished)= ] > at the end of the handshake. Like this the key-server, can check that his > nonce N_S and *that the nonce N_C* appear in Client-Finished. > > By the way, in the above, I call =E2=80=9C N_S=E2=80=9D what you call "se= rver-random=E2=80=9D and > =E2=80=9CN_C" what you call "client-random=E2=80=9D. > > > The current protocol prevents an exchange to be replayed by generating th= e > server_random as the output of a hash function. server_random =3D 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. > > > Where does this M come from? Who produces it? I could now see it in the > February draft. > > *Let=E2=80=99s do this=E2=80=A6: I will just look at the link you sent me= to the online, > current draft.* > *Sorry for my commenting potentially on some old draft.* > > In addition, the server_random carry the time and the key server does not > respond when the server_random is out of a windows. > > > That=E2=80=99s good. > I still would like to check that hash(M) thing... > > Note that this latest time control may also be performed in your case.) > > > Correct. > > > 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. > > > I agree, modulo the fact that I still would like to check that hash(M) > thing... > > 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. > > > I will check and make comments on the very draft therein. > > It will be done on Tuesday. > > > Regarding 3) we effectively prove the master secret. This provides sessio= n > resumption for efficiency reasons. > > > OK. If you want session-resumption, you have to give back =E2=80=9Cmsk=E2= =80=9D indeed. > > > > Regarding extended master, the current design does not prevent anti repla= y > mechanism as the edge server provides the hash of the session. In this > case, there is probably a trade off between perfect forward secrecy versu= s > efficiency. > > > I do not follow this phrase above=E2=80=A6. Sorry. > > I would be happy to know which direction we should take. pfs would requir= e > 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! > > > You=E2=80=99re welcome. > > I will be back on email and on this on Tuesday. > > > Best, > Ioana > > > Yours, > Daniel > > > On Thu, May 24, 2018 at 10:39 AM, uk@dmarc.ietf.org> wrote: > Dear all, > > I=E2=80=99ve 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=E2=80=99s a nice idea and because I=E2= =80=99m 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,=E2=80=9D by K. Bhargavan, I. Boure= anu, P. A. > Fouque, C. Onete and B. Richard at 2017 IEEE European Symposium on Securi= ty > and Privacy (EuroS&P), Paris, 2017, pp. 1-16. > And an attack was shown on Cloudflare=E2=80=99s "Keyless SSL=E2=80=9D whe= n run in RSA mode. > > The attack rests on the fact that the client sends the =E2=80=9Cencrypted > premaster secret=E2=80=9D 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) fro= m > one session =E2=80=94called session1-- between a client and an edge serve= r E2; > this collected data includes the =E2=80=9Cencrypted premaster secret=E2= =80=9D of this > session 1. > Then, the attacker used the corrupted edge server E2 to query the > key-server on this =E2=80=9Cencrypted premaster secret=E2=80=9D of sessi= on 1. The key > server would reply back to the corrupted E2 with the premaster secret fr= om > session1. The attacker who controls E2 and has the handshake data from > session1 can now obtain the channel key for session1 and therefore decryp= t > 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 th= e > 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 furth= er > 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 =E2=80=9Cencrypted premaster secret=E2=80=9D but also the no= nce 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 the= n > we make X be different things. My top preference would be that X be the > "channel keys + the Server-Finished message=E2=80=9D. In this way, the ed= ge-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 > > --000000000000731038056d1fd9e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ioana,

The current w= orking version is available here:

The txt and mkd version a= re in sync. Feel free to update the text.

To = briefly respond to your comments:

* TLS1.1 has bee= n removed from this document.
* The way we implement PFS is = described in section 4.1.1 "Perfect Forward Secrecy".
*= For the extended master secret, I do not thing the current design is accep= table as there is no PFS.

I will send an upda= te email to notify the list of the changes performed on the version availab= le on the git.

Feel free to update the docume= nt on github!

Yours,
Daniel
=






On Sat, May 26, 2018 a= t 6:25 AM, <i.boureanu=3D40surrey.ac.uk@dmarc.ie= tf.org> wrote:
Hi Daniel,



Thanks for this.
Please see my answers below.


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 focu= sed on TLS 1.2. This is especially true as the designation of the extension= is "tls12".=C2=A0

 If this were me, I would consider =C2=A0altogether removing TLS 1.1=E2=80= =A6, unless there is some very stringent and very well motivate use-case fo= r ot.

We are also planning to design an extension for T= LS 1.3 by next IETF in Montreal.=C2=A0

 Good. That=E2=80=99s great.

My understanding of step 1 and 2 is to prevent a passive attacker to send a= request to the key server.

 He is not just passive: first he is passive, then he is active =E2=80=94que= rying the key-server on an old KE_C =3D enc_pkS(premaster-secret)

The key server is bound to a specific TLS handsha= ke, by providing an random nonce involved in the handshake (and checking th= at random nonce has effectively=C2=A0been used in the exchange).

 That was one of my suggestions for remedies to the above!=C2=A0
I did not see this in the Feb. draft.

More specifically, a recorded TLS handshake can o= nly be replayed if the nonce provided by the key server matches the recorde= d one.=C2=A0

 And that cannot happen, as I presume the channel between the key-server and= the edge-server is secured...

The two drawback I see with this proposed mechanism are that it requires tw= o interactions with the key server ( one to send the ServerHello, and one t= o retrieve the=C2=A0keys).

 Correct. I wrote this in my initial comments. But without this nonce N_S co= ntributed in the ServerHello from the key-server to the edge-server, the qu= erying on an old=C2=A0KE_C is just unstoppable.

Then, the handshake_message as well as the Finish= ed message needs to be send to the key server. The advantage is on the othe= r hand an explicit binding to a=C2=A0TLS handshake. =C2=A0

 Not sure what the 1st sentence means, but the 2nd is the crux of the doing = this proxied handshake securely: one needs to bind the server in the Server= Hello=C2=A0message.

In fact I do not remember as I write this, if the edge-server only sends KE= _C back to the Server =C2=A0at the end of the handshake, but I would make t= he edge-server send to the key-server=C2=A0[N_C=C2=A0, KE_C , enc(k_C;Clien= t-Finished)=C2=A0] at the end of the handshake. Like this the key-server, can check that his nonce N_S and *that the nonce N_C*= appear in=C2=A0Client-Finished.
=C2=A0
By the way, in the above, I call =E2=80=9C N_S=E2=80=9D what you call "= ;server-random=E2=80=9D and =E2=80=9CN_C" what you call "client-r= andom=E2=80=9D.


The current protocol prevents an exchange to be replayed by generating the = server_random as the output of a hash function. server_random =3D hash( M )= and the=C2=A0operations performed by the edge server as well as by the key= server. A passive attacker would observed server_random but could not reverse M.

Where does this M come from? Who produces it? I could now see i= t in the February draft.

Let=E2=80=99s do this=E2=80=A6: I will just look at the link you se= nt me to the online, current draft.
Sorry for my commenting=C2=A0potentially on some old draft.
In addition, the=C2=A0server_random carry the tim= e and the key server does not respond when the server_random is out of a wi= ndows.

That=E2=80=99s good.=C2=A0
I still would like =C2=A0to check =C2=A0that hash(M) thing...

Note that this latest time control may also be=C2= =A0performed in your case.)

Correct.


I believe that the two mechanisms achieve the same goal with a different pe= rspective. Explicit biding, versus unability to replay a query based on cry= ptographic hash=C2=A0function.

I agree, modulo the fact that I still would like =C2=A0to check= =C2=A0that hash(M) thing...

While the mechanism is not described in the appen= dix, I am wondering if you see any reason to change the mechanism. That sai= d agree that the appendix=C2=A0should be clarified and updated. =C2=A0=C2= =A0

 I will check and make comments on the very draft therein.

It will be done on Tuesday.

Regarding 3) we effectively prove the master secret. This provides session = resumption for efficiency reasons.=C2=A0

 OK. If you want session-resumption, you have to give back =E2=80=9Cmsk=E2= =80=9D =C2=A0indeed.


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=C2=A0probably a trade off between perfect forward secrecy versus= efficiency. =C2=A0

 I do not follow this phrase above=E2=80=A6. Sorry.
I would be happy to know which direction we shoul= d take. pfs would require sending the=C2=A0handshake messages to the key se= rver so the key server can generate the server_random and the session hash.= =C2=A0


Thanks you for your feed backs!

 You=E2=80=99re welcome.

I will be back on email and on this on Tuesday.


Best,
Ioana


Yours,=C2=A0
Daniel =C2=A0


On Thu, May 24, 2018 at 10:39 AM,=C2=A0<i.boureanu=3D40surrey.ac.uk@dmarc.ietf.org>=C2=A0wrote:
Dear all,

I=E2=80=99ve had a look at a draft of Lurk that Daniel Migault sent me a wh= ile back; it was =C2=A0dated February 2018.
Here come a mix of comments:


 1. I like the aspect of termination of TLS be split into different services= =C2=A0(e.g., network + crypto); I think we should expand on this side..=C2= =A0

We should expand both because it=E2=80=99s a nice idea and because I=E2=80= =99m 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 crypto= graphic analysis of keyless SSL,=E2=80=9D by K. Bhargavan, I. Boureanu, P. = A. Fouque, C. Onete and=C2=A0B. Richard at=C2=A02017 IEEE European Symposiu= m on Security and Privacy (EuroS&P),=C2=A0Paris, 2017, pp. 1-16.
And an attack was shown on Cloudflare=E2=80=99s "Keyless SSL=E2=80=9D = when run in RSA mode.

The attack rests on the fact that the client sends the =E2=80=9Cencrypted p= remaster secret=E2=80=9D to the edge server who forwards this to the key se= rver and the=C2=A0*answer the=C2=A0key-server gives back to the edge-server= *.=C2=A0
As per Annex A1,=C2=A0it 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 k= ey-server should not=C2=A0*reply to the edge server with the premaster=C2= =A0secret*=C2=A0.=C2=A0
Such a reply would be an issue. Namely, if one edge server E1 becomes corru= pt this is what it can be used to do.=C2=A0
The attacker collects handshake data (which is over insecure channel) from = one session =E2=80=94called session1-- between a client and an edge server = E2; this=C2=A0collected data includes the =C2=A0=E2=80=9Cencrypted premaste= r secret=E2=80=9D of this session 1.
Then, the attacker used the corrupted edge server E2 to query the key-serve= r on this =C2=A0=E2=80=9Cencrypted premaster secret=E2=80=9D of session 1. = The key server would=C2=A0reply back to the corrupted E2 with the premaster= secret =C2=A0from session1. The attacker who controls=C2=A0E2 and has the handshake data from session1 can=C2=A0now obtain the channel key for s= ession1 and therefore decrypt the record-layer of =C2=A0session1.

In the work I mentioned above, there are=C2=A0several solutions=C2=A0to thi= s 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 generat= es a nonce N_S which is sent to the edge server who sends it further to=C2= =A0the client, as to is essentially used in the ServerHello from the edge-s= erver to the client.=C2=A0

2. the edge-server sends to the key server (in the step attacked above) not= just the =E2=80=9Cencrypted premaster secret=E2=80=9D but also the nonce o= f the client=C2=A0and the encrypted Finished message by the client. (In thi= s way the key-server can find his nonce=C2=A0N_S inside the finished message and the attacker=C2=A0above is counteracted).

3. the key-server answers with=C2=A0X,=C2=A0where depending on what we wish= for then we make=C2=A0X=C2=A0be different things. My top preference would = be that=C2=A0X=C2=A0be=C2=A0the "channel keys + the Server-Finished me= ssage=E2=80=9D. In this way, the edge-server cannot do session-resumption. = This is therefore inefficient in=C2=A0practice. So, if we want session resumpti= on, then we can make=C2=A0X=C2=A0be=C2=A0pmk=C2=A0or=C2=A0msk. Of course, w= e can link this to the options of the handshake..

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

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 handshak= e as the work I mentioned above also exposes some weird cross-protocol atta= cks.
I.e., =C2=A0the edge-server is corrupted and makes the key-server sign a QU= IC hash (with a long TTL inside) and then this edge-server can run for quit= e some time.=C2=A0
So, we need to pay some attention to this.=C2=A0

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:=C2=A0p= eople.itcarlson.com/ioana=C2=A0
Linkedin:=C2=A0goo.gl/54= 0OHa=C2=A0=C2=A0
T.: +44 1483 683425
=C2=A0







_______________________________________________
Lurk mailing list
Lurk@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/lurk


_______________________________________________
Lurk mailing list
Lurk@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/lurk


_______________________________________________
Lurk mailing list
Lurk@ietf.org
https://www.ietf.org/mailman/listinfo/lurk


--000000000000731038056d1fd9e8--