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

[<[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>> 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 ;-)

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 <[e-mail]<mailto:[e-mail]>> 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=[e-mail]<mailto:i.boureanu=[e-mail]>> 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.

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




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



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