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

Daniel Migault <> Wed, 27 June 2018 23:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC5C6130E3B for <>; Wed, 27 Jun 2018 16:08:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s8R1KiQeH0_x for <>; Wed, 27 Jun 2018 16:08:42 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 143A8130DF1 for <>; Wed, 27 Jun 2018 16:08:42 -0700 (PDT)
Received: by with SMTP id j26-v6so2753528lfb.11 for <>; Wed, 27 Jun 2018 16:08:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=b6UHEp90x9tbiAfTHnr34mARIkBt4pdZl5+AWlz3I0o=; b=fuSrUyS6I9c5r8fw8Zu2+nJJHNu+A83GSzY5rVdreUhi/wVTdVFM036ZVkE2VCZN8A zTXJtgWki4ZNKMl9yB8SJpKNiGqRqMdJfCgYeuEDTJKgiljayOnq1e5Ju36H3JxLQpnH MGaoXI4D9bCRe9wgIvYnBbLOi8JgH+x/td4YHgCi1jOkpvBX+MdVBjoWBURLl+e5G2qT yMZowvApJc4XwwS7KF94KP4ZcnbeY31TUzNaamPKWdEV1uLE/qsVXq4gPBxW7dJxGS9t KCCXVT/KK5ih6/qT6fjzVh7bXFEuEWV2oYNk+hp9fDG2h0nxSCF42pC1e5pJCRx5yKZ/ aP9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=b6UHEp90x9tbiAfTHnr34mARIkBt4pdZl5+AWlz3I0o=; b=I7vEbz89w9CbtrvoZqTYMrnFYjMB+botCv/mvx/EwRecctCU+trQPf7TowoApGMPI1 sKOWL0MBN8T8sxWE3cMeG0JuReZfKyQTsIp5VlLtuqD6KhU7JMC6ASPvzAOTMrlI2c7Z r5ccI+iMGza4MIMgoJOEIpRVCTpXdxvmuz3BKB1CJUFiBIZ1r4MuxYAkMCuQ5bP6iNdP wyIU3rNPEzirxEycNLRRj27gwswsdLT5b6aTiOLdvPAlFRYjMpqNABDQoKR12gAaXYg0 Q0d5LiTSF+WG1Qvg5s48bEpdHZ3MQx4/cQmRr+Ym4UP/10f9ft52AYTuI8litI0hfgmF cveg==
X-Gm-Message-State: APt69E26ZAe7eUgwcws6EViIAxZUzkY13RBo9BxlRaYQ6RmCPpvdgxjX H33mIN6uxRJM8/w6j8TPzjrtS+R29N238URzPPTu/Q==
X-Google-Smtp-Source: AAOMgpcPGchDHtM9F1QHrD//c/WV0kSkQLzKNp8vsNmnlcBY4lX44XJYY5zODfKt8NTDq1vNC2ihDD7OCp5X9/vHWLw=
X-Received: by 2002:a19:910a:: with SMTP id t10-v6mr5262337lfd.24.1530140920075; Wed, 27 Jun 2018 16:08:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:4281:0:0:0:0:0 with HTTP; Wed, 27 Jun 2018 16:08:39 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Daniel Migault <>
Date: Wed, 27 Jun 2018 19:08:39 -0400
X-Google-Sender-Auth: bUdjMUCZlYqC-f000i5dYVGy8ng
Message-ID: <>
To: LURK BoF <>
Content-Type: multipart/alternative; boundary="000000000000ff59cc056fa7b1c5"
Archived-At: <>
Subject: Re: [Lurk] LURK TLS 1.2 draft -- my latest edits + small TO-DOs
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Limited Use of Remote Keys <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Jun 2018 23:08:45 -0000


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:


On Tue, Jun 26, 2018 at 12:58 PM, Daniel Migault <> wrote:

> Hi,
> Please find an update of the document available on github:
> 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, <
> > 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