Re: [TLS] Deployment ... Re: This working group has failed

Peter Gutmann <> Tue, 26 November 2013 23:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 47E6F1AE03B for <>; Tue, 26 Nov 2013 15:28:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mLG_TdQtgfgc for <>; Tue, 26 Nov 2013 15:28:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id EB36E1AE036 for <>; Tue, 26 Nov 2013 15:28:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=uoa; t=1385508508; x=1417044508; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=TLSSllojOcH5V++zqvMeFVrMcPVWGKUhQHWhP2obmn4=; b=h39IZoBmRkEW7DIu3nTvDaP/g04OXbVf73J7ZAv6Q80Nnds5kuDSCj5X OzW8J+XExzuuCUdfo1aQDzllerL+jHVyo4nKwKYYjcdy6J/Q+XQnIkUaj G+pSguZfVPtJoTBNUVEPjFZ77Mi2d2Tt4XFL6X/ZYZEPT/BIobLwj5GI8 8=;
X-IronPort-AV: E=Sophos;i="4.93,778,1378814400"; d="scan'208";a="224228492"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 27 Nov 2013 12:28:18 +1300
Received: from ([]) by ([]) with mapi id 14.03.0158.001; Wed, 27 Nov 2013 12:28:18 +1300
From: Peter Gutmann <>
To: Andy Lutomirski <>, "" <>
Thread-Topic: [TLS] Deployment ... Re: This working group has failed
Thread-Index: Ac7q/y/ihw40evCST4Suv+3m/1v4Fg==
Date: Tue, 26 Nov 2013 23:28:18 +0000
Message-ID: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] Deployment ... Re: This working group has failed
X-Mailman-Version: 2.1.15
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, 26 Nov 2013 23:28:29 -0000

Andy Lutomirski <> writes:

>- When in client mode, implementations MUST refuse to connect to a server
>unless an explicitly chosen set of trust roots (or other mechanism such as
>DANE) authenticates that server (hello, everything).

Translated: "TLS implementations MUST refuse to connect to any computer or
device that isn't a public web server with a commercial CA-issued
certificate".  You may as well mandate that "TLS implementations MUST NOT
allow the tide to come in".

(There's a reason why some of the things are the way they are, and you're
unlikely to be able to change them unless you control both sides of the
infrastructure.  Sometimes you can't even do that, witness Google's ongoing
problems with trying to get Chrome into a secure-by-default mode with Google's
own servers).