Re: [TLS] draft-green-tls-static-dh-in-tls13-01

Eric Mill <eric@konklone.com> Fri, 07 July 2017 21:13 UTC

Return-Path: <eric@konklone.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 EC0C6131723 for <tls@ietfa.amsl.com>; Fri, 7 Jul 2017 14:13:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com header.b=r6Qzb3vs; dkim=neutral reason="invalid (public key: not available)" header.d=konklone.com header.b=GroJ2apu
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 fqT-0_HbwLvO for <tls@ietfa.amsl.com>; Fri, 7 Jul 2017 14:13:58 -0700 (PDT)
Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217CC1316B4 for <tls@ietf.org>; Fri, 7 Jul 2017 14:13:58 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 59585923E5 for <tls@ietf.org>; Fri, 7 Jul 2017 17:13:54 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=dWZcqealD3asHJSgr+rz8ilMK4s=; b=r6Qzb3 vsr8agfec5YHSdj8OdPzX0fRhaXpI+i+OyJJ9arVW0sHbfUJVgg6X1qWTlrDcr6U Bn/BX3ULgV3V5b98e1Mf88Az5Xz/dVTD7vcgo1Ap/9eftI5edXNJtO1bMdptYUR/ 64ksW24T+dBqGZCPfRDvB8GXgFt/iH06//hQg=
Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 5115C923E4 for <tls@ietf.org>; Fri, 7 Jul 2017 17:13:54 -0400 (EDT)
Received: from mail-yb0-f177.google.com (unknown [209.85.213.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id D2C42923E3 for <tls@ietf.org>; Fri, 7 Jul 2017 17:13:53 -0400 (EDT)
Received: by mail-yb0-f177.google.com with SMTP id f194so14449171yba.3 for <tls@ietf.org>; Fri, 07 Jul 2017 14:13:53 -0700 (PDT)
X-Gm-Message-State: AIVw110RdmzzRDeABh4b11nAKTRHMOo2god4r3059HlpJCKR3mccT1c8 +G+Msh+5OY7L62g79cSo6rj0FSdZnA==
X-Received: by 10.37.246.18 with SMTP id t18mr6184835ybd.211.1499462033139; Fri, 07 Jul 2017 14:13:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.60.199 with HTTP; Fri, 7 Jul 2017 14:13:12 -0700 (PDT)
In-Reply-To: <A0BEC2E3-8CF5-433D-BA77-E8474A2C922A@vigilsec.com>
References: <CAPCANN-xgf3auqy+pFfL6VO5GpEsCCHYkROAwiB1u=8a4yj+Fg@mail.gmail.com> <CAL02cgRJeauV9NQ2OrGK1ocQtg-M2tbWm2+5HUc4-Wc8KC3vxQ@mail.gmail.com> <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <CAJU8_nXBFkpncFDy4QFnd6hFpC7oOZn-F1-EuBC2vk3Y6QKq3A@mail.gmail.com> <f0554055-cdd3-a78c-8ab1-e84f9b624fda@cs.tcd.ie> <A0BEC2E3-8CF5-433D-BA77-E8474A2C922A@vigilsec.com>
From: Eric Mill <eric@konklone.com>
Date: Fri, 7 Jul 2017 17:13:12 -0400
X-Gmail-Original-Message-ID: <CANBOYLVSi3c4joq245rVZoyEU2AYfvdznSxWQsv1et2C6TX7pA@mail.gmail.com>
Message-ID: <CANBOYLVSi3c4joq245rVZoyEU2AYfvdznSxWQsv1et2C6TX7pA@mail.gmail.com>
To: Russ Housley <housley@vigilsec.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, IETF TLS <tls@ietf.org>, Matthew Green <matthewdgreen@gmail.com>
Content-Type: multipart/alternative; boundary="f403045da836d6f8ca0553c0b518"
X-Pobox-Relay-ID: 2E56198A-6359-11E7-8F0C-61520C78B957-82875391!pb-smtp2.pobox.com
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=konklone.com; h=mime-version:in-reply-to:references:from:date:message-id:subject:to:cc:content-type; s=2016-12.pbsmtp; bh=dWZcqealD3asHJSgr+rz8ilMK4s=; b=GroJ2apulm4DQ7sqiVDpHCQCgHaF/WMUvJ2wpboqXMuSA1lm03PZp0vfPZcS8fm+Qp664q5dbhqRoGmypA2IIsHMXxu1cUEUjDNCxwllqUCh5koxB6kf7SLSS6yoruchVFcedveUlOeiGxcLOoLJtnXvdzyHNMeMwwMuBdIjeiY=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-rrLqznmSPD5EAmDvG0UNhpnTdU>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 07 Jul 2017 21:14:00 -0000

On Fri, Jul 7, 2017 at 4:04 PM, Russ Housley <housley@vigilsec.com>; wrote:
>
> The enterprise wants forward secrecy on the public Internet. Terminating
> the TLS session at the load balancer preserves forward secrecy on the
> public Internet.
>


> In your response, you ignored a fairly significant point in my previous
> post.
>
>         In some industries, there are regulatory requirements that cannot
> be
>         met without access to the plaintext.  Without some authorized
> access
>         mechanism, the enterprise will be forced to use plaintext within
> the
>         datacenter.  That seems like a worse alternative to me.
>
> From my perspective, draft-green-tls-static-dh-in-tls13 is not advocating
> outdated crypto, like RC4 or MD5.  Instead, it is using exactly the same
> crypto algorithms and key sizes as draft-ietf-tls-tls13.  Again, this seems
> like a much better way forward than plaintext throughout the datacenter.
>

Your response is also failing to address a very important point, by
presenting the choice as either static-key TLS or plaintext. That's clearly
not the case -- you can maintain traffic visibility at endpoints within
your data center, by forcing traffic through terminating trusted proxies
which log the same network traffic data you would get from passive
monitoring. You can do that with forward secret TLS today.

I'm sure it's not as easy to change your designs to incorporate proxies as
it is to just rely on the network monitoring infrastructure you already
have in place, but that's not a good enough reason to insist that the TLS
WG standardize an RFC which can plainly be used for wiretapping.

It's also passing up an opportunity to gain the benefits of forward secret
connections within your data center, which should really be a best practice
and requirement for any organization managing data that merits strict
regulatory oversight.

This comes across as asking the IETF to contort itself around its own
stated goals so that the enterprise doesn't have to do any heavy lifting to
keep up with security trends. As explained so far, this seems like
something the TLS WG should reject.

-- Eric


>
> Russ
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
konklone.com | @konklone <https://twitter.com/konklone>