Re: [TLS] Industry Concerns about TLS 1.3

Pascal Urien <pascal.urien@gmail.com> Mon, 26 September 2016 08:28 UTC

Return-Path: <pascal.urien@gmail.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 81BB212B09D for <tls@ietfa.amsl.com>; Mon, 26 Sep 2016 01:28:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 y9txqp0AFIb8 for <tls@ietfa.amsl.com>; Mon, 26 Sep 2016 01:28:31 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 604FF12B00A for <tls@ietf.org>; Mon, 26 Sep 2016 01:28:31 -0700 (PDT)
Received: by mail-oi0-x230.google.com with SMTP id t83so199191779oie.3 for <tls@ietf.org>; Mon, 26 Sep 2016 01:28:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2eZAV1OL2Xn2B/PptR3WYC4Wd/AYHPnqM0HN/icDPRM=; b=hrXNxI19lBVmaJ70fOJ/DiIYiNM8FGwTyde/zyWhPL3V0l0/gkqtBpH1QT/3AbvUqq 4hfc5gANvUTyTpRUALfwUXa18yogh+oiWKy+Hyh/MemCAKUkKBH8TmUMXNOtrwDIfuD4 BqYBLkP4qKQHiS8fT94c65vq5/Se6Cao1YTpKxJPnkD3WTElRTEGpX4g7U05lPmhyr5l 7MlLsi+tFq7GLKxllhTAEZsMImexpA2mDEm+BX3CyNDjZSbk2o5zAD1l6PuYS9tsZuMv TWqc/ODJtURAWw8WNrbf/kvBidSNHI2k5PYYJlZwLURSKTKfyiur0MFUz/s1bpYvDK5W iRig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2eZAV1OL2Xn2B/PptR3WYC4Wd/AYHPnqM0HN/icDPRM=; b=jsaDrNW6ounr8dd3CfzP+jzukunWAC7W4lH7jcn0gOW6N0GwaqADf1WlMF/sIt9U/C G7vo3O1MuCD7BvrPnQi9eIgMgPIDuydS5dtL4Zku5zx3rSXIwMrym819X09XdF3HfSst EcLFRA/R+TUOhUshNl3RKlSAOJZp7U62ON86l1ZpwqlEVZtMQjXCm5Gs1LK3iNrUC9Pn uQ4cxXHU1skfwMK8p+LJ+wyTe6BBFAH2i2mhHvkSddFJ0bjT3P5ww30Q275PBJpaEeQb WTCNIlu5vQgnB4y6Z5mu1lCU0mup6P2uCTjjqqflLNKs6JHqSOQ4OjxS0G1hKPRic6op Ui5Q==
X-Gm-Message-State: AA6/9Rm/JRxlKPRspuNVUrFBG9i12P+fTMWoPn8e+f/VtEekpGtNFoKgHQXYcpg/9UKbZGacn/xHzSj+BN65nA==
X-Received: by 10.202.231.4 with SMTP id e4mr13426901oih.28.1474878510771; Mon, 26 Sep 2016 01:28:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.181.131 with HTTP; Mon, 26 Sep 2016 01:28:29 -0700 (PDT)
In-Reply-To: <4FC37E442D05A748896589E468752CAA0DBCBA55@PWN401EA120.ent.corp.bcbsm.com>
References: <DM5PR11MB1419B782D2BEF0E0A35E420DF4C90@DM5PR11MB1419.namprd11.prod.outlook.com> <CO1PR07MB283F2C414B6478E993675DEC3C90@CO1PR07MB283.namprd07.prod.outlook.com> <394611bf-208f-03d3-620c-79aaf169645b@cs.tcd.ie> <4FC37E442D05A748896589E468752CAA0DBC66AE@PWN401EA120.ent.corp.bcbsm.com> <CAH8yC8kgYzYXwJ01NkK7WYxD-diponWEQOd+MNHssm+bLHE54w@mail.gmail.com> <4FC37E442D05A748896589E468752CAA0DBC699B@PWN401EA120.ent.corp.bcbsm.com> <CACsn0c=5vjzQmr=ah6sH1JzTj3peaKad7aCPertcqD4B2DLKiA@mail.gmail.com> <4FC37E442D05A748896589E468752CAA0DBC6CAC@PWN401EA120.ent.corp.bcbsm.com> <fd4ad423-3614-5330-b687-1b5848e839f0@wheelsystems.com> <4FC37E442D05A748896589E468752CAA0DBC9732@PWN401EA120.ent.corp.bcbsm.com> <b24efbbb594040e794f7513b7e62b3c7@usma1ex-dag1mb1.msg.corp.akamai.com> <4FC37E442D05A748896589E468752CAA0DBCBA55@PWN401EA120.ent.corp.bcbsm.com>
From: Pascal Urien <pascal.urien@gmail.com>
Date: Mon, 26 Sep 2016 10:28:29 +0200
Message-ID: <CAEQGKXRgDU8rv4qFd=5_xzfUX92m9dn-Y+4=0VsP7N4U26pJvg@mail.gmail.com>
To: "Ackermann, Michael" <MAckermann@bcbsm.com>
Content-Type: multipart/alternative; boundary="001a1141b674b8b4a3053d64e94b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ymdmTvWG2d5Zr8doYEwrpsDdTyI>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Industry Concerns about TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 26 Sep 2016 08:28:34 -0000

