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

[Daniel Migault <[e-mail]>]

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=[e-mail]>
wrote:

> 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]>
> 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]> 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=40surrey.ac.uk@dma
>> rc.ietf.org> 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]
>>> https://www.ietf.org/mailman/listinfo/lurk
>>>
>>>
>>
> _______________________________________________
> Lurk mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lurk
>
>
>
> _______________________________________________
> Lurk mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lurk
>
>