Re: [TLS] Another IRINA bug in TLS

Jeffrey Walton <> Sun, 24 May 2015 01:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 07AC71A009B for <>; Sat, 23 May 2015 18:35:32 -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 Btk8ZyXjUQQF for <>; Sat, 23 May 2015 18:35:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 90C071A0099 for <>; Sat, 23 May 2015 18:35:30 -0700 (PDT)
Received: by igbhj9 with SMTP id hj9so16779357igb.1 for <>; Sat, 23 May 2015 18:35:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0oJ3JfRRnDWjrloFI3Lmtz/hMydUEDjY4yRdnSYRFJY=; b=jIQgbP9rMt3YrTxwAwlR4vYjvfdRobXVCphtpE2hAZ/3v+6dOlppTyp7QRz1F7Hmem LGttUh9Y0z0SeGDnCcSMtzyDYbiZpw0jI4cOqr+uOHvEhpgbNRrImxMD9mFN+jkk93pW FXc7QP2WINtqqNYFCD7fxu1ovtd4dcG8LmNswAg2F+mT9bTrk0gbRfOo/vcyLFsu1+Ue Vb6bc4Wpf2F/GvU3jBhL3W5ox0WjWJayH/YTY8ZxK5aV693v+0IASjHYVnlu5iEqL3wL usx2pBMwTNweZt/lLD9yZbB7alez2gSRulnveS2orvHJjGN2VT9c/du5QOmS9lmVGKpB pZfQ==
MIME-Version: 1.0
X-Received: by with SMTP id p2mr6882138igr.9.1432431328997; Sat, 23 May 2015 18:35:28 -0700 (PDT)
Received: by with HTTP; Sat, 23 May 2015 18:35:28 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Sat, 23 May 2015 21:35:28 -0400
Message-ID: <>
From: Jeffrey Walton <>
To: 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 01:35:32 -0000

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.

>From my time in US Financial, we were well aware of the problems with
browser based web applications and underlying technologies like PKIX.
We would regularly decline browser based applications for use in the
firm. The application would then be sent into risk acceptance *if* a
director or VP really wanted to use it.

If the system handled low value data, like online banking, then the
firm would accept the risk because they did not want to lose
customers. That is, they chose to accept the risk. If it was high
value data, like pending litigation, mergers and acquisitions,
executive compensation, then the risk committee would not overrule us.
That is, they would not accept the risk.

By the way, the "... did not want to lose customers" is one of the
reasons we lack 2FA in so many US banks. They don't want to make it
inconvenient on their existing customers. And its one of the reason US
Financial suffers loses at 25x to 600x than their European