Hi All

There is a smart way to recover DH secret by a third party

It is DH tripartite base on EC paring

https://tools.ietf.org/html/draft-urien-tls-dh-tripartite-00

Rgs

Pascal



2016-09-25 23:20 GMT+02:00 Ackermann, Michael <MAckermann@bcbsm.com>:

> I understand your concern over what the nation-state actors are doing but
> it is not the same as what Enterprises do to manage their private servers,
> networks and clients.
>
> Your final paragraph is quite a constructive question.   "What
> specifically would you have us do? What do you want in the protocol that
> enables your needs, but doesn't make it possible for everyone in the world
> to be surveilled?  Please, make some specific suggestions."
>
> My personal perspective would be, that the approach to achieving an answer
> to that important question, would start with:
>
> 1.  Gathering  protocol neutral requirements from all involved factions,
> (with help and suggestions from people on the TLS list)
>
> 2.   Brainstorming session(s) with people on the TLS list as well
> potential users/operators, with objectives that include the design of a
> solution that meets (hopefully) all known requirements.
>
> What I would like to see come out of the debate we seem to be currently
> involved in,  is the realization that significant operational/management
> issues exist with TLS 1.3 and that the IETF is taking them seriously enough
> to at least begin dialogue intended to address these issues, and
> potentially work together to craft related solution(s).   In my view this
> issue is far too complex &  pervasive to believe that any one person or
> group's perspective would produce a viable overall solution.
>
> Again, let me restate,  I don't think anyone is saying that we MUST have
> RSA.    But, we, as the clients of the IETF TLS protocol, would like to
> work with you to assure we have workable, manageable  and affordable
> solutions,  that meets our needs as well as the needs of others.
>
> -----Original Message-----
> From: Salz, Rich [mailto:rsalz@akamai.com]
> Sent: Saturday, September 24, 2016 10:10 PM
> To: Ackermann, Michael <MAckermann@bcbsm.com>; Pawel Jakub Dawidek <
> p.dawidek@wheelsystems.com>; tls@ietf.org
> Subject: RE: [TLS] Industry Concerns about TLS 1.3
>
> >   This lack of scope, depth and detail [in MITM infrastructures] are
> > what drove us to install the packet collection infrastructures
> > (debugging networks I think some are saying).
>
> At the risk of repeating myself and flogging this dead horse...  What you
> are doing is exactly what the nation-state actors are doing.  I bet that
> some even use that exact phrase of "packet collection infrastructure."
>
> I understand that if you want to use TLS 1.3, it is going to be expensive
> and/or inconvenient; you're going to have to educate regulators and get
> bespoke TLS endpoint solutions from vendors. Perhaps you can get the NSA's
> to stop collecting everyone's Internet traffic for future decoding?
>
> Less flippantly, what specifically would you have us do? What do you want
> in the protocol that enables your needs, but doesn't make it possible for
> everyone in the world to be surveilled?  Please, make some specific
> suggestions.
>
>
>
>
> The information contained in this communication is highly confidential and
> is intended solely for the use of the individual(s) to whom this
> communication is directed. If you are not the intended recipient, you are
> hereby notified that any viewing, copying, disclosure or distribution of
> this information is prohibited. Please notify the sender, by electronic
> mail or telephone, of any unintended receipt and delete the original
> message without making any copies.
>
>  Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are
> nonprofit corporations and independent licensees of the Blue Cross and Blue
> Shield Association.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>