Re: [TLS] Industry Concerns about TLS 1.3

Pascal Urien <> Mon, 26 September 2016 08:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 81BB212B09D for <>; Mon, 26 Sep 2016 01:28:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y9txqp0AFIb8 for <>; Mon, 26 Sep 2016 01:28:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 604FF12B00A for <>; Mon, 26 Sep 2016 01:28:31 -0700 (PDT)
Received: by with SMTP id t83so199191779oie.3 for <>; Mon, 26 Sep 2016 01:28:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id e4mr13426901oih.28.1474878510771; Mon, 26 Sep 2016 01:28:30 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 26 Sep 2016 01:28:29 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: Pascal Urien <>
Date: Mon, 26 Sep 2016 10:28:29 +0200
Message-ID: <>
To: "Ackermann, Michael" <>
Content-Type: multipart/alternative; boundary="001a1141b674b8b4a3053d64e94b"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Industry Concerns about TLS 1.3
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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



2016-09-25 23:20 GMT+02:00 Ackermann, Michael <>:

> 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 []
> Sent: Saturday, September 24, 2016 10:10 PM
> To: Ackermann, Michael <>; Pawel Jakub Dawidek <
> 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