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

Chris Palmer <> Wed, 08 October 2014 17:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 605231ACD62 for <>; Wed, 8 Oct 2014 10:43:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.165
X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ydwX9rN36x9n for <>; Wed, 8 Oct 2014 10:43:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D59771ACD55 for <>; Wed, 8 Oct 2014 10:43:07 -0700 (PDT)
Received: by with SMTP id g201so8330136oib.7 for <>; Wed, 08 Oct 2014 10:43:07 -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=oU9JUUFRBy4c6cyDs5fkvVj8+/7Gx6SVknZAONvjl6Y=; b=KCqwqnlRr61iFa+w+a1YX13hA2AQDsAmFWTskpTAXFIbBQQW4QRQFGNfFLHG3yJ4t4 2LSfgCd05UgVaY2+4Z2PJ2zsBJw8Std3yY5WNgm81alwrtkXas6IpsROJhNjzNZ3r/3x HWFjr9h1bFyx27rRS1wPYc0B51IoPOsYd6LvrKDwhJcuspv/TXWMaAheQgB5Z59l7YP7 CCAGjieMnW09kL9aIjJC1ZqkXEKWVQGraq8hT0QZvjjtHpjhxo/3PdI2a2ZRJeRb2Ppb o42bYQrOyTBVSXB3kAc3JjvEB29uHHGZQrWMyfwOsJDmL9tPUoAX2S4A03Cv2cF7pz1k 51fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oU9JUUFRBy4c6cyDs5fkvVj8+/7Gx6SVknZAONvjl6Y=; b=ipIq2KG6W0N6uEApaZUZQh59vSzJlGjbfRJeiEULT6Wg40mIkV+Tk+3gicTGp176Od CzO0nQI1JbGikPl3Y0CYObDbRpN34z1HYS2hVTUH4Kcmpo31Z9fc1j/yHu0l9j8NTBxn xhZ7uB9R7HpeIVRnCiXdFuqCVtklq3mGo7boggVCfT9H6covGmaqDugAyMbPd3dM4Y7Y EQ+oaqB6EQ5X4aCngE9KPHyT+h1BFnDcOdo3S5Atcvs718OTqxzixWSnlzzxUcXi8old fmFJP7l/w/DQcH7dpDqC90rlNtYhQnyEcOVZW66FtFc7At5wK/et7t7mV9AOmqt0JpMA Bgbw==
X-Gm-Message-State: ALoCoQm0S0lj3JeuqLn7goXhvUWHx+Oe0+Y6GgWRRZ7vlM0jXF8EI7OFaWXQPvWbt7HU3ZB/EBWG
MIME-Version: 1.0
X-Received: by with SMTP id q3mr14440612obi.28.1412790187196; Wed, 08 Oct 2014 10:43:07 -0700 (PDT)
Received: by with HTTP; Wed, 8 Oct 2014 10:43:07 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Wed, 08 Oct 2014 10:43:07 -0700
Message-ID: <>
From: Chris Palmer <>
To: Ted Lemon <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>, IETF WebSec WG <>, The IESG <>,
Subject: Re: [websec] Ted Lemon's No Objection on draft-ietf-websec-key-pinning-21: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Oct 2014 17:43:09 -0000

On Wed, Oct 8, 2014 at 8:02 AM, Ted Lemon <> 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.