[Lurk] lurk tls12 extension update & thoughts

Daniel Migault <daniel.migault@ericsson.com> Sat, 26 May 2018 18:20 UTC

Return-Path: <mglt.ietf@gmail.com>
X-Original-To: lurk@ietfa.amsl.com
Delivered-To: lurk@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 70EFD12E044 for <lurk@ietfa.amsl.com>; Sat, 26 May 2018 11:20:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.402
X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9T96yi0RPsm6 for <lurk@ietfa.amsl.com>; Sat, 26 May 2018 11:20:20 -0700 (PDT)
Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (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 2EDD212E041 for <lurk@ietf.org>; Sat, 26 May 2018 11:20:20 -0700 (PDT)
Received: by mail-wr0-x229.google.com with SMTP id w7-v6so2190582wrn.6 for <lurk@ietf.org>; Sat, 26 May 2018 11:20:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=4dsGfYbhL9VC45Hjh5nsjtVbZCbPfAkh87F8pqH84Co=; b=S7lxOpBNIXwRK9ggvHZ5zq/jLphoY7JqnGh9XZ1dKPayM0HsMaJWQNUdjiuCvX9cG3 GJ6ShF6LasVe2jAwB+NDAH/nqtGd4ZpeMM9WiXwXcGP5gEDrKWZl4sy90hT1vTxTGKBP olQN6WjEr73WcTEJCRpid1IKa7W4+gszCvzWVzUwxotjdBmOLfa7Fx5ncQnURqQP82ig Y+gqohF8TdZe/6b315mSqisrHoEm+JYksLfKgH6mIJcVfMkmrEohO11Clt6hHvBOTqi3 x1et594g6e0NbRAExAUsUhaEsALPGhKwkB/x7c9nIKGcLyle1mP2AhMthOIYS8IRWm47 m2Ow==
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:from:date:message-id:subject :to; bh=4dsGfYbhL9VC45Hjh5nsjtVbZCbPfAkh87F8pqH84Co=; b=To6KbC/RtZ0cXAYlMO2gQlInxP33m8Dwk1HvKOGGcc7p+QFqdEReR6IIVb6JPZNx4G z9izW0aWaVq/fMJ4d16xFWT+yE5CLGeB9AkGqzYrgbCHoBN0tunSjC4fT7p3KmaNYSfE KaNuAWstmlRNv7+6Nq9Hdl5lXgvVB9uDDdfc36qxaK1ct3L+lVSHp8QsOy7bQ0hjvz3C Web9xrAnrubZBQGsGrzb7C+gQf/77WGuraiBHbkcOSW0w2bBtzO4DISfExP60lPNej8x b3jYt9Cmw4kHwXfGrzHaZ9eQt/e0WNSfAoAhzqYQvZWhigFrSviiv63gwTLabosS4aWb dtdw==
X-Gm-Message-State: ALKqPwdlKUtpGMwLB9PzSLUkSUnRmKIUa3SOnAXTBRkBuh37x8xXi3a5 VauK61acZzYpEhUzjeOWMZ8335++D5aPvYL3K82TsQ==
X-Google-Smtp-Source: ADUXVKKimqvabB+DT5S7oBuv7nNkva0af7GVbNFzISIlKDb24UHDPHULy5PKAzs9ofy0rW6YjMGM8cZ1tmCIvMpMONU=
X-Received: by 2002:a19:4dc5:: with SMTP id a188-v6mr3953315lfb.99.1527358818538; Sat, 26 May 2018 11:20:18 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 2002:a2e:510a:0:0:0:0:0 with HTTP; Sat, 26 May 2018 11:20:18 -0700 (PDT)
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Sat, 26 May 2018 14:20:18 -0400
X-Google-Sender-Auth: xYcsNnHeAFGT68thYVn8LUxultc
Message-ID: <CADZyTkmPu+t-4cCEV9i49n0VC=9BR3RYgn9Y7TiFGtk4rT6k4w@mail.gmail.com>
To: LURK BoF <lurk@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d2d8a5056d1fefd1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lurk/0-di1yie2yHvYIh5-6mrz3A4pCM>
Subject: [Lurk] lurk tls12 extension update & thoughts
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: Sat, 26 May 2018 18:20:23 -0000


The working version is available on github:

Please find below my thoughts as well as how the working version has been
updated. Feed backs or comments are appreciated  ;-)


a) tls version

I believe this parameter is not necessary anymore. Although the current
document designates the extension as "tls12" it also generating masters for
TLS 1.1 and TLS 1.2. I suggest we focus the extension on TLS1.2 only to
remain coherent with the designation. This makes the the tls_version
parameter useless and I suggest we remove the parameter.

This has also been suggested by Ioana in her review.

b) other prf hash function than sha256 for TLS 1.2 ?

As the hash function "intrinsic" or "sha256" is determined by the
authentication method, I am inclined remove these values and only specify
the hash function used for the pfs. If things change in the future other
value for hash suites may be added.

prf provides hash function agility and currently explicitly specify the
hash function of the prf as well as the hash function of the pfs. On the
other hand, the hash associated to the prf seems to be SHA256 with TLS1.2.
That is RSA uses SHA256 to generate the master secret and eventually
extended master secret uses SHA256 to derive the session hash. ECDHE does
not specify the hash function as it is provided in the sig_and_hash
structure. As a result, the hash agility is limited to the hash function of
the pfs and hash function determined by authentication method.

c) perfect forward secrecy

The cost of implementing perfect forward secrecy is a hash computation on
the edge server and on key server. This makes a maximum of two additional
hash computations and I believe we should remove the "null" value.

To make a long story short b) and c) propose to change:


PRFAlgorithm = Enum( BytesInteger(1),
    sha256_null = 0,
    sha256_sha256 = 1,
    intrinsic_null = 2,
    intrinsic_sha256 = 2,


PFSAlgorithm = Enum( BytesInteger(1),
    sha256 = 0,

and dupdate the draft accordingly.

d) Extended premaster does not implement perfect forward secrecy, nor anti
replay. The main reason is that the opaque hash is transmitted, rather than
the full handshake. I believe we should address this by providing the key
server the necessary parameters to generate the session_hash. This needs to
change the design for the extended master.

e) Capabilities exchange has been updated