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

"Diego R. Lopez" <> Tue, 19 December 2017 00:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 75406126C22; Mon, 18 Dec 2017 16:18:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Kt1MvcnFXHPQ; Mon, 18 Dec 2017 16:18:54 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6E11A12422F; Mon, 18 Dec 2017 16:18:54 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.323.15; Tue, 19 Dec 2017 00:18:51 +0000
Received: from ([fe80::5e9:e441:e61f:7696]) by ([fe80::5e9:e441:e61f:7696%13]) with mapi id 15.20.0323.018; Tue, 19 Dec 2017 00:18:51 +0000
From: "Diego R. Lopez" <>
To: Stephen Farrell <>, Brian Witten <>, "" <>, "" <>
Thread-Topic: [Patient] [saag] Internet Draft posted as requested -
Thread-Index: AQHTd42wukyhoX4twUmW0ABJZQSMiaNIPdsAgAGhsYA=
Date: Tue, 19 Dec 2017 00:18:51 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM5PR0602MB3249; 6:fCWufTc9rsNvzqUFs2xI84kIXariHS+VnypwrnuVuzWv1JTKMOWX0+PP5cwTl0OnStBKONOQHgpg5sQnAu0MNPc2AjasQ29y/WG6l8+ZV2LFy2SJwHPfDaQHY64CzgxgD349ncmnGXUccEE4qHIEgULl1N44A2VhSFHd97/qx3UuX6LP4ZreF0gLnyvdy+HiGKzsZq/6UOqIVM1pXcEkYQjXuHsSMfU3dl/lbMzEx1hIuXzbgiZGRSB4sU8eKHsys6jYhnfbggDx0Ut7X3QDcX7dyV58P0ZiDNZKULyN0QqBvWPSmu9r0Y32AcgMEVeun/dCwhjafWktdRLpTJS5oje5oXj5AJOe/OCvPsUtqGc=; 5:wGfn58HIVU+ry+8nSVoqkAgRo9b+bL20eYbR9T7MbyQ0zixL6aOCCpYrPpNmlwvLJyFMxpJ8UpxmFQtd95TOz0fVtCftmAXrOi3dXtoyC2jjgtHGlDcBlgQcpj0DPu7EyZVGusIlh9k7P+n1RL6xYnhdKGIeThIjdivA0NYtNPk=; 24:HixjhGwRKT2jQJTc+cqe64EPkaL0DwAJ6SkVMYAxlv6DjnSiWk7XPHyJt6alfFjPM6o8RaBwTIf0GEdzmt2Z5Hvn6VSYbeOLahPqfRGjOdg=; 7:6BqphXct4fX+88bnuQxuL/Cg99p+h+8umDIq4+aw1gL/vuN9GFEqXivGJL2akN6vSUkLVhxYCIMUbGjKgjPyRcckXAFL+EDRsjkO8joQZMaqXfHLC9rTCakr7C0XmVPVXUaBzpYsi8HT/56LzRDRVQuFJuvlyea97qHnL5O6aK0im3XSS1T0xj6se7jt2k9YgPLBecijVdQskdG1I6mgtl3pYmtHGJ/rbO2GRF6koLAzM6eLyMa1oMTN6uohDXrg
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: aa744c2e-d83a-4500-54c7-08d546761537
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603307); SRVR:AM5PR0602MB3249;
x-ms-traffictypediagnostic: AM5PR0602MB3249:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(32856632585715)(40392960112811)(192374486261705)(128460861657000)(81160342030619);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3231023)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123564025)(20161123558100)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011); SRVR:AM5PR0602MB3249; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM5PR0602MB3249;
x-forefront-prvs: 052670E5A4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(346002)(396003)(376002)(252514010)(24454002)(199004)(189003)(25724002)(40134004)(229853002)(2900100001)(966005)(82746002)(6486002)(93886005)(2906002)(99286004)(83716003)(316002)(6436002)(76176011)(2201001)(478600001)(83506002)(25786009)(8936002)(86362001)(58126008)(2950100002)(110136005)(6512007)(97736004)(3280700002)(5660300001)(8676002)(36756003)(6306002)(106356001)(7736002)(105586002)(14454004)(68736007)(81156014)(81166006)(53546011)(305945005)(66066001)(786003)(6246003)(45080400002)(5250100002)(6506007)(3660700001)(59450400001)(102836003)(3846002)(53936002)(6116002)(33656002)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0602MB3249;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: aa744c2e-d83a-4500-54c7-08d546761537
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2017 00:18:51.7888 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0602MB3249
Archived-At: <>
Subject: Re: [Patient] [saag] Internet Draft posted as requested -
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Protecting against Attacks Tunneling In Encrypted Network Tunnels <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Dec 2017 00:18:58 -0000

Hi Stephen,

I agree we should not bore the list (and ourselves) repeating the disagreements we have. Those are the kind of discussions for the third or fourth beers...

Just let me remark a couple of things I have seen when reviewing today's messages that I think are worth noting:

1) You do not need to break TLS or HTTPS, as there are potential alternatives that could be applicable, depending on the case. For IoT environments I foresee multiparty security could be a reasonable choice. For personal environments, I think Paul's idea of decrypt-and-bless could be something interesting to explore. And replying to Melinda, those proposals do not imply sharing session keys (though there is a draft on enterprise datacenters arguing for a related approach that I think has a solid case behind...) In summary: there are options on the table that deserve some attention, and do not imply breaking TLS

2) What I had in mind when replying to you was not arbitrary routers, or WiFi Aps, or any other network box being authorized to inspect encrypted traffic. I foresee a single (or very few) edge devices that are properly authenticated, authorized (in a PoC we have we even attest their software...) using the same kind of TTPs you mention.

Be goode,

"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D

Tel:         +34 913 129 041
Mobile:  +34 682 051 091
On 18/12/2017, 01:23, "Stephen Farrell" <> wrote:


    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.



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição