Re: [Cfrg] Security proofs v DH backdoors

Ilari Liusvaara <> Sun, 30 October 2016 11:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D95D512944B for <>; Sun, 30 Oct 2016 04:49:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id alj5ZRFY77EI for <>; Sun, 30 Oct 2016 04:49:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0791B129484 for <>; Sun, 30 Oct 2016 04:49:40 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D0B612D85; Sun, 30 Oct 2016 13:49:39 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id veXH8kU3rH7T; Sun, 30 Oct 2016 13:49:39 +0200 (EET)
Received: from LK-Perkele-V2 ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 31A1A28B; Sun, 30 Oct 2016 13:49:39 +0200 (EET)
Date: Sun, 30 Oct 2016 13:49:37 +0200
From: Ilari Liusvaara <>
To: Peter Gutmann <>
Message-ID: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Cc: CFRG <>
Subject: Re: [Cfrg] Security proofs v DH backdoors
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 30 Oct 2016 11:49:43 -0000

On Sun, Oct 30, 2016 at 11:04:48AM +0000, Peter Gutmann wrote:
> Ilari Liusvaara <> writes:
> >Unfortunately, LTS is a non-starter as web browsers are concerned. 
> Sure, and if you read the -LTS draft you'll see it's not targeted at web
> browsers.  I know that this is probably hard for some people to understand,
> but there's a lot (an awful lot) of TLS used outside of web browsers.
> Unfortunately, like HTTP/2, this use seems to be mostly ignored (in HTTP/2 it
> was explicitly ignored, the response on the WG was "let them eat HTTP 1.1"
> when the matter was brought up).

Do the devices need to interop with web browsers? 

- If yes, those devices should be designed with newest specs (because
  otherwise those things likely will become stale an cause security
  headaches for _others_). Oh, and ECC asymmetric crypto is the lightest
- If no, then you should be using top-edge TLS or something non-TLS that
  is competently designed (esp. on constrained environments, as TLS is
  not very economical there, even with pure-PSK).

> >And it is pretty much non-starter as far as everything else is concerned.
> Do you have any basis for saying this, or are you just, I dunno, making random
> statements?

What libraries would implement that? TLS is not exactly simple to
implement. As evidenced by plenty of implementations with very basic
flaws (e.g. not sequencing the handshake properly, or not checking

> >It also does not fix the reasons why web browers [...]
> >
> >Heck, the web browser vendors don't seem to [...]
> As I've already said, there are lots of uses of TLS outside of web browsers.
> Yes, it's true, there are!  

Well, I know: I regularly have non-web TLS connections open, some even
with a client certificate.

> TLS 1.3/2.0/whatever-it'll-be-called is TLS-for-web-browsers (and content
> providers serving them).  TLS-LTS is TLS for everyone else.

What you think in TLS 1.3 is unsuitable for other usecases (excepting
quite constrained ones, where TLS (any version) is generally overly