Re: [saag] [TLS] Fwd: Pinning

Nikos Mavrogiannopoulos <nmav@gnutls.org> Wed, 06 June 2012 12:17 UTC

Return-Path: <n.mavrogiannopoulos@gmail.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FED21F886B for <saag@ietfa.amsl.com>; Wed, 6 Jun 2012 05:17:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgDBSYRVOQqC for <saag@ietfa.amsl.com>; Wed, 6 Jun 2012 05:17:19 -0700 (PDT)
Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0856021F883F for <saag@ietf.org>; Wed, 6 Jun 2012 05:17:18 -0700 (PDT)
Received: by ggnc4 with SMTP id c4so5406666ggn.31 for <saag@ietf.org>; Wed, 06 Jun 2012 05:17:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=P5YluU2pZ8Bj/6zs2fMAuGZRc8juJiFP6sBbv8Xd40s=; b=lxGtNai6D8HMjRWMMV+KfXK4aLp1Ax74h/Rl2wxtyQbH23sKqWRml0qwRuObZNinsB jwbBMYtAv68a+cAw5b6g62J3jzTavgSWig3tiZQmrDhtf5EPRRtT4awuQyEEAHoxzBTk 8x5Ul8Z37Hi0AfxJ6p+HwOM8f52+ISiCqgi4IEqL/NfCg/2Ci5BtvxVix6OiUuj+orSq DNvTTVNOR6Q4pQ+zxC7T22z45cLBRYcKnxT0crqk/WTUlXDgtB/RyozlCkisRqI+zsur f/DFT/DmDmqJ/vqgSFQsOXGPRpPs6+AwthsIhxzNygExyTOLRzCFaEwbhhHwqhbCvYmw ERtQ==
MIME-Version: 1.0
Received: by 10.42.12.83 with SMTP id x19mr13376917icx.16.1338985038439; Wed, 06 Jun 2012 05:17:18 -0700 (PDT)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.231.80.15 with HTTP; Wed, 6 Jun 2012 05:17:18 -0700 (PDT)
In-Reply-To: <B03D70FE-E3C2-46B9-89B2-3FF0F6794864@vpnc.org>
References: <4FCE6431.6050808@ieca.com> <B03D70FE-E3C2-46B9-89B2-3FF0F6794864@vpnc.org>
Date: Wed, 06 Jun 2012 14:17:18 +0200
X-Google-Sender-Auth: 4hA1gNgllLjckzqoqpXLWNAgyXU
Message-ID: <CAJU7zaLi4i9-kYSk7M0YM+4o5be3G3enYmY12irxCB0WwXE+GQ@mail.gmail.com>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: saag@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [saag] [TLS] Fwd: Pinning
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jun 2012 12:17:19 -0000

On Tue, Jun 5, 2012 at 11:17 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> From the SAAG mailing list, but appropriate here. I bet that Sean would appreciate all discussion to go on on the SAAG mailing list...
> Begin forwarded message:
>> From: Sean Turner <turners@ieca.com>
>> Subject: [saag] Pinning
>> There are many proposals for how to say which key or certificate or trust anchor should be used by the client in a TLS session that it is about to open. These proposals include making that decision in the DNS (https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/), in the application after TLS has happened once, to be remembered in the future (https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/), and in the TLS handshake (https://datatracker.ietf.org/doc/draft-perrin tls-tack/). If more than one of these protocols are deployed, operational mistakes could lead to a client getting conflicting information.

The fact that more than one protocols can be deployed is an advantage.
In that case an attacker needs to control more infrastructure in order
to perform an attack on a TLS session. If you compare to the current
situation where the attacker only needs to control a random CA, it
looks like an improvement. Of course the situation can be improved by
restricting to few of these approaches rather than all (more peer
verification paths is better, but also increases the probability of
something going wrong unintentionally and thus false alarms).

regards,
Nikos