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

Hubert Kario <hkario@redhat.com> Thu, 12 October 2017 12:57 UTC

Return-Path: <hkario@redhat.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 B0F5C1344BF for <tls@ietfa.amsl.com>; Thu, 12 Oct 2017 05:57:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level:
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 X9R1H2_TsRyn for <tls@ietfa.amsl.com>; Thu, 12 Oct 2017 05:57:40 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 397AC13305F for <tls@ietf.org>; Thu, 12 Oct 2017 05:57:40 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D3FC8C04AC46; Thu, 12 Oct 2017 12:57:38 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D3FC8C04AC46
Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com
Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 50BAC62940; Thu, 12 Oct 2017 12:57:38 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Thu, 12 Oct 2017 14:57:28 +0200
Message-ID: <2078865.Sr80Q4DYO4@pintsize.usersys.redhat.com>
In-Reply-To: <1507760676870.14256@s21sec.com>
References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <CAOjisRywXfBfgWuZQPR++sHcK7M7vaKFMDea3XMA4tAUEs7HdQ@mail.gmail.com> <1507760676870.14256@s21sec.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3026514.Y3xAIzhxBm"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Thu, 12 Oct 2017 12:57:40 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/37EuppCvbus9XFsEf-zlxno4XX0>
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: Thu, 12 Oct 2017 12:57:42 -0000

On Thursday, 12 October 2017 00:24:36 CEST Ion Larranaga Azcue wrote:
> 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...

yes, a three-way DH with two certificates (one IPS one EE server) does seem 
like a much better approach, especially if IPS certs need to have special 
flags that make them useless for anything else and cannot be set by CAs in 
public CA programs.

>    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


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic