Re: [saag] On PKI vs. Pinning (SAAG 108 preview)

Yaron Sheffer <yaronf.ietf@gmail.com> Fri, 21 August 2020 08:57 UTC

Return-Path: <yaronf.ietf@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 B66553A08C6 for <saag@ietfa.amsl.com>; Fri, 21 Aug 2020 01:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.525
X-Spam-Level:
X-Spam-Status: No, score=-0.525 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MALFORMED_FREEMAIL=1.573, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 vMOHFUL96dMX for <saag@ietfa.amsl.com>; Fri, 21 Aug 2020 01:57:09 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54BF63A08C1 for <saag@ietf.org>; Fri, 21 Aug 2020 01:57:09 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id p20so1259417wrf.0 for <saag@ietf.org>; Fri, 21 Aug 2020 01:57:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-transfer-encoding; bh=5aLv2fSuuq0m1GeislepLdyk1RXMKBEeijhQF4KLrfk=; b=PwXHhk5XFWogF0gbK5LHqzPFROFNBibCJfckAYS9knOeib/uQ7O/gfBVpCnGcjNnuM LDuRrIJ/wvVgr1JCFi28a/wQQ9Mxze9yKZEBdqNFpma3YFMmaeMK5QFamHMdqt3HAgLW 0ZoJo1cvreDAZOlMvTbsj3R3zmB3savh/Ijj+m8L8L60URnqsLRI9/olrbNYiXOy/szh a7wOEmljWHEeLauuey+fbJw2nBGm1WCC60hc0f79j++0jwi8KiysP2jcZGxQx86CgyME Czts/BUkLcKO1lkOoRiwdaVjLFVJRST5a6/4B4XaxUAPyKXs+ikqpa5h0FLlkuJMXT7R ldHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=5aLv2fSuuq0m1GeislepLdyk1RXMKBEeijhQF4KLrfk=; b=edbcl36lGuQilP+1ZAVxDYWELxABPSyhBkPW1qGsZtIKs8mik3X68s/50QWeCtv8zq 2lmRFfrHpQB7d9RleVlfQ207gvPjZq6z56nEDE2xk6UAINUzcPa2jCOmda4P2QtC91w0 3RbKFT/NlEfAoUYsTIZWQCvxQlHhN4jv61zHjqUNLtb0J/PidO6yiIprr3AYXiIuOnVN pqLCF1Y1jhJ8i5xbCxepzCsbUojrL0UWKomZqHHQASLdplPRJ2vKmGJmk9oLD2itk0Ez eAtxx2dQpMiqL6VxPdc9JFt4ctT8ZWoGJUzipmUT5IR0c9a1Beyt+NlnXmbpjyqBtkjt uI9g==
X-Gm-Message-State: AOAM5302zFtk93aG4HqROHpBcBo6JRhaod2k/L/UeIOD59PAwbeadF/C 6Ev7yfjFEiypQ0TKSgQ//Hw=
X-Google-Smtp-Source: ABdhPJybmdlJLyOnlNy1ONYXmgyY51dG268XNSSIip9qhbNdleqIjiH4+xsIqqmFxbsa/xJkyh78HA==
X-Received: by 2002:a5d:4a41:: with SMTP id v1mr1916512wrs.371.1598000227465; Fri, 21 Aug 2020 01:57:07 -0700 (PDT)
Received: from [10.0.0.139] (bzq-79-183-65-175.red.bezeqint.net. [79.183.65.175]) by smtp.gmail.com with ESMTPSA id v7sm3348402wmj.28.2020.08.21.01.57.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Aug 2020 01:57:06 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/16.40.20081000
Date: Fri, 21 Aug 2020 11:57:05 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, Benjamin Kaduk <kaduk@mit.edu>, <saag@ietf.org>
Message-ID: <429787F2-CF84-493B-8201-4C1EF4AE7FD1@gmail.com>
Thread-Topic: [saag] On PKI vs. Pinning (SAAG 108 preview)
References: <20200728191331.GV41010@kduck.mit.edu> <25733.1597953420@localhost>
In-Reply-To: <25733.1597953420@localhost>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/GoSXB5AaO_DqcmejE3r_-AdGjdY>
Subject: Re: [saag] On PKI vs. Pinning (SAAG 108 preview)
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 21 Aug 2020 08:57:11 -0000

On 8/20/20, 22:57, "saag on behalf of Michael Richardson" <saag-bounces@ietf.org on behalf of mcr+ietf@sandelman.ca> wrote:

    Yaron writes:
    > Exactly! Daniel Migault and I published an RFC [1] on "identity pinning" in
    > TLS 1.3. This is TOFU pinning seen as a second factor, where the first
    > factor is PKI. It also happens to be very low maintenance and independent
    > of certificate (EE and CA certificate) changes. This solution is especially
    > useful for enterprise use cases, where certificate transparency doesn't do
    > the job.

    I think that there are two divergent types of pin, and there were allusions
    which I missed in the saag meeting as to who is using the term in a different
    way.   Yaron describes pinning as second factor, which assumes that the PKI
    is minimally valid.  It guards, I think, against a different CA issuing a
    name.   The pin is more of a configured name-constraint, I think, but I only
    browsed that RFC very quickly.
    The other kind of pinning assumes that the PKI does not reach known root,
    or rather it configures a new trust anchor for the use of this API.
    I gave a talk at INTC today about Enterprises and trust anchors, and I think
    that this is very relevant.  Enterprises are mostly lost here.

To further clarify: I used the word PKI loosely, and should have said "a preconfigured trust store". The first factor in RFC 8672 is normal TLS cert validation, where the trust store can be the Mozilla set of trust anchors, or that set plus the enterprise CA, or just the enterprise CA. Yes, the main goal is to protect from a different CA mis-issuing a certificate for the same name, but surprisingly, even the same CA is prevented from issuing a stealth cert with the same name for a different TLS server. The pin is an additional constraint but not a configured one. Because of the TOFU behavior, no configuration is required.

Thanks,
	Yaron