IETF Logo Mail Archive

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

Jonathan Hoyland <jonathan.hoyland@gmail.com> Tue, 04 December 2018 16:39 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 EC366130F21 for <tls@ietfa.amsl.com>; Tue, 4 Dec 2018 08:39:45 -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 ouwX1LstgXf5 for <tls@ietfa.amsl.com>; Tue, 4 Dec 2018 08:39:44 -0800 (PST)
Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (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 08E21130EB4 for <tls@ietf.org>; Tue, 4 Dec 2018 08:39:44 -0800 (PST)
Received: by mail-vk1-xa33.google.com with SMTP id d201so3946781vka.0 for <tls@ietf.org>; Tue, 04 Dec 2018 08:39:43 -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=HUr3LtEXW5aG2gNbWOS+M1WuZBPSEYMGJ5cpBgoyL7Q=; b=T7d2YgZp/6P82aj24hNkr84veOYa0IWYZl+It/2nwIc6Aijj2P2x7v+2q96II0iqi7 0dUjxSgsyKefcM5G9mX/Bwzmu3dP0AP7i7+JIeSD5pyfh0agMTwATDI8uKGjMSHoyPhw aDGXelshykBM3MgT2XGbBlObR80fJ0psK6Y/G5KFEHPaCnpftaWa7bjjuKSCeXruKGCZ 9X0tXggsb+gNUiQuhqmu+EH9jvqzfke8Ax718x2lhp0OWvLds4FZRHRx2VEUJTNV/Z/1 +KolzQAvhSlwA0w5MmH5cDjTcD0p55XqJxbJQPmr5Dn1yMFMQmbEFVJDgo4rtgVrLczC gBAw==
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=HUr3LtEXW5aG2gNbWOS+M1WuZBPSEYMGJ5cpBgoyL7Q=; b=LWoTEjEMgO1QQ6ATdtADnUZELOpl3puLezxHWx2PH1YLcFhV05Mrbyuh9TMSN539kB IHhwG8yTLhFbLo85bO6G+kGxf/lvbjHJ7Wc/wR4DKsk0xKLER/L4FROlKfigO9+1AuCC AYq4NauHhgNGIdsbbSmNAzOROG8sld2o0PJ5hmGqXU+jAzGEQmHAmrI6MYf/te2m2nPH /qCqSeU9cIBizIXpalg1eU2QojeKz+LQv9letlyPkWAjl5PbWxwQupMgNIPVK70+m08h YFSliwwXbqQBiwvhce1SKGbDLeP8G8TGE5aWhKAPfi6XJ4MVspDWJNXf5M74YN2wo6iV qi3g==
X-Gm-Message-State: AA+aEWZFRQCiunnSJGSJmIGMaKPFO94wQhDxEJMiU/q2++NqqCK/bf8I ZhcHfgTQeTkIC+dTWMCRbwxPwqNW8DTvLmTp9bkYS6Oa
X-Google-Smtp-Source: AFSGD/Wlh3byegoKu6plNLiLWfZzvScZeBnYGXwZf6WS5MnvYC8NYl97VWVNxlvhFM+v317C27HdjGV1+XfzlX+sRNU=
X-Received: by 2002:a1f:19d6:: with SMTP id 205mr8838292vkz.53.1543941582681; Tue, 04 Dec 2018 08:39:42 -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> <CAHOTMV+vPkM-=Qsto-8-ipFuGsNKkH_U=BEY_mB=7CM7tto3Mw@mail.gmail.com>
In-Reply-To: <CAHOTMV+vPkM-=Qsto-8-ipFuGsNKkH_U=BEY_mB=7CM7tto3Mw@mail.gmail.com>
From: Jonathan Hoyland <jonathan.hoyland@gmail.com>
Date: Tue, 04 Dec 2018 17:39:30 +0100
Message-ID: <CACykbs12+51PokVymo5aB0eQ9PT36VqV92VmwBwoc+NPCEcpJA@mail.gmail.com>
To: Tony Arcieri <bascule@gmail.com>
Cc: Nico Williams <nico@cryptonector.com>, Crypto <cryptography@metzdowd.com>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000096fb5c057c34e9d4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xbUifVh2LkCsxAvuUZ10QkTywlA>
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 16:39:46 -0000

Isn't there a lower bar at the IETF for defining new cipher suites, as long
as you're not seeking a "recommended" setting?

I think escrowing lower down keys / not MACing the messages beyond the
handshake means that you lose authenticity and integrity of the message
data, which is unattractive.
How burdensome would the extra few bytes actually be, given that the
alternative is substantially weaker security?

Regards,

Jonathan


On Tue, 4 Dec 2018 at 16:19 Tony Arcieri <bascule@gmail.com> wrote:

> On Sun, Dec 2, 2018 at 3:36 PM Nico Williams <nico@cryptonector.com>
> wrote:
>
>>  > 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.
>
>
> Wouldn't escrowing only the client/server application traffic secrets
> (instead of keys higher in the schedule) avoid this problem? These keys
> would permit the one capability "visibility" appliance vendors allege to
> care about: traffic decryption, without permitting others like session
> resumption.
>
>  The most obvious escrow design requiring no changes to the clients is to
>> use a static eDH key on the server-side.  The next most obvious such
>> design is to have the server talk to the escrow agent.
>
>
> It seems like with an out-of-band escrow agent, the traffic secrets could
> be escrowed with no changes to TLS.
>
> --
> Tony Arcieri
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.23.0 | Report a Bug | By Email