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

Dave Garrett <> Mon, 23 October 2017 17:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 883D21393A8 for <>; Mon, 23 Oct 2017 10:17:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 Ju_8dZuROuDd for <>; Mon, 23 Oct 2017 10:17:20 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A16D6138DE1 for <>; Mon, 23 Oct 2017 10:17:20 -0700 (PDT)
Received: by with SMTP id k123so22908275qke.3 for <>; Mon, 23 Oct 2017 10:17:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:references:cc:to:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=fEcmPuu5Xdb6hJcyqOAcwwtVceHIBJfXlBK60orrh38=; b=V4Bmbxdy4iyHACPTIOtXqlMHXsnHKGPo5MSm8nOva5BEXtQY0QQ7bYf5ridHRiHcAX mtY08xoli+cfwMpouVB3RD715FMzi+ExkfIhX86NE40/SU9ULtDC6ylPwBfV9zlEBoUL ofdOG89wwCJQz9+HJof1aR2/Vwb8GaQKtRnjrt6pYi2TSPWM0xF3xrgHUDQIAokFiK3F 4vphxIUUkVq1nrjpGkUfYwXW/BxcuqqgJyPnjqX1B3R6fm+mjkr8J8PzXxe9bUKO35Md K9BRE6A2y14+++dNOcdRLxOYfnmNgnUO71U6e5jh8z2dMqsOWGizT1lYkAlSzVROY7Uy HJnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:references:cc:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=fEcmPuu5Xdb6hJcyqOAcwwtVceHIBJfXlBK60orrh38=; b=bvS06zoVDpQiILA3Y7I8B2TiUPAjTxngItpe+de8sZtDC4IXUFAWyGV6PKaWT2cUR8 p2SVyJPosqqQF3PAyNiwxB9ln8/Mv9NZdrylHhaFWpwBP3DyKV/Yo28yG883lh0/ETKT kPibp3eEfla7ZZMNTu7W/ePRm6qUIm7AYR6J8K94SCAPi/OzRITXfXq16m5MSgIkMjjQ vqiv6qarEaBdPO6FmHDSvDRj2HT7TBsT0JzktyRR3FoWn2LFQcHdRHRokW0wdrxhGOk3 QwW/8RIbHf/65c2piiXdJvknJ2M6M+UjW5aZGtwz/r6LsqeWW3z2v0nPENV8oDezFCR0 yPJw==
X-Gm-Message-State: AMCzsaXRhcSTX0JCQKUKinEs1ek9DcFyUnlWPLh/dM8GJIHODuVDEh5j MM3QxVltOxRWaZ6t9iYDd7E=
X-Google-Smtp-Source: ABhQp+TA2AvL+HGWoZJ7xcjI3/OBLkU9bmgx22ownSj6QYdzyTN1QV834QXnjaFFBAnx452RwYG52Q==
X-Received: by with SMTP id e29mr19630904qkh.253.1508779039725; Mon, 23 Oct 2017 10:17:19 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id i13sm4891711qke.39.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Oct 2017 10:17:19 -0700 (PDT)
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: "Ackermann, Michael" <>, "" <>
From: Dave Garrett <>
Message-ID: <>
Date: Mon, 23 Oct 2017 13:17:18 -0400
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
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 17:17:24 -0000

On 10/23/2017 12:39 PM, Ackermann, Michael wrote:
>  2. Modifying Server,  application and logging infrastructure is a huge,
>     expensive proposition,  that executive management would not be
>     receptive to at all.   Not to mention the logistics to follow if
>     they were.

I'd just like to have everyone stop and focus on this, right here. This 
is the crux of everything. It takes effort and resources to upgrade your 
systems, and you don't want to do it. Tough; this is not the TLS WG's 
problem. The job here is to design the most secure protocol possible, 
and weakening things significantly to accommodate legacy methods is not 
a realistic option. Organizations will *always* have to expend effort 
and resources to upgrade to better systems. If that can be reduced 
without affecting security, great, but if not, then you're just going to 
have to accept it. People should not be here arguing against technical 
improvements; they should be with their managers explaining the simple 
reality of the situation. Yeah, I know it's hard to explain to executive 
management that they are not in control here, but they aren't.

I count at least 400+ messages on this list on this one topic. The 
answer is still "no". You're not getting a cheap drop-in replacement for 
your existing insecure use of static RSA keys out of this WG. Fixing 
devil's advocate qualms like whether or not clients have to send an 
extension is not enough to get even a rough consensus. Nontrivial, but 
very much viable, effort and resources will be required to upgrade.