IETF Logo Mail Archive

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

Ion Larranaga Azcue <ilarra@s21sec.com> Wed, 11 October 2017 22:24 UTC

Return-Path: <ilarra@s21sec.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0D8132D17 for <tls@ietfa.amsl.com>; Wed, 11 Oct 2017 15:24:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level:
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 gS0vIAE49dbM for <tls@ietfa.amsl.com>; Wed, 11 Oct 2017 15:24:42 -0700 (PDT)
Received: from mail.ssi.pt (mail1.ssi.pt [195.23.55.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807EF1326DF for <tls@ietf.org>; Wed, 11 Oct 2017 15:24:40 -0700 (PDT)
From: Ion Larranaga Azcue <ilarra@s21sec.com>
To: Nick Sullivan <nicholas.sullivan@gmail.com>, Ralph Droms <rdroms.ietf@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
Thread-Index: AQHTO72INxjGwk0f70e0hZ2DWWm8J6Lb99iAgAM9PuA=
Date: Wed, 11 Oct 2017 22:24:36 +0000
Message-ID: <1507760676870.14256@s21sec.com>
References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com>, <CAOjisRywXfBfgWuZQPR++sHcK7M7vaKFMDea3XMA4tAUEs7HdQ@mail.gmail.com>
In-Reply-To: <CAOjisRywXfBfgWuZQPR++sHcK7M7vaKFMDea3XMA4tAUEs7HdQ@mail.gmail.com>
Accept-Language: es-ES, pt-PT, en-US
Content-Language: es-ES
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.228.250.15]
x-exclaimer-md-config: 006f0bbf-7968-42ed-bdf3-292cea52a85c
Content-Type: multipart/alternative; boundary="_000_150776067687014256s21seccom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/XfEZuVJVdlD-zQtfgYsft9mXgSU>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Oct 2017 22:24:45 -0000

I'm a newcomer here, so I may be wrong in some aspects (I apologize in advance for that) but at least I'd like to give my opinion...


I really don't feel confortable with the approach taken in this draft. Most of the proponents of these kind of "tapping" limit their scope to datacenters, but I agree with others in that it should be treated as if it will be used on the internet as a whole (as the specification does not prevent this kind of use, and we can't know how users and hosting companies will react to this functionality being available).


It's true that with this approach the client has to opt-in but once it has opted-in, the client has no control over which third party the encryption keys are passed to. Imagine a client opts-in because he knows there is an IPS within the network and the company hosting the server asks him to (I know at least one of our clients would certainly consider this). But some time later a malicious third party manages to coerce the hosting company to provide the keys to them instead (or in addition to) the IPS. From the point of view of the client, he wouldn't notice anything different (only a change in the key identifier but could be due to key renewal)...


I think a way to solve this would be involving the client more in the visibility negotiation. For me, the client not only has to opt-in to the tapping, but should also have the possibility to unambiguosly identify the tapping third-party and accept or reject the connection accordingly. I had some naive idea for this but I was unable to accomodate it in the handshake as it is currently defined (in fact, I don't think this kind of control for the client can be provided without major changes to the handhsake protocol).


I also don't like the way security so greatly depends on SSWrapDH1 (as addressed in point 6 of Security Considerations). I expect many administrators will create long-lived keys in order to avoid the work to have to redistribute them, leaving connections open to attack during months after they take place (until SSWrapDH1 key renewal)...


Anyway, I think key life length could be addressed in later drafts, but the inability of the client to identify (and possibly reject) the tapping third party is a "no go" for me...


   Ion


________________________________
De: TLS <tls-bounces@ietf.org> en nombre de Nick Sullivan <nicholas.sullivan@gmail.com>
Enviado: lunes, 9 de octubre de 2017 22:49
Para: Ralph Droms; tls@ietf.org
Asunto: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Ralph and Russ,

This draft addresses the two main concerns I had with draft-green:
1) Client opt-in
2) On-the wire visibility

There are clearly some details missing from this draft (such as how Ke is used as a symmetric key), but generally I think this approach is more explicit and therefore less likely to unintentionally impact the broader internet if used in the datacenter setting.

Nick

On Mon, Oct 2, 2017 at 1:31 PM Ralph Droms <rdroms.ietf@gmail.com<mailto:rdroms.ietf@gmail.com>> wrote:
We are about to publish draft-rhrd-tls-tls13-visibility-00.  The TLS extension defined in this I-D takes into account what we heard from the discussion regarding TLS visibility and draft-green-tls-static-dh-in-tls13-00 in Prague. Specifically, it provides an opt-in capability for both the TLS client and server and makes it clear on the wire that visibility will be enabled for the session.  The new mechanism does not depend on static handshake or session keys.

- Ralph and Russ


_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email