Re: [Lurk] Questions about LURK TLS draft

Daniel Migault <daniel.migault@ericsson.com> Wed, 11 April 2018 14:22 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 985E1126DC2 for <lurk@ietfa.amsl.com>; Wed, 11 Apr 2018 07:22:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 jko67EdnRWvt for <lurk@ietfa.amsl.com>; Wed, 11 Apr 2018 07:22:14 -0700 (PDT)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 C42761201FA for <lurk@ietf.org>; Wed, 11 Apr 2018 07:22:13 -0700 (PDT)
Received: by mail-lf0-x233.google.com with SMTP id m200-v6so2913239lfm.4 for <lurk@ietf.org>; Wed, 11 Apr 2018 07:22:13 -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=AkbO2nmIbxqWQczA3Zpi7cen7E+KRw31bvAmMazrEAs=; b=VyFFP3zXEheSMXaSByQ8EXNipg+paQ1I5mpqM4DD6AJ/UYitmuoVGXFtUcxyYrIwBZ GJG0P6HxMBZg2P1oRCapDdxoXXxMIhK3ByoUvJpKmRGJn+n0LKku6Ru8tlXkFofo8D9T AqoYyV11sSO3ok1LfKA5rIhHIH0mnQuLd+hoZfmu1HRHlBAA3/DDJwGVYhnxwi1QdzY2 olqNUjtmqCjGRS+02BQcxCKPmodMTy/IZRhtwkG/8ZtoYJqzyJgvwtf+nXzGHkc8rrvj c0T0y90XdulfmeP9QhBXRSPhIZTufSW2L2xFoY9DbS9LwQQjzcPQWTUk3M52tLiSeIqK eI9Q==
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=AkbO2nmIbxqWQczA3Zpi7cen7E+KRw31bvAmMazrEAs=; b=WE0mVwGoqYdXzQS6xRDf3O7U5blW62qABbBFJ6a6hMf3bvClrKzPztbgzRykFgOrna RKZJnA/wmGOotEqGGv8YWFRI9iXf/m+MjoZSjuNBiva9P840D1CLbetgtzjWXcUqtaoS sd5jLaBEcQd2ZWAT0taOCfxPXvCDn8l5QTGqmlnJu97BCjdeSbX2ezSV47x9VtqjHGcB 0WjPevR5W5KZlVLI7Q+UQz/gRgy2ZQAixg4aLWSUW0CUwFDl4LMX1xoJxYq+x7vYXPCy lvKs4LBnUuLJJmjTbujzFSjzl0F/r01E65wv4oB9+MAiQmo2FS44bopYCnCnqIh6X+qh NVoA==
X-Gm-Message-State: ALQs6tDch+cGMMvcP+ZIjnvT0W+4Y3z2SZ66gMPnj1+iNNze4FzPAvTa CRWrCbZEWBXked8SWx3fgY76bOmEOhYHBDzdsGk=
X-Google-Smtp-Source: AIpwx4/6xDj9RnUmWxGvMOmtMfp48/6AVWgwDxG/SZ8/WWqU5/9n9aNaktL+fbzHtQHE2kiN8DS5e3Fhp6tScwXEblw=
X-Received: by 10.46.146.13 with SMTP id k13mr3067293ljg.70.1523456531869; Wed, 11 Apr 2018 07:22:11 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.46.110.7 with HTTP; Wed, 11 Apr 2018 07:22:11 -0700 (PDT)
In-Reply-To: <4af646b5-bcb5-4f71-ae2d-88552e66b270@Spark>
References: <4af646b5-bcb5-4f71-ae2d-88552e66b270@Spark>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Wed, 11 Apr 2018 10:22:11 -0400
X-Google-Sender-Auth: mKmIUqAnChrg1UClzo80POYCUNg
Message-ID: <CADZyTkkqj6RvLysrgv_eOR-5X6zXdimu+oevB06u06s7D3NXQw@mail.gmail.com>
To: Jesús Alberto Polo <ietf@jesusalberto.me>
Cc: LURK BoF <lurk@ietf.org>
Content-Type: multipart/alternative; boundary="089e0827fb4469b38d0569935d59"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lurk/js5UtWRe-dvnaRYytjkvXWk6zWE>
Subject: Re: [Lurk] Questions about LURK TLS draft
X-BeenThere: lurk@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 11 Apr 2018 14:22:18 -0000

Hi Jesus Albertot,

You are more than welcome to intergate LURK with OpenSSL and NGINX. We
discussed this during the hachathon in London, so feel free to share your
thoughts or questions on the mailing list. I am sure you will get some
interesting feed backs.

If I understand correctly your question is whether the Key Server should
only "decrypt" the premaster versus computing the master secret.

One reason is to limit the scope of usage of the private key. Returning the
premaster can be used by any attacker to decrypt any random bytes ( of the
size of the premaster ) which could be used outside the scope of a TLS
session. Returning the master, instead limits the usage outside the scope
of TLS. A typical attack could consist in asserting you are the company "
www.example.com" and ask users to rely on the RSA public key to encrypt
some data. An attacker corrupting a edge server to gain access to the key
server could decrypt this data and as such impersonate "www.example.com".
In this example data is outside the scope of a TLS session. Returning the
master requires the attacker to reverse the master to the premaster to
access data which is harder to do.

Another reason is that within the scope of TLS providing the master enables
to provide perfect forward secrecy, and in our case the inability to
regenerate a master secret from an observed TLS key exchange. If the key
server returns the premaster, an attacker corrupting a edge server to gain
access to the key server and observing a TLS key exchange is able to access
the master and decrypt the TLS session. If the attacker does not have
physically access to the private key, he will have the opportunity to
perform the operation it needs. The purpose of PFS is to prevent that a TLS
key exchange can be replayed even if you have access to the Key Server. The
mechanism currently described is the one from [1] which uses a one one-way
function. The key server and the edge server uses hash( R ) for the server
random. A passive observer will see H( R ) on the wire, and needs to send R
to the Key Server for the generation of the master. This is assumed to be a
difficult operation.

This mechanism prevents requesting the Key Server from an observed TLS key
exchange. However,  we do not prevent "illegitimate" exchange to happen,
that is request outside a TLS exchange. Note also that by providing the
master, the edge server is able to do session resumption.... The following
document provides a security analysis of KeylessSSL [2].

Thank you for raising this question and please feel free to raise your
concern.

Yours,
Daniel


[1] https://tools.ietf.org/html/draft-erb-lurk-rsalg-01
[2] https://epubs.surrey.ac.uk/813643/1/mainKeyless.pdf




On Mon, Apr 9, 2018 at 4:32 AM, Jesús Alberto Polo <ietf@jesusalberto.me>
wrote:

> Hi,
>
>
> I’m currently working on an implementation of LURK to be integrated with
> OpenSSL and NGINX. After having identified all main parts and started the
> development, I have some questions regarding the LURK extension for (D)TLS
> 1.1 and 1.2 draft, more specifically for RSA as key exchange method
> (rsa_master, section 5).
>
>
> As I understand, the Edge Server (LURK client) only needs the Private Key
> to decrypt the premaster secret sent by the TLS client. I would like to
> understand why LURK server computes the master secret instead of only
> decrypting the premaster secret and letting the Edge Server compute the
> master secret (since it is terminating the TLS connection). In this way:
>
>
>    1. the LURK server would still protect the private key.
>    2. it’d be less intrusive for the TLS protocol (the only change is the
>    remote decryption instead of local decryption), it’d have less impact on
>    the OpenSSL code as well.
>    3. less error handling (however, LURK server would have less control
>    over the cyphers, TLS versions, PRF functions…).
>    4. the master secret would be locally computed by the TLS server and
>    never sent through the network (that is, even if an attacker compromises
>    the secure connection between LURK client and server and steals the
>    decrypted premaster key, they still need for other values of the TLS
>    connection in the LURK client).
>
> Thank you in advance.
>
>
> Best regards,
>
> Jesús Alberto
>
> _______________________________________________
> Lurk mailing list
> Lurk@ietf.org
> https://www.ietf.org/mailman/listinfo/lurk
>
>