Re: [TLS] Industry Concerns about TLS 1.3

Judson Wilson <wilson.judson@gmail.com> Tue, 27 September 2016 08:33 UTC

Return-Path: <wilson.judson@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 043FF12B09A for <tls@ietfa.amsl.com>; Tue, 27 Sep 2016 01:33:11 -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 J9zwt-xGfvIu for <tls@ietfa.amsl.com>; Tue, 27 Sep 2016 01:33:08 -0700 (PDT)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 455A512B098 for <tls@ietf.org>; Tue, 27 Sep 2016 01:33:08 -0700 (PDT)
Received: by mail-lf0-x234.google.com with SMTP id g62so14398843lfe.3 for <tls@ietf.org>; Tue, 27 Sep 2016 01:33:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=c/Nao4ZeWvumjWzCsYdE8+BWMLGd6w2CIya1O4zOqyA=; b=DG6t1nFsC5vQnCSiANDBC9a4urTkNk4bWGfRuz13NhUETIjkg88kgntCnkTMw6j0mC Keh19Rr989juG32dmf4KetVTK0FnMzXnkSL4eiOcU8x6GkaKQUvt78Ujz5P/0LrQZyYe Mr6GXoh9pxB8/BoD9fvFfXRZdO5g5w0eHFacd+KajhOWdWKGMRlNL/DyTgAAB6kcPIe8 uuE8fts2/ccNQvDXTJomT/Ou104fX/sz0W+ykX7ZRyXXUV64rVShk62jY0/wytyT3uGu ytOAMMzx0TofpB6YiXNAt3BINeQaqHXj4dEbz4iPsMaF+YTAo8C5uxLjXw3+uRT4/bjz X5yA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=c/Nao4ZeWvumjWzCsYdE8+BWMLGd6w2CIya1O4zOqyA=; b=QCRKB+AE+MAqtrJXdta1eZrWAN1f9o/6aRtP1ylzeETG/dLQTAJR8Dd2xFqi1VM1qx K/rM7xguvbVIDZIDuimGBicPJwv2d81ho7XbZb0qau0jiqDK6RA9ZfYUjPQgZg3f/FNW 9hLyiEqYy61sHT7hEFQv8xZFFaX3IUeb3TRoxkFInNIr8ohVqU6GBzo1Rlys8QytEoEi ey6MFuZjFTVV9jaDOJzBKgXz3W9jmPvKmsWePSy6uRCFIsBz5yQhzT+TwEJWUh9W+YJB PmtjoXbvCvORh/77dXHi64uvl46xbOSxw7Ycb3oo2nIzuJM9JYFBVFarJ1bGD5zpF5Yz qxLA==
X-Gm-Message-State: AA6/9RmJhKwF8VlTtLcz28Jak9v4kVIM+hjKt2+vVcZiHgrp/BXn/c6K/Ff108mFk/EOHGHpE9gIZWe5g9eY2w==
X-Received: by 10.28.173.144 with SMTP id w138mr1559778wme.12.1474965186180; Tue, 27 Sep 2016 01:33:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.160.197 with HTTP; Tue, 27 Sep 2016 01:33:05 -0700 (PDT)
In-Reply-To: <11BA66BB-3B08-4170-8F84-A06E1B4214AC@dukhovni.org>
References: <DM5PR11MB14191AABED7E43F904133787F4C80@DM5PR11MB1419.namprd11.prod.outlook.com> <r470Ps-10116i-4C64C69C85D443BF91A20D2FDB8F48E9@Williams-MacBook-Pro.local> <DM5PR11MB1419320109EC18605B1D2072F4CD0@DM5PR11MB1419.namprd11.prod.outlook.com> <BD40CD6E-568F-40A3-838F-C4AC9C9AF9C8@dukhovni.org> <CABcZeBNKzr7tmYPz2BBt=cSvLnhniUosSbHZCU8qS42bXoO=_g@mail.gmail.com> <11BA66BB-3B08-4170-8F84-A06E1B4214AC@dukhovni.org>
From: Judson Wilson <wilson.judson@gmail.com>
Date: Tue, 27 Sep 2016 01:33:05 -0700
Message-ID: <CAB=4g8KqrO5EN20rawExHoM3qw9S8se8vQJupK0_A_8o8Dytiw@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=001a11444a28fa7c9d053d79173d
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/rOmMD5n55zBgVnHzEkI0UA0xtec>
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: Tue, 27 Sep 2016 08:33:11 -0000

>
> Yes, I know that changed.  It was an example of something that works with
> TLS 1.2 even when PFS is used.  With TLS 1.3 server or client
> implementations
> can find other ways to retain long-term records of session keys.  The
> capability
> to do that is not a requisite or desirable protocol feature.  Different
> user
> communities will have different needs, and the best solution is to provide
> security by default, and cede control of the result to the endpoints.



I don't believe that storing this information on the endpoints is a great
idea, simply because the monitoring equipment will have a difficult time
ensuring that the information exists when it is needed. It also increases
the number of sites that are risks to compromising past data.

I think this challenge is best solved by putting the information on the
wire in some way, possibly as a special industry-specific extension (used
only by those who are bent on shooting themselves in the foot). The benefit
being that if the TLS channel is alive, the session information is
available to the monitor.  Just as a strawman, the client could transmit
session info in special records, encrypted by a public key, and the
monitoring equipment could scoop these up. For compatibility with servers
outside the network, a middlebox could somehow filter out these records.

It sounds like the need is large enough that such an effort is feasible,
and it would be good to keep normal TLS 1.3 unambiguously forward secure.
(There IS still the question of how to make sure that the extension is not
enabled in endpoints it shouldn't be.)

On Mon, Sep 26, 2016 at 5:20 PM, Viktor Dukhovni <ietf-dane@dukhovni.org>;
wrote:

>
> > On Sep 26, 2016, at 7:21 PM, Eric Rescorla <ekr@rtfm.com>; wrote:
> >
> > There are other ways to accomplish this.  For example, the server might
> > use session ticket keys that are stored centrally encrypted under a
> > suitable escrow key.  If clients always enable session tickets, then
> > every handshake will result in the server returning a session ticket,
> > in which case the session can be later decrypted if the session ticket
> > keys are available.
> >
> > This actually doesn't work in TLS 1.3 because the resumption master
> secret
> > is not sufficient to decrypt the connection in which it was established.
>
> Yes, I know that changed.  It was an example of something that works with
> TLS 1.2 even when PFS is used.  With TLS 1.3 server or client
> implementations
> can find other ways to retain long-term records of session keys.  The
> capability
> to do that is not a requisite or desirable protocol feature.  Different
> user
> communities will have different needs, and the best solution is to provide
> security by default, and cede control of the result to the endpoints.
>
> --
>         Viktor.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>