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

Colm MacCárthaigh <> Wed, 19 July 2017 16:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2E9C8124234 for <>; Wed, 19 Jul 2017 09:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 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_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tVXVrZPIzTSZ for <>; Wed, 19 Jul 2017 09:20:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 98A601287A5 for <>; Wed, 19 Jul 2017 09:20:10 -0700 (PDT)
Received: by with SMTP id w187so1363438ybc.0 for <>; Wed, 19 Jul 2017 09:20:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=J5z+qfHt8u7hvuCOCZ5JcPjF1/j4BE+ISWH/tW0DsVE=; b=DE8pIoaz7+EA0e7nTw/zSnvnd4WR/MR7SeDrnI+ivKaF9g86LeAGskG/5tg6AT9/Ci HqbrSJumAxa4SwAMlrfJSQkGHkdarQ1VvBI+Q30Td4D34ZFjdkHrPZNrCNyTN+pCITfC bnnKsyR9vHYChHjd5mw4HIIx/NpvgBb7YbmiMtAljf3DSctQQ/vCRDwJN804ED9oo5Qa HAYUS8r9K8C7KKfc2Gah0PVKDKaHnvJjcTagFJEPxbT8NYyXDFUV55R6Ac3Br8JfWsql SFJK4mGP572R5/WuuNAV+F0XdX142uBw3/VOKAnyD6wAdpZIyQJIlZy4Dn3/z0p3LgB/ YbrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=J5z+qfHt8u7hvuCOCZ5JcPjF1/j4BE+ISWH/tW0DsVE=; b=nxjgtEw0AKdcyBG6z1Iasee+Rxwj/Evt7zde4glvrtvGFOHql1oIJgTu71IvHoF7nu RyAWvQ5p2X+oIwY4XwUqmQ0Shwab7Ewtioi7/eoKP+isX6VyTQXG2YvYBbGL4JwxT34j TxmsAf8n+Rj/9JnpFhtW9r1i5+/43B1bWO0ntbzrsy7lAHtcueVQQrVXV/leFJvHzBbq 7O3+rH6OLIESDqlHHKvQdetLhwAQloLuYunQYD19PSoyHgizCdnJ7v4rmVf4d0xUgJk1 ky1a277GuVSBppeVIkDtkI3mpwew3N6aDvoz3inoQTlTSR6SQt8xT22UwV3ZCoesqYXd /L8Q==
X-Gm-Message-State: AIVw1133daFzYCfzrsygm7r2fygrjMVSXG+NZ1WhCY1odnP2628lUXB6 ZjMd0cYhFi5wIcf00ZKH8OD4KPXtjGgB
X-Received: by with SMTP id i8mr607487ybb.12.1500481209723; Wed, 19 Jul 2017 09:20:09 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 19 Jul 2017 09:20:08 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <>
Date: Wed, 19 Jul 2017 09:20:08 -0700
Message-ID: <>
To: Watson Ladd <>
Cc: Roland Dobbins <>, "" <>
Content-Type: multipart/alternative; boundary="001a1135162c7fa0970554ae0136"
Archived-At: <>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Jul 2017 16:20:12 -0000

On Wed, Jul 19, 2017 at 7:48 AM, Watson Ladd <> wrote:
> On Jul 17, 2017 12:29 PM, "Roland Dobbins" <> wrote:
> On 17 Jul 2017, at 21:11, Watson Ladd wrote:
> How do you detect unauthorized access separate from knowing what
>> authorization is?
> I think we're talking at cross purposes, here.  Can you clarify?
> You said you need to look at packets to see unauthorized access. How do
> you that access is unauthorized unless the authorization system is doing
> the monitoring?

Over the years I've met with businesses who have these kinds of set ups.
The way it usually works is that the analysis is secondary and based on a
suspicion of some kind. For example: if an employee is suspected of insider
trading, or stealing proprietary data, then the administrators may take the
extreme measure of inspecting all of their traffic. This is why many
corporate environments have those "No expectation of privacy" disclaimers.

Another example is where traffic to a set of suspicious destinations is
subject to a higher level of scrutiny. For example, maybe traffic bound for
well known file sharing services.

I've never seen an environment with pervasive always-on monitoring;
creating a trove of plaintext would be a net security negative, and
organizations rarely have the resources it would take to keep or analyze
all of it anyway.

Yes, but you'll rot13 or rot 128 the file first. Why wouldn't you?
> Many don't.  And being able to see rot(x) in the cryptostream has value.
> As the IRA pointed out to the Prime Minister, she needed to get lucky
> every time.

Where I come from, if you're quoting the IRA to support an argument, nobody
takes you seriously.

> The tools that network engineers and security personnel need analyze
> network traffic.  Logs are insufficient.

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.