Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Adam Caudill <> Mon, 23 October 2017 19:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 077CA139605 for <>; Mon, 23 Oct 2017 12:12:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sqOPWx-NOikd for <>; Mon, 23 Oct 2017 12:12:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2A0891395F3 for <>; Mon, 23 Oct 2017 12:12:10 -0700 (PDT)
Received: by with SMTP id g6so12520659pgn.6 for <>; Mon, 23 Oct 2017 12:12:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=WCHV85emOvogA/TCFWu+Ftyzuo03/6AdNwkaH1hpfew=; b=YgPx0rX5FK0n2e5TVIUJSZb0CWSsh8OvH8faM+mEY7HcsTOOifLBlcZUczQ8gVlgoZ tcpuRwdyk/b2lgMlWM9MIL89zAtRvGk8aE8iIBiXlfsVNw+ACd2wK+tYMNl+oxsG1qJ+ RVt/m0vvUhUXnAAQ0HdIxRzLHtV5SfSA93S3s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=WCHV85emOvogA/TCFWu+Ftyzuo03/6AdNwkaH1hpfew=; b=qMDnwXjwgHelwBQocDlEwl43eRsqjsHlf1fEvbMm/yQ+6tBqjDCPr2CosPum8f8p5v cN0tdZRLt8HLlVk78MtgUHi4WMxmnb0GIf8KdGZrbus7zVU5XilQYOEhyXwd7m3cbJRb hhjkfWP4EH4Tu+bmCQIdnEclL/Ad/W1w3wdmpu0gWjNAAI86xDxsYnI2cu6oRUTKZ5PI KIwt3FEwUo6+VNdE+4WFs1kR5lh1XL26R+VbsXOq0iOEofBXaSIIz5B/7LP2LqjWLYHW N5rocyibDpWz+qv3T1ZydkcRiTc7KUxIfb23457GUYhRHOybTSK5orI7vxY07lrA283K VYMg==
X-Gm-Message-State: AMCzsaUVkM7Iu0B2xg82D/plrqNn5QvNu8L2HV5i9z+gAKBW+8f8Txa6 9/wo3Te6HX0UN3tMW/36H0eDztWe9PeujUsJbI12ndug
X-Google-Smtp-Source: ABhQp+SXnRuXLG5OfT2Z1dG77s1ZlO8AhBk/YyGRvdcdMmdgeztwot9fDM9uGHL8rcmH6NGNGUWRVn7WMgX7HOO+dYw=
X-Received: by with SMTP id q14mr8835252pll.325.1508785929191; Mon, 23 Oct 2017 12:12:09 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <000501d348e5$1f273450$5d759cf0$> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Adam Caudill <>
Date: Mon, 23 Oct 2017 19:11:58 +0000
Message-ID: <>
To: "" <>
Content-Type: multipart/alternative; boundary="089e082ba4945a1752055c3b99e4"
Archived-At: <>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
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: Mon, 23 Oct 2017 19:12:12 -0000

To be honest, I’m rather surprised that this group continues to spend time
on this. I’m of the opinion that the chairs should step in and put this
discussion on hold until the work on TLS 1.3 is complete. This, and any
document of the same goal, are eating up time and energy that should be
directed to completing the work this group was chartered to do. There’s no
indication that there will be any consensus on moving forward with any such
document in this group, and I don’t think that will change any time soon.

Those advocating for some standardized method of subverting the security
properties of TLS have been offered numerous options in good faith, and
continue to reject them all. I’m aware of extremely large enterprises that
in fact require TLS 1.2 with PFS, as they made the investment in addressing
this issue early on, and do so effectively. This can be solved without
changes to the protocol or a standardized “backdoor” - and is being done
today by at least some enterprises.

I understand that this complicates the work that some do, and will mean
additional engineering or spending to deal with it, when they eventually
move to TLS 1.3; that said, I don’t think their decision to take the easy
route in traffic inspection and ignore the evolution of 1.3 till the last
moment should lead to adding new risk to every other TLS user, especially
those that invested in long term solutions that deal with these changes.

I’m of the opinion that this discussion is no longer productive; there’s no
indication that there will be consensus on this or similar documents, good
faith efforts have been made to offer alternatives - in multiple
discussions, it’s distracting from the work of completing 1.3. To me, the
most logical thing to do is move on, finish the work on 1.3, and then
reevaluate (not that I expect consensus to emerge then either).


--*Adam Caudill*