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

Daniel Migault <daniel.migault@ericsson.com> Thu, 28 June 2018 17:53 UTC

Return-Path: <mglt.ietf@gmail.com>
X-Original-To: lurk@ietfa.amsl.com
Delivered-To: lurk@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32616130FAB for <lurk@ietfa.amsl.com>; Thu, 28 Jun 2018 10:53:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWoSkdr7lwMD for <lurk@ietfa.amsl.com>; Thu, 28 Jun 2018 10:53:40 -0700 (PDT)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74EF1130DFE for <lurk@ietf.org>; Thu, 28 Jun 2018 10:53:39 -0700 (PDT)
Received: by mail-lf0-x236.google.com with SMTP id n24-v6so4857308lfh.3 for <lurk@ietf.org>; Thu, 28 Jun 2018 10:53:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=OOJIRit8SC9/EWfFS/eframTLnTCRYCqdbOpMlyJpgI=; b=ZQKmlYfg5E5xJZlauxATCeC0IMN50IbqQyQ6dj+HPQFZpJAQTwksKlaNOZKJviXQTr L0BiXULQBOOCsQt3Li1g1PWsk5KRF+jOxzBKDtQUnS9BmeXPed3cMrMKJYnvfIxBXnAQ V71RaAx/SboOJTMQevMfefuR/PrfxZvIgECSLozq4hlEMPrOf7lNheiW+mb4VnY+iNzB uK8eCefgp2B3VPnasOUNHF/OcOagNCwlga7kwFOuR98GqwxAi4PsNp3t/ldjKHOLFVr+ UeinCoRhRi2tfJLQZBm+9buHeC2nf3qi8j2YK0vVPjS6VFY6TxB9pNiYe7/iEj1Z7PLe vVKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=OOJIRit8SC9/EWfFS/eframTLnTCRYCqdbOpMlyJpgI=; b=Zy/fe6hCM+G/ehBCk1zf7sfENHtPtKLYa4OIH+MosK+YxX5kXSwyovWNYCOgdAh3/l qcn/Cex5lgd/owic02hTdUQ3kOmeaPrWQ0JooYoBCTG8QGNbbpmMOsmhtCcYLjLe/sfr eaRs14VpvjziCbPF+ngtrlOxzcaEkiDvEVC+Onkto+QHMceSmEmj9dgrOpaW7cAFxXcF rMLXqwbsiWTao4M8ru7nrzO2cktkQV/Y4mLPO3FpCfMpKb+qMLsPuGNEt4ix0y2JFmk2 fJnB8pplFhZ7u5XUjngVzKcosIkd+wsXRXuXoMfchcU5LhpQ+2uElNd37gZMoBr5BfhI z93g==
X-Gm-Message-State: APt69E155fKCkajsjFLRhKfqztO2ky3AZNXG+Oe/LKGbhLtpiIeaIKI8 NfzGakOXePdfNssQqePZvVEdOHFHRUJStGzm/CQ=
X-Google-Smtp-Source: AAOMgpdTZZrMjchpNRJAHm5fC1QRLuKxaRMKOJ0X6xcqEAGMdnw9Y4mwwCwnE2pn0Ih86dRJCxa223fxYnDoWni0V1s=
X-Received: by 2002:a19:910a:: with SMTP id t10-v6mr7529946lfd.24.1530208417783; Thu, 28 Jun 2018 10:53:37 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 2002:a2e:4281:0:0:0:0:0 with HTTP; Thu, 28 Jun 2018 10:53:37 -0700 (PDT)
In-Reply-To: <4FC6EEC2-D4C5-4340-8A31-5D78ECE31FEB@surrey.ac.uk>
References: <97D2A22D-6F4F-45F8-A1EA-6958199C2F59@surrey.ac.uk> <CADZyTkm29boWGaWzcoC_dir3tB6vkng0ud4WzPcmx+2wY5t1_Q@mail.gmail.com> <CADZyTkm0EdH-xVa7bPPOkmaJCP6qdjrDUtrDdohMbyfSTK+6+Q@mail.gmail.com> <4FC6EEC2-D4C5-4340-8A31-5D78ECE31FEB@surrey.ac.uk>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Thu, 28 Jun 2018 13:53:37 -0400
X-Google-Sender-Auth: g170HnA0rhrCQmWJ-TyygmmILE4
Message-ID: <CADZyTk=adn8DyknDLRL_CL5Z+sQBBro5ctFOkOuX1=k_KzOhBg@mail.gmail.com>
To: i.boureanu=40surrey.ac.uk@dmarc.ietf.org
Cc: LURK BoF <lurk@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002ca64f056fb76943"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lurk/ThuIpdr0NKeA68W_gK4TEkavCDk>
Subject: Re: [Lurk] LURK TLS 1.2 draft -- my latest edits + small TO-DOs
X-BeenThere: lurk@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Limited Use of Remote Keys <lurk.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lurk>, <mailto:lurk-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lurk/>
List-Post: <mailto:lurk@ietf.org>
List-Help: <mailto:lurk-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lurk>, <mailto:lurk-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2018 17:53:43 -0000

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=40surrey.ac.uk@dmarc.ietf.org>;
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 <daniel.migault@ericsson.com>;
> 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 <
> daniel.migault@ericsson.com>; 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
>>> Lurk@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lurk
>>>
>>>
>>
> _______________________________________________
> Lurk mailing list
> Lurk@ietf.org
> https://www.ietf.org/mailman/listinfo/lurk
>
>
>
> _______________________________________________
> Lurk mailing list
> Lurk@ietf.org
> https://www.ietf.org/mailman/listinfo/lurk
>
>