Subject: [Lurk] LURK TLS 1.2 draft -- my latest edits + small TO-DOs

From: <[email-masked]>
Date: Thu, 21 Jun 2018 22:06:06 +0000

Hi all,

Daniel, thanks for our last Skype… Sorry for the delay past that

Daniel, after that Skype, here’s where we are.

@my actions:
I’ve modified the mkd  file of LURK TLS 1.2 draft as per what we discussed.

I mainly placed my modifications in the security considerations, which I almost entirely rewrote.

This “security-considerations” section now has these sub-headings:
1. General Considerations (in here I put not much, but general things .. like those linked to the LURK Server returning msk and not pmk)

2. Perfect Forward Secrecy Considerations
In here, the new stuff is on the security analysis linked to what we need of the pfs function for LURK in RSA-mode to get some forward-secrecy (i.e., protect against a MiM + corrupt LURK client make bad queries to the LURK Server).

I have put in the two options for the ‘pfs’ function we discussed of:
1) pfs being a CRHF; 2) pfs being a PRF instance keyed on a key that the LURK Server and LURK Client pre-share.
I said that 1 is better at achieving security, but 2 is may be more efficient

[You may one to add precise RECOMMENDATIONS there]

3. Proxied-Infrastructure Considerations
In here, I’ve put two things :
a). that the Client's Finished be sent to the LURK Server (along with all handshake data) help the
LURK Server audit the query;
                b). that the option where the LURK Server sends S to the LURK Client, for this one to do server-random=pfs(S), is better at  forward-secrecy protection than 2) above  but it is more expensive (i.e., increased latency)
* I’d like to add this 3.b) in the appendix, as an optional variant. Would that be OK?

    (BTW, you may need to touch up the jargon: e.g., if I used “RECOMMENDED” where I was supposed to use that, etc).

All this is on GitHub on a  branch of the repo called “patch1"

@your actions:

You are/were going to
  — add the aspect that Client's Finished be sent to the LURK Server (along with all handshake data)
  — re-design the rsa_master_extended with the full handshake
Once you do this, you and/or me can make a run to make it all uniform.

Thanks.

Best,
Ioana

---

From: Daniel Migault <[email-masked]>
Date: Tue, 26 Jun 2018 12:58:32 -0400

Hi,

Please find an update of the document available on github:
https://github.com/mglt/draft-mglt-lurk-tls12

The rsa_extended_master includes now the necessary parameters to generate
the session_hash. It does not include anymore the session_hash. As a
result, randoms are available which enables anti replay mechanism based on
the hash of the server random.

Both rsa_master and rsa_master_extended include the possibility to have an
option that carries the Finished message as well as parameters to check the
Finished message. While this is designated as "finished" option, it impacts
the format of the request.

rsa_master without the "finished" option requires to specify the client
random, the server_random and the encrypted_premaster. With the "finished"
option, all of them are included in the handshake.
rsa_extended_master without the "finished" option requires to specify the
an handshake that includes the ClientHello...ServerHello. With the
"finished" option the handshake provided includes the later and so is
included.

The current design avoids the repetition of parameters. As such, when the
"finished" option is provided, the parameters are expected to be taken from
the handshake associated to the "finished" option.

I do not find the term "option" appropriated, so I am happy to hear a
better designation.

Yours,
Daniel

On Thu, Jun 21, 2018 at 6:06 PM, <i.boureanu=[email-masked]>
wrote:

> Hi all,
>
> *Daniel, *thanks for our last Skype… Sorry for the delay past that
>
> *Daniel*, after that Skype, here’s where we are.
>
> *@my actions:*
> I’ve modified the *mkd*  file of LURK TLS 1.2 draft as per what we
> discussed.
>
> I mainly placed my modifications in the* security considerations*, which
> I almost entirely rewrote.
>
> *1. General Considerations *(in here I put not much, but general things
> .. like those linked to the LURK Server returning msk and not pmk)
>
> *2. Perfect Forward Secrecy Considerations*
>
> In here, the new stuff is on the security analysis linked to what we need
> of the pfs function for LURK in RSA-mode to get some forward-secrecy (i.e.,
> protect against a MiM + corrupt LURK client make bad queries to the LURK
> Server).
>
>
> *3. Proxied-Infrastructure Considerations*
>                 b). that the option where the LURK Server sends S to the
> LURK Client, for this one to do server-random=pfs(S), is better at
>  forward-secrecy protection than 2) above  but it is more expensive (i.e.,
> increased latency)
>
>     (BTW, you may need to touch up the jargon: e.g., if I used
> “RECOMMENDED” where I was supposed to use that, etc).
>
> *All this is on GitHub on a  branch of the repo called “patch1"*
>
> *@your actions:*
>
> You are/were going to
> _______________________________________________
> Lurk mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lurk
>
>

---

From: Daniel Migault <[email-masked]>
Date: Wed, 27 Jun 2018 19:08:39 -0400

Hi,

I finally removed the option and created a new type of request when the
finished message is included. The reasoning behind is that we anyway have
to indicate whether the finished message is included or not which costs one
byte. Then the presence of the finished message impact the format of the
request ( that is the way parameters are transmitted). This is closer to
another type of request than the addition of an option.

