Re: [websec] Ted Lemon's No Objection on draft-ietf-websec-key-pinning-21: (with COMMENT)

Chris Palmer <palmer@google.com> Wed, 08 October 2014 17:43 UTC

MIME-Version: 1.0
In-Reply-To: <20141008150209.2897.72243.idtracker@ietfa.amsl.com>
References: <20141008150209.2897.72243.idtracker@ietfa.amsl.com>
Date: Wed, 08 Oct 2014 10:43:07 -0700
Message-ID: <CAOuvq23fEApmqUHnOnuhKF72Z+wPSVr-zsUMiW2gWLpm4dreFQ@mail.gmail.com>
From: Chris Palmer <palmer@google.com>
To: Ted Lemon <ted.lemon@nominum.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/9SzpB1pNxb4-AkW82qlA4ijg3ao
Cc: "draft-ietf-websec-key-pinning@tools.ietf.org" <draft-ietf-websec-key-pinning@tools.ietf.org>, IETF WebSec WG <websec@ietf.org>, The IESG <iesg@ietf.org>, websec-chairs@tools.ietf.org
Subject: Re: [websec] Ted Lemon's No Objection on draft-ietf-websec-key-pinning-21: (with COMMENT)
Precedence: list

On Wed, Oct 8, 2014 at 8:02 AM, Ted Lemon <ted.lemon@nominum.com> wrote:

> This mechanism relies on there being no MiTM attack from a compromised
> signing key either prior to a legitimate pinning, or in a situation where
> the host being "protected" doesn't actually do pinning.   I think this
> should be mentioned in the security considerations section.   I raise
> this to the level of DISCUSS because I think this actually creates a new
> attack surface for government censorship: you MiTM the host you're
> attacking, pin it to a cert signed using a compromised CA, and then that
> UA can't communicate with the host again for the duration of the pin.
>
> The scenario would be that the government has a transparent web cache in
> the path between the host and the UA, and the web cache pins false cert
> for hosts that are being censored.   Now even if the user sets up a
> tunnel to bypass the transparent cache, they can't access the censored
> site, so they conclude that the site is down and abandon the tunnel.   I
> could easily see this being used in a scenario like the recent DNS
> censorship in Turkey.
>
> Setting a lower maximum pin age mitigates the damage of such attacks if
> the user keeps the tunnel up for the duration of the pin, but I don't
> think it's realistic to assume that they will.   I think that the only
> way to mitigate this attack is to have a mechanism whereby conflicting
> DANE TLSA information overrides the pin.   This would allow a site being
> attacked in this way to securely inform the UA that the pin was invalid.
>  The government could of course prevent DNSSEC validation, but the UA
> could take this as another signal to drop the pin: if the zone where the
> TLSA record should be fails to validate (as opposed to isn't signed,
> which wouldn't signify anything), the pin is likely a censorship attempt.

http://tools.ietf.org/html/draft-ietf-websec-key-pinning-21#section-4.5

[websec] Ted Lemon's No Objection on draft-ietf-w… Ted Lemon
Re: [websec] Ted Lemon's No Objection on draft-ie… Chris Palmer