[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

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>
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)

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:
http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

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