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

"Ted Lemon" <ted.lemon@nominum.com> Wed, 08 October 2014 15:02 UTC

Return-Path: <ted.lemon@nominum.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 126631A1BE5; Wed, 8 Oct 2014 08:02:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id LHkpwQPVOwNP; Wed, 8 Oct 2014 08:02:11 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A14191A1BE4; Wed, 8 Oct 2014 08:02:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Ted Lemon <ted.lemon@nominum.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.3.p4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20141008150209.2897.72243.idtracker@ietfa.amsl.com>
Date: Wed, 08 Oct 2014 08:02:09 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/mzJF0PIfa4zKRaDDivXM85d5Z-A
Cc: draft-ietf-websec-key-pinning@tools.ietf.org, websec@ietf.org, websec-chairs@tools.ietf.org
Subject: [websec] Ted Lemon's No Objection on draft-ietf-websec-key-pinning-21: (with COMMENT)
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 08 Oct 2014 15:02:13 -0000

Ted Lemon has entered the following ballot position for
draft-ietf-websec-key-pinning-21: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


I've cleared my DISCUSS.   For the record, here it is, but there is no
further action required:

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.