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

Colm MacCárthaigh <colm@allcosts.net> Wed, 19 July 2017 16:35 UTC

Return-Path: <colm@allcosts.net>
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 E6569131472 for <tls@ietfa.amsl.com>; Wed, 19 Jul 2017 09:35:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 ahBvLao-tYuE for <tls@ietfa.amsl.com>; Wed, 19 Jul 2017 09:35:36 -0700 (PDT)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 6DCF912F3CB for <tls@ietf.org>; Wed, 19 Jul 2017 09:35:36 -0700 (PDT)
Received: by mail-yw0-x22c.google.com with SMTP id v193so2733453ywg.2 for <tls@ietf.org>; Wed, 19 Jul 2017 09:35:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Qa89sV6rKVUO2NXoAWnS60CHcJcI9iLQ8nb1fSkpzgM=; b=r7hMRYlXmNwo1WfM9hfekTW5ju4sqD04B4UG8d2s38zOgmeyQBmYKRaRwxIq/U6pZY hbuyW8LEt5y5/o07/Tpe6pb6pCc2ts1c0cQMcelRzlHzb8Dva/5vGupZXeUw7GQajSVS EddFltyQGPbHWXrVpcVB7rgnya/tXEGVGlxuRU7+tXki8CUn3cE8vijdOuf97Fye4rGP /ntDR0nYat2gYteBukUP1zGrAp/tWKPnbvG92UzcQVr4QkQ5FfvrndNkTLZgGy3VsL9c 8U0+Rgx6bLMhoG9RnEXI9De++edvNiQJ9QKVpOA51b2A0ZNEKUojes5qmBUkC88PsBEP ffNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Qa89sV6rKVUO2NXoAWnS60CHcJcI9iLQ8nb1fSkpzgM=; b=DRaeMx+n8ppkvf3z5p+xxTIKbAQud1e5y1LBQ1kcaCUTt3PO5OJS/68u2MFZ9AIe65 gbQ1D9YUos1+fJG3AeMrIn+5YePrU7Ooq+RCF1VymhLeoYu8jkIor9hZWOMMJxaP+FQ4 FrDGr3Xh6iE8oQ4jqg6ybrlCOEtfrAKxmxAR7ASbFoI66HFQmpcjPR9SHiiPivgS1fcM AEvFMEl4Y8Ph7atQDHoBrs98Q/Bn6mIAjxgGsuheWqNqu3kh5AAmGmsWPHSAyQ6UFlMB vARidyfN5l5ZlzNOa3qAc1jPQyi/RNEdb1wBGjFToeZu7vr9brLwp5Hai/pxqPFuQ5OB jJIQ==
X-Gm-Message-State: AIVw113Ck6+qvBw/7g/KjWIRE4qL2n52hAF7VqaNv1xfxwCN4eiOPm6P p+lpUDwFHL7DVzKH47/qLrLblLH24Qya
X-Received: by 10.129.182.77 with SMTP id h13mr756185ywk.90.1500482135563; Wed, 19 Jul 2017 09:35:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.27.4 with HTTP; Wed, 19 Jul 2017 09:35:34 -0700 (PDT)
In-Reply-To: <B08F0D98-FAE9-494C-AA96-4CE89792B770@ll.mit.edu>
References: <CAPCANN-xgf3auqy+pFfL6VO5GpEsCCHYkROAwiB1u=8a4yj+Fg@mail.gmail.com> <CAOjisRxxN9QjCqmDpkBOsEhEc7XCpM9Hk9QSSAO65XDPNegy0w@mail.gmail.com> <CABtrr-XbJMYQ+FTQQiSw2gmDVjnpuhgJb3GTWXvLkNewwuJmUg@mail.gmail.com> <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com> <a0a7b2ed-8017-9a54-fec0-6156c31bbbfa@nomountain.net> <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net> <CAN2QdAGRTLyucM1-JPmDU17kQgAv0bPZNASh54v=XoCW+qj48A@mail.gmail.com> <CACsn0cnc0X5++cOvTNsboda8J42qg3VDquZ4Va-X-YDcggnbvA@mail.gmail.com> <7423703D-5277-4F78-A2ED-1B7E152E7B08@arbor.net> <CACsn0cmo0HXBj7MidTTwkgE+Hwed9SrEODSzN8oURzQHJTW1aQ@mail.gmail.com> <E5BF12C2-B79A-444B-B4C2-90D28B40CCAC@arbor.net> <CACsn0c=_OT8R6SSr0P3RvT7Qx+smfz1DAKjH9Gni+jM8Ue4v5A@mail.gmail.com> <CAAF6GDc9e9TGWVaOjdb83AFH=z2kt41Rje+r4Ureoc6KVgEUJg@mail.gmail.com> <B08F0D98-FAE9-494C-AA96-4CE89792B770@ll.mit.edu>
From: Colm MacCárthaigh <colm@allcosts.net>
Date: Wed, 19 Jul 2017 09:35:34 -0700
Message-ID: <CAAF6GDdSnCggfsrSG68An348ngR+fcb+9nQcKvJJGFtxg8NzJw@mail.gmail.com>
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
Cc: "tls@ietf.org" <tls@ietf.org>, Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary="94eb2c1cbeb0aecac10554ae38fc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/mzPa0wWGgP_1fUTouVLMmOrv-AY>
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: Wed, 19 Jul 2017 16:35:38 -0000

On Wed, Jul 19, 2017 at 9:26 AM, Blumenthal, Uri - 0553 - MITLL <
uri@ll.mit.edu> wrote:
>
> Same question. At some point in time you need to decide to start examining
> all the traffic. At that point you can start capturing its plaintext. The
> proposed alternative seems to be capturing the ciphertext and the key so
> the ciphertext can be decrypted later – which makes no sense to me.
>

That's not what I've seen. Instead, I see administrators creating port
mirrors on demand and then filtering the traffic they are interested in
using standard tcpdump rules, and I see MITM boxes that selectively decrypt
some traffic to look inside it and apply some kind of security filtering.
In the former case, DNS lookups and IP/port destinations are commonly used
to trigger some suspicions too.


> They are, though it's a big change. I think we can do better than logs; a
> mechanism that's in TLS itself could be opt-in and user-aware, and so less
> likely to be abused in other situations. There's also some basic security
> model advantages to encrypting the PMS under a public-private key pair, and
> one that isn't using the private key that the servers themselves hold.
>
>
>
> To use the key you need to have the corresponding ciphertext stored.
>

That's not how the tcpdump/wireshark approach usually works. You give it
the private key and decrypts the TLS connection as it's happening.

-- 
Colm