IETF Logo Mail Archive

Re: [TLS] Rethink TLS 1.3

Yoav Nir <ynir.ietf@gmail.com> Mon, 24 November 2014 20:41 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4C71A9027 for <tls@ietfa.amsl.com>; Mon, 24 Nov 2014 12:41:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8BGAwrgPLC4 for <tls@ietfa.amsl.com>; Mon, 24 Nov 2014 12:41:49 -0800 (PST)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C6A51A1A4F for <tls@ietf.org>; Mon, 24 Nov 2014 12:41:49 -0800 (PST)
Received: by mail-wi0-f176.google.com with SMTP id ex7so7018639wid.9 for <tls@ietf.org>; Mon, 24 Nov 2014 12:41:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=JxGYzvOjIUN3i82s4xoP8tEwEn+RbPNWmosgg2Uuwew=; b=whsEm7uCXPjHuv6V0BSzL7HmwPCPxRZwdhDOvp6jQjUQbTBZnqVX/TnjRK9TFzDM9u JGqU252Zo6AxF/2NvwcNGLt9S4frwlf9WqdftCx2ZBOOAK4MNs+txlxrtVoXNeEOFT+Z X1Gd+x47ROLPivlgMccLiNMz/ScxNlmiBCWPO4l8si+hGgjrPvn6SFV8ODRlq5/6e++L 5e77OXsmJysaXGemEU5KJINaNVczCa2bbp3YJM8ZdokWGVs0q5zp5nQ+XNsNN5IhbWpy n24CDYNUx9iHJESzrJCoC726ryx2pErIfO6CCwOKtkjktWpCxE2P4DSfz7jmHhB6iS81 9xFw==
X-Received: by 10.180.90.241 with SMTP id bz17mr25335515wib.41.1416861708026; Mon, 24 Nov 2014 12:41:48 -0800 (PST)
Received: from [192.168.1.104] (IGLD-84-228-139-23.inter.net.il. [84.228.139.23]) by mx.google.com with ESMTPSA id lp14sm13538148wic.20.2014.11.24.12.41.46 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Nov 2014 12:41:47 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <54738EB8.7040908@fifthhorseman.net>
Date: Mon, 24 Nov 2014 22:41:44 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <AE50C73D-DCE6-4D24-9A1A-9C16BF17A123@gmail.com>
References: <CACsn0ckmYrx+S--pP6P7VgjsmqQsoYnp+m-9hTPT-OJ9waUtkA@mail.gmail.com> <5470742A.8020002@streamsec.se> <CACsn0cnKqkHxw0Hudw0OGM1mVxZKJhj04ig2G3KtURtWhYTacw@mail.gmail.com> <CA+K9O5QqX1fwLHVguoM4C0n=VAkg5C_ytnBfBTp-ckvCKzFuDA@mail.gmail.com> <CAH8yC8myNFg6tkHiA5eAGO8NfXjkUjB6ft9noR3gS_V6m5v3Ww@mail.gmail.com> <54738EB8.7040908@fifthhorseman.net>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/L1ZwBLuaUPUCKa1EsgOejrtescc
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Rethink TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Nov 2014 20:41:51 -0000

> On Nov 24, 2014, at 10:02 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> 
> On 11/23/2014 04:40 PM, Jeffrey Walton wrote:
>> In fact, the IETF seem to accommodate interception in its standards,
>> which makes me wonder if its an unwritten agenda. For example, Public
>> Key Pinning opaquely accommodates interception by allowing attackers
>> to break pinsets (cf. Section 2.7 of
>> https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21). And the
>> ability to surreptitiously break a pinset is not listed in security
>> considerations.
> 
> https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21#section-2.7
> 
> reads:
> 
> 2.7.  Interactions With Preloaded Pin Lists
> 
>   UAs MAY choose to implement additional sources of pinning
>   information, such as through built-in lists of pinning information.
>   Such UAs should allow users to override such additional sources,
>   including disabling them from consideration.
> 
>   The effective policy for a Known Pinned Host that has both built-in
>   Pins and Pins from previously observed PKP header response fields is
>   implementation-defined.
> 
> Can you explain how this can be used by an attacker to break a pinset?
> 

I think Jeffrey meant section 2.6:

                                         It is acceptable to allow Pin
   Validation to be disabled for some Hosts according to local policy.
   For example, a UA may disable Pin Validation for Pinned Hosts whose
   validated certificate chain terminates at a user-defined trust
   anchor, rather than a trust anchor built-in to the UA (or underlying
   platform).

This is not some unwritten agenda of the IETF. This section was discussed extensively. Browser vendors (among others) felt that Key Pinning could not be deployed without the sentence above. The working group did consider adding an optional “strict” directive that would prohibit such behavior (and make such websites unaccessible from behind an intercepting proxy), but ultimately rejected this option as vendors (not the IETF) decided they didn’t want to implement this.
 
Yoav

v2.23.0 | Report a Bug | By Email