Re: [Patient] [saag] Internet Draft posted as requested -

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 18 December 2017 00:23 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: patient@ietfa.amsl.com
Delivered-To: patient@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59B312711D; Sun, 17 Dec 2017 16:23:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMNhRLoyhEnY; Sun, 17 Dec 2017 16:23:56 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 710921200C5; Sun, 17 Dec 2017 16:23:56 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A6605BE2E; Mon, 18 Dec 2017 00:23:54 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGGAGQSPcvNE; Mon, 18 Dec 2017 00:23:53 +0000 (GMT)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 50C71BE24; Mon, 18 Dec 2017 00:23:53 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1513556633; bh=m5QGpiFSvg+U31NLNkBVEOm6VwOi+54A4Oy0CT2mXOY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=QDx1J/goMwTQ7i2bDyGnNpJ9/+eoz6fR06B9giRHDlmvPpgRHmc1BOvS9nLLCq4tj aLFnxnPWhOCUmETZbp82J1NRnHCPezYXhRXG/LwRhUts9ltUZ3nZ7p52rfFcDElhof mu2T41dSLsBS6wJLGSKl+VGtt0xg1fripld32oFE=
To: "Diego R. Lopez" <diego.r.lopez@telefonica.com>, Brian Witten <brian_witten@symantec.com>, "patient@ietf.org" <patient@ietf.org>, "saag@ietf.org" <saag@ietf.org>
References: <MWHPR16MB14881688FE400E3277CA8A9393310@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB14889BEE3EB0ED5F328D7C3993370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB14889B7535153E5844649CA393370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB14880A12D15AC58FDD5CEC8793370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB1488D43F3B53BC7BBE9D836593370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB1488853B0E4F7BB8E557288D93370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB148845FB069D03625BC399B193370@MWHPR16MB1488.namprd16.prod.outlook.com> <MWHPR16MB1488848D7AC828EBB8DA90B093350@MWHPR16MB1488.namprd16.prod.outlook.com> <DM5PR16MB148477E1FAA4C210A3B013F7930A0@DM5PR16MB1484.namprd16.prod.outlook.com> <dfdb52ca-81ae-50b7-cd5f-e256b5cb047d@cs.tcd.ie> <AF4C62E0-61AB-45DB-B3E6-56AB67A1070A@telefonica.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <d47e82af-5c6f-9be5-4226-4d6713701148@cs.tcd.ie>
Date: Mon, 18 Dec 2017 00:23:52 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <AF4C62E0-61AB-45DB-B3E6-56AB67A1070A@telefonica.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MT3HJ19vsNt2fkLfMpGfDifS9petDHdxL"
Archived-At: <https://mailarchive.ietf.org/arch/msg/patient/ZH5_Pt87X-yXkrVsSRM0_8zNqJs>
Subject: Re: [Patient] [saag] Internet Draft posted as requested -
X-BeenThere: patient@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Protecting against Attacks Tunneling In Encrypted Network Tunnels <patient.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/patient>, <mailto:patient-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/patient/>
List-Post: <mailto:patient@ietf.org>
List-Help: <mailto:patient-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/patient>, <mailto:patient-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Dec 2017 00:23:58 -0000

Diego,

I generally disagree with some of your earlier points where
you disagree with me:-) I do agree that there are hard
problems with updates and bugs in general for endpoints and
devices in the middle. I don't agree that breaking TLS or
HTTPs is a viable way to improve that, It'd make it worse.
But rather than repeat things I've said to you in person
before, for this threat, maybe it is work saying that the
proponent here claimed to be interested in a new multiparty
security protocol (in the mailing list description) which
could have been a worthy, if unlikely to succeed endeavour.
In Singapore, I concluded that they are primarily or maybe
only interested in the web as used by people and in mitm'ing
that. So personally I think the separate mailing list would
be better closed down as it seems to have been started on
the basis of some confusion wrt folks' goals.

On 17/12/17 23:19, Diego R. Lopez wrote:
> 
> I am afraid I don’t follow you here… What do you mean by “random
> name/address that claims to be “good””? Given there are appropriate
> roots of trust, how is this “random” trust different from the
> certificate verification process in TLS?
The difference in the above context is the the proponents
here want TTPs that tell lies all the time, and that are
so wide-spread and not well-known that they appear to the
endpoints indistinguishable from a random router. The public
Web PKI TTPs we have are far from perfect but at least they
don't do that so far.

There also appears to be some magical thinking that allows
some proponents to say that they think these new lies can
benefit the user and give the user more control. I have no
clue how that can reflect a genuine technical opinion.

S.