Re: [TLS] chairs - please shutdown wiretapping discussion...

Ted Lemon <> Tue, 11 July 2017 21:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1113612F287 for <>; Tue, 11 Jul 2017 14:16:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 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, SPF_PASS=-0.001, 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 eR3xCQYnDp9l for <>; Tue, 11 Jul 2017 14:16:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0350812ECB5 for <>; Tue, 11 Jul 2017 14:16:33 -0700 (PDT)
Received: by with SMTP id r30so4139019qtc.0 for <>; Tue, 11 Jul 2017 14:16:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=s2inkSzTRfCyKxFsUOig+2MffrVeq7eMxRaKxhbf+BU=; b=wNil1rwyLeQwz0rbVN8NW0Re3V5EKupfYVnausLRyivCfTyYfe3rNu6MlpHDOU6hPa otKnSgyMQcb7fc31AcnAU1oPmonhcP0MGgBSglcy2BwGHLZ5cCgoSfCQLYUQJrz93zIz IVuq9nBi5S+s82/ejYLV1c0rsjSD4CDLFHdpMUEWoc3b9xZ3eg0AJyQewoNgSFGTlJzf UWiJYWp+6+mOL9Ys92q4wUf1RWJizhQFqDUg+80ewrz9xHXAiYTZNOb/QIBozuGOd1ah CPbxoLjZNJMzNu6HRPLjCnJKxRWP/ZWCsT5/wo1qKa2KVKdXThjMKxVeEDlbA9VYdNQP J7xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=s2inkSzTRfCyKxFsUOig+2MffrVeq7eMxRaKxhbf+BU=; b=XzKdN/TJz2UeSrnCqefzaHWfFJ3E3/0+gnd4rxFtFQglt/nF7FOJLQhtDG9hXZkAFK xSyumWI6Dpwx/8/vhkwZBVq+Q8bTPDm+X2Y6iSNOBf+be6TS5BOISL2DnmWlEe7b3fM8 dzrPfNNOwI/Rmt3bzpOUX8eDAcl8hX2W3MZ9ISfWiugd+mugmzlDO5z0Y9VGKK6HaHzk F24UkM8ioDteNC+P55v4Q0SMNXA5EEYNphr4Tl/h1a7wmggERAa4ULYfqo3jhiR4jttk rP1u3HtMF3t7h2GrhORRcG96fP4YIhWCI3aunzBG2+y/QCW6TA3Dd1hmXKY05J5DwnJb J1LA==
X-Gm-Message-State: AIVw113AdsG9HEztKgdwGp7Go+gvsc/POmQnWZ+Mv/fL2gvPdkuBuUXf POOVh3+YPYQLu70Tyv9kNQ==
X-Received: by with SMTP id q4mr2494617qti.221.1499807793028; Tue, 11 Jul 2017 14:16:33 -0700 (PDT)
Received: from macbook-pro-6.ether.lede.home ( []) by with ESMTPSA id h17sm358327qte.20.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 14:16:32 -0700 (PDT)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8AA6497C-735E-4176-8A62-70698828EEE7"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 11 Jul 2017 17:16:31 -0400
In-Reply-To: <>
Cc: Christian Huitema <>,
To: Stephen Farrell <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...
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: Tue, 11 Jul 2017 21:16:36 -0000

On Jul 11, 2017, at 4:58 PM, Ted Lemon <>; wrote:
> On Jul 11, 2017, at 4:31 PM, Stephen Farrell < <>> wrote:
>> I'd bet folks would invent proprietary
>> ways of avoiding detection, that deviate from the "standard"
>> and that perhaps make crypto worse all around. Say by deriving
>> secrets from some function f(exfiltrated-secret, time, count)
>> for a small counter or some such and having the decryptor of
>> the wiretapped packets hunt a bit for the right key.
> Hm, well, but that would be catnip for security researchers, particularly if it weakened the key.   But yeah, you're right, that does make detecting the attack possibly impractical aside from as a large research project.

On second thought, this suffers from the same problem as the many-static-keys problem: there are too many moving parts.   This requires all clocks on all servers and interceptors to be in perfect sync, not just close, or else potentially halves the performance during clock skew  overlap periods.   It requires every server and interceptor to implement the same algorithm.   And you still have to distribute the information from which the key is derived.

So again, yes, you can do this particular mitigation strategy.   But it's expensive, and so nobody's going to do it if they have a better choice.   It's cheaper to just re-tool to support TLS 1.3.   As long as the solution isn't standard, it's only going to appeal to a _very_ limited audience, if there's any audience for it at all.   E.g., consider trying to deploy something like this on a country-wide scale.   You're just going to exfiltrate every key instead—it's cheaper.