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

[Daniel Migault <[e-mail]>]

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=[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]
>> https://www.ietf.org/mailman/listinfo/lurk
>>
>>
>