Re: [TLS] Another IRINA bug in TLS

Watson Ladd <> Sun, 24 May 2015 12:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0D9071A1AC9 for <>; Sun, 24 May 2015 05:20:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 9dfJkenUzFYH for <>; Sun, 24 May 2015 05:20:38 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AA6751A8AB8 for <>; Sun, 24 May 2015 05:19:14 -0700 (PDT)
Received: by wicmx19 with SMTP id mx19so22093592wic.0 for <>; Sun, 24 May 2015 05:19:13 -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=nBRYLclOyny5Y1JZG269rzRnN/VFuB1dKhU/l8mtHMA=; b=EfdEC4mcA2MEecbqBjXior27v5fExhz6EeUPpTse0DvOMhrrgMio+1N+5fC10By/U5 Q+j6L9qCZOVI0OC7juaETv7I5IDOgyvDPXT6T9/ZjW89cXtAqMdIS8Mlw1jy89Kg7SoH OPy2b37qIOzbdyLWXrlF11Yh8IBEQBeCtKwE47U8L8SkqAgWGcAfRZtUiQuO26mQSa8z S4wOHI9Mac3Zq0nQvdOFaakRY5CeFNZudecf3FISR1dZ7RAZyAupeK9SpJP4kO7cz8hs 3ftkLCWgES/GBbD8sW29shXYXhaLw44C8uQM3MeLbOy7Q3IFcbplN9ZreFeL6pcofcWl F3Qg==
MIME-Version: 1.0
X-Received: by with SMTP id yp3mr30576817wjc.32.1432469953451; Sun, 24 May 2015 05:19:13 -0700 (PDT)
Received: by with HTTP; Sun, 24 May 2015 05:19:13 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Sun, 24 May 2015 08:19:13 -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 12:20:43 -0000

On Sat, May 23, 2015 at 9:35 PM, Jeffrey Walton <> wrote:
> On Sat, May 23, 2015 at 8:36 PM, Watson Ladd <> wrote:
>> On Fri, May 22, 2015 at 1:05 PM, Jeffrey Walton <> wrote:
>>> ...
>>> 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.
> Ah, this is a very good point. I just call it "drinking the koolaide".
> SSL was originally designed for ecommerce transactions. In ecommerce,
> risk is offloaded onto merchants and share holders. When something
> goes wrong, its the merchants and share holders who pay.
> After inception, SSL/TLS was repurposed for additional uses, but the
> risk model was not the same. For example, someone in Iran may use
> SSL/TLS to access their Gmail account, and that account may have email
> threads with views that are not popular with the current regime. But
> the risk was not offloaded, and lots of people were likely tortured
> and killed because of Diginotar.

Are we talking about phishing? No, we're not.

Are we talking about CA compromise? No, we're not.

The bugs we are discussing involve core security claims: that knowing
the private key associated to one end of a TLS connection is required
to know what data is sent. It's a problem that every single use of
cryptography faces. And it's trivially solvable: SSH has far fewer of
these problems. (It has other problems: check what your hostkeys are
people! If you generated them two decades ago, time to rotate)

So what exactly are you proposing as the solution, if you want to
protect all data? Or is this working group just not worth it: we would
need the Very Serious Security Protocol for you to actually think that
it's worth fixing this problems and sharing your infinite wisdom? I'm
well aware of how TLS got designed: SSH v1 also had tons of problems,
but SSH v2 fixed them all. IKEv1 had problems, IKEv2 fixed them all.
That's the point of having these new versions.

Of course, once you actually have the VSSP, you can just use it for
*all* your data, and replace TLS, SSH, etc. with it. Maybe instead of
quietly fixing holes, you should let all of us know about them, and we
should fix them.

Watson Ladd

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