Re: [TLS] ETSI releases standards for enterprise security and data centre management

Jonathan Hoyland <jonathan.hoyland@gmail.com> Tue, 04 December 2018 15:34 UTC

Return-Path: <jonathan.hoyland@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37027130EFA for <tls@ietfa.amsl.com>; Tue, 4 Dec 2018 07:34:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 FdWK6vHxxFNw for <tls@ietfa.amsl.com>; Tue, 4 Dec 2018 07:34:22 -0800 (PST)
Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 BE5F2130E95 for <tls@ietf.org>; Tue, 4 Dec 2018 07:34:21 -0800 (PST)
Received: by mail-vs1-xe32.google.com with SMTP id n10so1213952vso.13 for <tls@ietf.org>; Tue, 04 Dec 2018 07:34:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JZbPRLLpEpMnAQ3tUlj8WcsAXqocvdrCA+gKvYVb+GY=; b=nKzjExbVsn2nK7mAK15DHBhwFdC+pC2+PwoFssGr6EGd6vEbEYtd+hPCLbE8ptaYyO H5lYdNdI1Q6zxS1qBVOk6FsOZJf0UbfsnFSuqvmlDcYySq5jGOHCmhIEHbr2Sz2I4f92 wCctv3lHEuCpDq09KdkKXOC/vLGv4uzhH8qkcz91MKDW+DgO6fPYzzhqt7rBSSRWIica IbgVkwB1DpvitmqyyRJOdcWM+lkh6WuWfH9Z5PLEXxfSfGej+qeENpUK7ssV8HbtuckG VE+1NFuNu661KVviQxJJvbVPT44OVVhyuQI0mt6FiLziDODAY1ONXDlxNV1BIIcCFAdk HZZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JZbPRLLpEpMnAQ3tUlj8WcsAXqocvdrCA+gKvYVb+GY=; b=JY7O9qkJf3VAGmhuyiC3gXLalgZKMSO66B8CB81f0zwUJu8wSetMfAjiETjG6oUX83 ZeHHCybUpyPwD4GGuL4+W/DDIf/pwxdSFWo93g6yzSvEJgalFEGuW/jE3OQzL8kQ3iS4 hhfltgGzefCnL0M9oAwqgJ60Uhu/T4IID3bmo6rvKkxq5te1z/FALewHwNZzgfCUurks TgB/jHcjTZsI9vKqeQRvsPIshAMUO9Ac3RzjsBOL+l4kq1RugxXJ3IkNXJyPcBkGYQB3 rYhenv4boOZbBKvCjJ8cB7Xq7SdrKtbnxfeN6CNSro+kg4ryJMy9yvABciqr28IuveA5 f6mw==
X-Gm-Message-State: AA+aEWbdnbM76GlvQoP8rkqLcNJnvGdWcMIzn5t4vD4DPfJtWAOn9nja rr9KD8A/FERMre8H32PYy0kS9pixe2ayIk4V9dE=
X-Google-Smtp-Source: AFSGD/Vaj2NY1VHUjqhAMO501i+Q7pkimgb5L74uVXDDF+yYNO4Nx19K2saANGVqOXQL0xZRkcemu36U/9h3WgRz+Fk=
X-Received: by 2002:a67:e15e:: with SMTP id o30mr9193850vsl.66.1543937660405; Tue, 04 Dec 2018 07:34:20 -0800 (PST)
MIME-Version: 1.0
References: <CADqLbzKd-AgDRv2suZ-0Nz4jNUqKg0RNT8sgQd-n793t+gEN3g@mail.gmail.com> <CAHOTMVKZT1ScvHeP3=Kv2zodVimHkaAtG-2DTq6ojnF+q-OMSQ@mail.gmail.com> <20181202233553.GD15561@localhost>
In-Reply-To: <20181202233553.GD15561@localhost>
From: Jonathan Hoyland <jonathan.hoyland@gmail.com>
Date: Tue, 4 Dec 2018 16:34:08 +0100
Message-ID: <CACykbs0ZESBKYzF9=VxbmrLXkqZs843MpQsjiMYK10Q3BLf85Q@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cdceb1057c33ff35"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/9-3V1brdxmzmcXizU3eG7yhBHVQ>
Subject: Re: [TLS] ETSI releases standards for enterprise security and data centre management
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Dec 2018 15:34:33 -0000

Is it necessarily true that any key escrow system must allow resumptions?

Just to play devil's advocate, consider defining a new cipher suite that
appended a MAC to each message before applying one of the other cipher
suites.
If the MAC is keyed with a key not derived from the master secret, but from
some other value shared between the client and server, but not the
middlebox, then the middlebox would be able to read all* the traffic, but
would not be able to successfully resume the session.

*The middlebox would not be able to verify the tag, so technically it can't
check /everything/, but it would be able to read the data on the channel
without being able to modify it.

Regards,

Jonathan



On Sun, 2 Dec 2018 at 23:36 Nico Williams <nico@cryptonector.com>; wrote:

> On Sat, Dec 01, 2018 at 07:59:45AM -0800, Tony Arcieri wrote:
> > This does not seem to address a problem which was brought up when the
> > similar draft-green-tls-static-dh-in-tls13-00 was discussed, namely any
> > system in possession of one of the non-ephemeral-ECDHE private keys,
> > ostensibly for the purposes of passive traffic decryption, can
> arbitrarily
> > resume decrypted sessions and therefore impersonate any observed clients.
> >
> > I'm not a fan of systems like this, but I believe for security reasons
> they
> > should be designed in such a way that only the confidentiality of traffic
> > is impacted, and a "visibility" system isn't able to leverage the
> decrypted
> > traffic to resume decrypted sessions and thereby impersonate clients.
>
> Any key escrow system will have this property.  Given the session keys
> (or a way to recover them) you can resume decrypted sessions.
>
> If I had to I would build a corporate TLS 1.3 session key escrow system
> as follows:
>
>  - use a keyed PRF/PRNG to generate the ephemeral DH keys, with two
>    inputs, a secret key shared with the escrow third party, and a number
>    generated randomly:
>
>    edh_key = DH_key_gen(seed = PRF+(escrowed_key, r = getrandom()));
>
>  - log to the escrow third party {connection ID, random} for each
>    connection (the connection ID can be a handshake transcript hash).
>
>    (it's even safe to log the random number r in the clear, as it alone
>    is insufficient for recovering session keys)
>
> This would preserve all the properties of TLS 1.3 and would work for any
> other version of TLS with EDH too, and also for any other protocols that
> use ephemeral key agreement (SSHv2, IKE, ...).
>
> It's more work to integrate this than to use RSA key transport with
> escrowed RSA key orchestration, but it's one-time work (do it for about
> six or so open source implementations and you've got 90+% coverage).
>
> I'm sure upstreams would accept this sort of contribution as it is
> better for everyone outside corporate environments if we can just stop
> the pressure to go back to RSA key transport.  It's also better for
> corporate environments, as insiders are the largest threat there, so
> forward security is still a plus even in corporate environments.
>
> Nico
> --
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>