Re: [TLS] Another IRINA bug in TLS

Watson Ladd <> Sun, 24 May 2015 00:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 565DF1A0013 for <>; Sat, 23 May 2015 17:36:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.6
X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sCP9wg_3uTo0 for <>; Sat, 23 May 2015 17:36:50 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6C1F31A000F for <>; Sat, 23 May 2015 17:36:50 -0700 (PDT)
Received: by wizk4 with SMTP id k4so19499588wiz.1 for <>; Sat, 23 May 2015 17:36:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=emmUIqov1oCzmNPfsshgaBsqhw1w5q2ww+6ePloSfr0=; b=haClirk388zozSuO834Wb6PMGGhS2HgMlzMcISkGomVXJbx1ijPDYQf+JvlF+uJ0cR mRY5cKtIvXaf+pUnw7U6d5nXmdVF37sG4eS5sqIWHGwR51ob7A2OHZ8vidoIsOlElckC jn7rp2h9NF1hlFXAtEG/+3q0EbkeJNUOA7JVQFSjEVl5dI6mMYrRYISE5AiVA5rGsbUy ER9qArdLCqq54PwBrEdJmei+/mLZNsAa4DHOXqXrHDtPBkC8Hv6+htAK32klXyjnYDgH ayhl6z6onwRdmAbeWPu2QbqqfVy00PxzvMM23AsquK9BDOIAUvbhjPPQEwF+mJ6bZkMy WCKw==
MIME-Version: 1.0
X-Received: by with SMTP id yp3mr26930758wjc.32.1432427809257; Sat, 23 May 2015 17:36:49 -0700 (PDT)
Received: by with HTTP; Sat, 23 May 2015 17:36:49 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Sat, 23 May 2015 20:36:49 -0400
Message-ID: <>
From: Watson Ladd <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "<>" <>
Subject: Re: [TLS] Another IRINA bug in TLS
X-Mailman-Version: 2.1.15
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: Sun, 24 May 2015 00:36:52 -0000

On Fri, May 22, 2015 at 1:05 PM, Jeffrey Walton <> wrote:
> On Fri, May 22, 2015 at 10:54 AM, Peter Gutmann
> <> wrote:
>> Santiago Zanella-Beguelin <> writes:
>>>Regarding validation of DHE parameters and how reasonable it is in practice,
>>>I wanted to make some publicity for miTLS (
>>>A miTLS client maintains a table of known trusted parameters, including the
>>>subgroup order for parameters with non-safe primes. When receiving unknown
>>>parameters from a server, it tests the primality of p and (p-1)/2 to check if
>>>p is a safe prime (and caches a positive result in the table).
>> So you do a full primality test (Miller-Rabin or whatever) for each connect?
>> Doesn't that make it awfully slow?
> The software under my purview does.

And that software would be? Of course, once software is designed and
written it doesn't cost more to use. The whole rationale of protecting
some information less than others ignores the zero marginal cost of

> I don't allow the developers to use any parameters without validation.
> That includes crypto parameters. But its for a systems that handles
> medium and high value data; and not low value data where web browsers
> and their use of TLS would be appropriate.

But that use is what TLS was originally designed for. We have to be
very clear on this point: TLS lacks properties other protocols, like
SSH have, that would defend against these attacks. Some of these
attacks are made worse by implementation complexity and bugs, assisted
by the use of informal descriptions of protocols instead of formal
> I don't think browsers will ever be able to handle anything other than
> low value data, so I probably won't have to worry about web browsers
> and what do (or don't) validate before use.

Web browsers handle bank account information, tax returns, user
accounts, etc for billions of people. Hard to think of a more
high-importance target.

>>>If the modulus is prime but not safe, miTLS checks if it is in the table of
>>>trusted parameters and otherwise rejects it. We distribute miTLS with a pre-
>>>populated table of parameters which we tested thoroughly (and we welcome
>>>people to test further). Most of the time we hit an entry in the table.
>> What testing do you do on unsafe primes?
> GnuTLS with its Lim-Lee primes causes me a lot of problems because
> they cannot be validated.
> If we encounter them, then developers are *not* allowed to apply a
> secret to them. The user has to generate a new, verifiable key and
> then add that key to their keyring.
> Jeff
> _______________________________________________
> TLS mailing list

"Man is born free, but everywhere he is in chains".