Comments are appreciated as the dead line for publication is Monday 23:59
UTC time, so please provide feed back by Sunday ;-)

the current version is available at:
https://github.com/mglt/draft-mglt-lurk-tls12/blob/master/draft-mglt-lurk-tls12.mkd

Yours
Daniel

On Tue, Jun 26, 2018 at 12:58 PM, Daniel Migault <
[email-masked]> wrote:

> On Thu, Jun 21, 2018 at 6:06 PM, <i.boureanu=[email-masked]
> > wrote:
>
>> Hi all,
>>

---

From: <[email-masked]>
Date: Thu, 28 Jun 2018 17:05:55 +0000

Hi Daniel,

I’ve pushed some mods; please see if you accept.

The important ones are:
1. I renamed "pfs" to "fresshness_fct”;

2. I rewrote the security considerations, especially on sec_pfs
      Therein, for our alternative to using a CRHF, I introduced a simpler way than using a PRF. That is...
       Since the channel between the LURK Client and the LURK Server  MUST be encrypted by default, in the optional version we can just do this:
 a.  the LURK Server directly  sends the server_random to the LURK Client. //again this is over an encrypted channel in any way
 b.  the LURK Client uses this server_random with the TLS Client
 c.  the LURK Server checks the correctness of the use of the said server_random when the query for the master_secret is made, with
the messages forwarded therein;

  3. in some places, we still had "LURK Client" and "LURK Server" used wrongly.

Please see in details in the mkd.

I will do another run tomorrow, on the appendices, but please see if you accept this first.

Best,
Ioana

On 28 Jun 2018, at 00:08, Daniel Migault <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

I finally removed the option and created a new type of request when the finished message is included. The reasoning behind is that we anyway have to indicate whether the finished message is included or not which costs one byte. Then the presence of the finished message impact the format of the request ( that is the way parameters are transmitted). This is closer to another type of request than the addition of an option.

Comments are appreciated as the dead line for publication is Monday 23:59 UTC time, so please provide feed back by Sunday ;-)

Yours
Daniel

On Tue, Jun 26, 2018 at 12:58 PM, Daniel Migault <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Please find an update of the document available on github: https://github.com/mglt/draft-mglt-lurk-tls12

The rsa_extended_master includes now the necessary parameters to generate the session_hash. It does not include anymore the session_hash. As a result, randoms are available which enables anti replay mechanism based on the hash of the server random.

Both rsa_master and rsa_master_extended include the possibility to have an option that carries the Finished message as well as parameters to check the Finished message. While this is designated as "finished" option, it impacts the format of the request.

rsa_master without the "finished" option requires to specify the client random, the server_random and the encrypted_premaster. With the "finished" option, all of them are included in the handshake.
rsa_extended_master without the "finished" option requires to specify the an handshake that includes the ClientHello...ServerHello. With the "finished" option the handshake provided includes the later and so is included.

The current design avoids the repetition of parameters. As such, when the "finished" option is provided, the parameters are expected to be taken from the handshake associated to the "finished" option.

I do not find the term "option" appropriated, so I am happy to hear a better designation.

Yours,
Daniel

On Thu, Jun 21, 2018 at 6:06 PM, <i.boureanu=[email-masked]<mailto:i.boureanu=[email-masked]>> wrote:
Hi all,

@my actions:

2. Perfect Forward Secrecy Considerations
In here, the new stuff is on the security analysis linked to what we need of the pfs function for LURK in RSA-mode to get some forward-secrecy (i..e., protect against a MiM + corrupt LURK client make bad queries to the LURK Server).

@your actions:

You are/were going to

Thanks.

Best,
Ioana

_______________________________________________
Lurk mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lurk

_______________________________________________
Lurk mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lurk

---

From: Daniel Migault <[email-masked]>
Date: Thu, 28 Jun 2018 13:53:37 -0400

Thanks for the update, I pushed the update and added you as contributor so
you can directly push.
Yours,
Daniel

On Thu, Jun 28, 2018 at 1:05 PM, <i.boureanu=[email-masked]>
wrote:

>        Since the channel between the LURK Client and the LURK Server  MUST
> be encrypted by default, in the optional version we can just do this:
>
>  a.  the LURK Server directly  sends the server_random to the LURK Client.
> //again this is over an encrypted channel in any way
>  c.  the LURK Server checks the correctness of the use of the said
> server_random when the query for the master_secret is made, with
> On 28 Jun 2018, at 00:08, Daniel Migault <[email-masked]>
> wrote:
>
> Hi,
>
>> Both rsa_master and rsa_master_extended include the possibility to have
>> an option that carries the Finished message as well as parameters to check
>> the Finished message. While this is designated as "finished" option, it
>> impacts the format of the request.
>>
>> On Thu, Jun 21, 2018 at 6:06 PM, <i.boureanu=40surrey.ac.uk@dma
>> rc.ietf.org> wrote:
>>
>>> Hi all,
>>>
>>> I mainly placed my modifications in the* security considerations*,
>>> which I almost entirely rewrote.
>>>
>>> In here, the new stuff is on the security analysis linked to what we
>>> need of the pfs function for LURK in RSA-mode to get some forward-secrecy
>>> (i..e., protect against a MiM + corrupt LURK client make bad queries to the
>>> LURK Server).
>>>
>>>