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

Daniel Migault <> Tue, 26 June 2018 16:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C4B31310D8 for <>; Tue, 26 Jun 2018 09:58:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Status: No, score=-1.398 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, URIBL_BLOCKED=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 OgnFwMQ5grKU for <>; Tue, 26 Jun 2018 09:58:36 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ABDE3131078 for <>; Tue, 26 Jun 2018 09:58:34 -0700 (PDT)
Received: by with SMTP id i125-v6so9346094lji.2 for <>; Tue, 26 Jun 2018 09:58:34 -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:cc; bh=xaHe53I2UZcj6nDayf+JXOBYydPSBQZ7dwIbniJjhoc=; b=j4eVw+3LbHBnL0d6caywNHXUPA14xHMMWeb/dEuT7ckqUHlQGla9WDoHQeNBxzLNF1 lFn0HuoS4PIg7SqlQ2lOupa7tMq1F7588CdKFO9BbUv4K9tshwKPrh38ZUdTuOaHmwpP YsPxLE9FQdHEvBl80N1XYQfDVP8KF7wtECfCqTco1uUUSbMkiuLY2Hhh914QqM+f3WL+ 7qcapT45IINCKJ/twtEzx+sBrEeqk0XUJo/TkC32TgvegaolYLL6k0/XWsJOxsDl/62w lPr0FFvlkEMI6oLVoL+iYtLotWPhpUCQ1CQ+kBbjVjYBccNKyPuevmeP187oZYavlc/g oSVw==
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:cc; bh=xaHe53I2UZcj6nDayf+JXOBYydPSBQZ7dwIbniJjhoc=; b=Eju+hOjOpj7TabPwxTMPCg54FamslKKT8f6r4tllGgu/oo+92lij8xPlhditxlTGir 4Exq0CZBq/+WTKJc4a3umeB4t56CHvnFPAPhfuBM5gwXth9lRFzQBPRorrPQVQ0Jhw/l k7I3ppb+bg21AScqoNrwa+Rkdozj/v/wQRSbrZbsERPaF59iDJhodFFbDRorEjydOBsZ hA7TbH8aPNfnDRBIwEprDpHoSMcVDFnuXIZs/T6hGcO7mFmfAMKBV+9K0ookb5ODra0v xvTs6IhaiIX/UaiPoP50+CqHXsM8LQLMu88+9bwUs12lVg6A/KELhaxCnL/KrK/BvYkm ZWWg==
X-Gm-Message-State: APt69E0qU1E4G5BjvMQA/3sjULktpPLz1K/6ASujWRZ0J7I6xmwJKkMH RIKs896dkQS3iq0SLyJWDdjea1yu/FhNHjnjVDuoBw==
X-Google-Smtp-Source: AAOMgpfMkIEbCgCKk9L0g7wy/ZahjBrZIuE6FgeVSGtOERVo5dcEgy5dX43q6HwKnI0zYOZST/moMfGiv6XjgBWncgM=
X-Received: by 2002:a2e:712:: with SMTP id 18-v6mr1673732ljh.37.1530032312992; Tue, 26 Jun 2018 09:58:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:4281:0:0:0:0:0 with HTTP; Tue, 26 Jun 2018 09:58:32 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Daniel Migault <>
Date: Tue, 26 Jun 2018 12:58:32 -0400
X-Google-Sender-Auth: Owx66SboqcJuzNDkxi28crqEplc
Message-ID: <>
Cc: LURK BoF <>
Content-Type: multipart/alternative; boundary="00000000000082c7f0056f8e68d0"
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: Tue, 26 Jun 2018 16:58:48 -0000


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

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.


On Thu, Jun 21, 2018 at 6:06 PM, <>

> 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