Re: [TLS] Industry Concerns about TLS 1.3

Ryan Carboni <ryacko@gmail.com> Fri, 23 September 2016 01:53 UTC

Return-Path: <ryacko@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 48B4A12B720 for <tls@ietfa.amsl.com>; Thu, 22 Sep 2016 18:53:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_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 6L39Z1OHk4NK for <tls@ietfa.amsl.com>; Thu, 22 Sep 2016 18:52:59 -0700 (PDT)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 D766C12B8A9 for <tls@ietf.org>; Thu, 22 Sep 2016 18:52:58 -0700 (PDT)
Received: by mail-wm0-x231.google.com with SMTP id l132so3851143wmf.1 for <tls@ietf.org>; Thu, 22 Sep 2016 18:52:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=Z2SfC51j7KS+GSC9piHJ9z/ArxGpay+rpn145yYm67U=; b=o9PE6QdqRrB9IoAy7Axli+TwwtK8zn/tqH6FZlfQ9a5hw8pqSOmHnW+GsssTNlUyK3 F6uGmNJT3uFzXPvQuxaIIdTRrOYYBCy3OW9v5DHMkyDNZoQp25hcQu7ECcnq7pP0lP29 omudDpGd8IbY4Bnld/+j4TgdtGFNkGf7SI8MdNj5QRmTFGz+hCnMbalsZJ3J9ayQFzBJ pBMlWaXhPNs1aUgevpfHHD3aDobzO3Oz2MFihnyW1DPt1ztMEZc6v2QpEFhRPl4EDmbF c17cjtZ+YVc+4yBvHc3FxbuI+vgY5r6r5HrIfihr8CpPibkX81zA/DQDNTuQmqC4kYSX 8X8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Z2SfC51j7KS+GSC9piHJ9z/ArxGpay+rpn145yYm67U=; b=E8Kwu6syZJocZbYtF3sL1e12dzj3REHzD8bkfaNgfE3fnEFYs/NY8AxqdQs/y9CHjO emRISKg7H0oLzB1xKkFLimSxS7iSl+jvfXHFuXZBSz9LlBX/PRREqyA0OGu9FRHdAqco QMIuqNUPZhNwquYXMhQD0w2ncgD6rxmvzL9fWcYXBVoQAUBsDqnkJh0tKJfiqgwfyuYS k8KWFxW1bT6HiJKyhHMaGdUJoCxztUek16QpKcvldiWAP2wgY00jDEj/1QOWU8xhnLjA pj4NelFhP+w7Zxf9tuVR34hddVV20Zl4pV6oQScFhPhtO9LNrEC6ciXwAm+ii1xqvz6O twnw==
X-Gm-Message-State: AA6/9Rnrn9Yy/maexUTQJ0fh39Le1kUlEQOrj750DLKMEHXhpas/PaQy5fQM1ItxS36n/3GQ3c3pWyZdq9G2RQ==
X-Received: by 10.28.215.81 with SMTP id o78mr328745wmg.42.1474595577364; Thu, 22 Sep 2016 18:52:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.105.87 with HTTP; Thu, 22 Sep 2016 18:52:16 -0700 (PDT)
From: Ryan Carboni <ryacko@gmail.com>
Date: Thu, 22 Sep 2016 18:52:16 -0700
Message-ID: <CAO7N=i2TzAhCSAPrHirrsHywEWtn+5orXeJFVVtpUcwj3VQ+Kw@mail.gmail.com>
To: BITSSecurity@fsroundtable.org, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a1146eef89387ef053d230959"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/5i9ZzzUGPsC10xb2XnTG6XUwFpg>
Subject: Re: [TLS] Industry Concerns about TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 23 Sep 2016 01:53:01 -0000

>
> The impact on supervision will be particularly severe.  Financial institutions are required by law to store communications of certain employees (including broker/dealers) in a form that ensures that they can be retrieved and read in case an investigation into improper behavior is initiated.  The regulations which require retention of supervised employee communications initially focused on physical and electronic mail, but now extend to many other forms of communication including instant message, social media, and collaboration applications.  All of these communications channels are protected using TLS.
>
>
In the past ten years, we have seen botnets, root kit trojans, root kit
DRM, NSA TAO implants, OpenSSL heartbleed, heartbleed-style attack against
Cisco routers, cold boot attacks against expanded subkeys from a linear key
schedule, etc, etc...

I do not think encryption to be an obstacle of any kind.

Just use a forward proxy and move encryption from the browser to a
dedicated appliance? https://github.com/joshdick/miniProxy <- just from
Googling "php proxy"

And I think the only way to protect against heartbleed is require private
keys larger than than the MTU. But private keys are kind of pointless
nowadays when google has their private keys on thousands of machines around
the world.

Although DH depends on both parties generating a high entropy secret.
Personally I think the observation by an NTRU employee on NTRU-KE is better
than DH: https://github.com/NTRUOpenSourceProject/NTRUEncrypt/issues/7 "We
probably won't implement this exact idea -- this is basically each side
encrypts a secret, sends to the other, and puts the result through a KDF,
but with the slightly artificial choice that the encrypted secret is also
the private key and the KDF involves multiplication. Currently you can get
the properties that NTRU-KE gives (i.e. that both sides contribute secret
randomness) simply by using standard NTRU in each direction to send two
secrets and it's not clear what advantages NTRU-KE would have over that.
There may be room for a custom key exchange scheme in the future, but we'd
want to make sure it had advantages over the obvious way of doing it.


This shouldn't be a problem, but in the internet of things, DH is actually
less secure than normal public key exchange. Servers are more likely to
have entropy than embedded devices.

Ultimately, the world is insane.