Re: [websec] Feedback on draft-ietf-websec-key-pinning-01

David Illsley <davidillsley@gmail.com> Mon, 12 December 2011 21:09 UTC

Return-Path: <davidillsley@gmail.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF6D21F84AA for <websec@ietfa.amsl.com>; Mon, 12 Dec 2011 13:09:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.51
X-Spam-Level:
X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6gVK6n412eF for <websec@ietfa.amsl.com>; Mon, 12 Dec 2011 13:09:28 -0800 (PST)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7B621F8496 for <websec@ietf.org>; Mon, 12 Dec 2011 13:09:28 -0800 (PST)
Received: by pbbb4 with SMTP id b4so1754522pbb.31 for <websec@ietf.org>; Mon, 12 Dec 2011 13:09:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+MtjyEg+GpOswk1n6DiNVH7kaP9lzIzGTxd4aaTWQB8=; b=LSnALyPlA7xvXct1six1WK9o8Eirkwf9MGeHmnN7+BvJtqmlfvrfzQtN7KfE06PP5p UI+hX3q8KEEbEVpiByo7VLHFVVbN6ZeLIep5GMZuYbpj6ny3eugPUqNAATgaBBdqyTid BbRPxpTaXgqg9q/7EViuMbVkax6w68DTQ1Kas=
MIME-Version: 1.0
Received: by 10.68.191.106 with SMTP id gx10mr36654192pbc.60.1323724168366; Mon, 12 Dec 2011 13:09:28 -0800 (PST)
Received: by 10.68.49.166 with HTTP; Mon, 12 Dec 2011 13:09:28 -0800 (PST)
In-Reply-To: <CAOuvq23bRvDYKig4zNhmN91yBEOj2BG+-WzfA9wXwmVvJP8p_A@mail.gmail.com>
References: <7C746AD7-9448-4883-9A30-85A2E72C8AF5@gmail.com> <CAOuvq23bRvDYKig4zNhmN91yBEOj2BG+-WzfA9wXwmVvJP8p_A@mail.gmail.com>
Date: Mon, 12 Dec 2011 21:09:28 +0000
Message-ID: <CA+E3Fw2xiN6qTgBddekizFOhM5zER5Xj-qX9jskKneBGZGXmYw@mail.gmail.com>
From: David Illsley <davidillsley@gmail.com>
To: Chris Palmer <palmer@google.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: Chris Evans <cevans@google.com>, IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] Feedback on draft-ietf-websec-key-pinning-01
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Dec 2011 21:09:29 -0000

On Mon, Dec 12, 2011 at 7:38 PM, Chris Palmer <palmer@google.com> wrote:
> On Sun, Dec 11, 2011 at 5:03 AM,  <davidillsley@gmail.com> wrote:
>
>> With pinning, if they lose control of their DNS*, visitors during that period can be HSTS+pinned to a certificate which the domain owner has no access to, leading them open to long-term denial of service (beyond reclamation of DNS) or extortion.
>
> How do DNS registrars handle theft and extortion now? Does pinning
> significantly change the dynamic of the scam? It seems to me like
> pinning somewhat increases the visibility and detection risk of
> theft/extortion, but I admit I don't know much about this scam
> phenomenon. The victim must do more than just get the registrar to fix
> the DNS, they must also get the private keys for the falsely-pinned
> public keys. But the attacker has to get a certificate, which involves
> tricking both a registrar and a CA, and paying the latter.

I think the dynamic is changed because at the moment, you have a
registrar which you have a contractual relationship to fall back on
when something goes wrong, and things are likely resolved in a short
period of time. Once the registrar has straightened things out, you've
just got to wait for DNS TTLs to expire and you're good to go.

With pinning, your registrar can still straighten DNS out, but any
visitors who accessed the site in the affected period (hours-tens of
hours at a guess) are pinned to a private key you have no access to.

>
> (Since UAs MUST only note pins received over an error-free TLS
> connection, the attacker must have received a certificate for the
> domain name they stole, signed by a trusted certification authority.
> Obviously, that is not impossible (or even difficult, as you note).
> Importantly, due to the need for a CA-signed cert, the attack creates
> a "paper" and money trail. If it happens often, the internet community
> will come to know which CAs are not checking for domain theft, and we
> can start to un-trust those CAs. And we can ask them to tell us what
> they know about the attackers who bought the certs.)

Yeah, it's definitely useful to have more data points, but I'll put my
hands up to being pessimistic about the CA model. The paper trail
might be useful, but a stolen credit card from country A being used in
with a CA in country B when you're in country C might be hard to
really make anything of.

>
> This puts a bit of upward quality pressure on CAs. For example, maybe
> DV issuers could look more closely into the history of the domain's
> ownership before issuing the certificate: Has the new owner owned the
> domain for one day? Maybe we should call the technical contact who
> previously owned it for three years up until yesterday? Has the
> registrar had a rash of domain theft lately? This is good for
> everyone: internet users, internet site operators, and the CAs and
> registrars who work hard to be trustworthy. Pinning makes your choice
> of CA matter again.

We can wish... I'm still hoping we actually get CAs
special-case-checking DV certs for domains which have a publicly
facing EV cert...

>
>> There are a few responses to this I can think of:
>>
>> 1. It's 2011/2012... everyone should be using TLS+HSTS+Pinning
>> 2. It's fine - important sites will have decent pull with browser vendors to ship unlock pins...
>> 3. Modify the spec to make the vulnerability smaller
>
> Yes to (1) and (3), and like you I don't like (2). As a browser
> engineer, I don't want to be handling support emails from people
> who've had their domains hijacked — that won't scale — and internet
> security must be available to everyone.
>
>> 1 may be a valid response, but in that case, I think the spec should call out this potential vulnerability in section 3 and highlight that the only complete mitigation is to go to TLS+HSTS+Pinning. I think it's important to call out to implementors this possibility, and that they might have to deal with something like (2).
>
> Ok, I'll come up with some text.
Great. Thanks.

>
>> My only thought for 3 is to narrow the vulnerability by softening/not enforcing the pin until it's seen multiple times over at least some minimum period of time in which a DNS etc problem is likely to be rectified. There's already a bootstrapping hole, and I don't know that widening it by a small time period is a huge deal.
>
> Because the bootstrapping hole is so much smaller with pinning than
> without, I agree that we have some headroom to play with. Requiring a
> minimum time period might not be a bad idea. What would it look like?
> "UAs MUST note the same set of pinned public keys for 168 hours (7
> days) before treating the host as a Known Pinned Host and requiring
> Pin Validation." ?
>
> Does anyone have any data on domain theft and extortion? How often
> does it happen, how long does it last, how much is the ransom, et c.?

Unfortunately I don't, and I do think pinning does change things
anyway. FWIW, the event that made me think of this was apparently 'for
fun' [1]. Such people might also consider a long-term denial of
service 'fun' :-(
David
[1] http://www.guardian.co.uk/technology/2011/sep/05/turkish-hacker-group-diverts-users