IETF Logo Mail Archive

Re: [saag] NSA bug in Windows 10

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 18 January 2020 16:32 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 9484812003E for <saag@ietfa.amsl.com>; Sat, 18 Jan 2020 08:32:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 pVz3FDG6r1sk for <saag@ietfa.amsl.com>; Sat, 18 Jan 2020 08:32:43 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA22812002F for <saag@ietf.org>; Sat, 18 Jan 2020 08:32:42 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8A0B03897A; Sat, 18 Jan 2020 11:32:12 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9FAD9C4C; Sat, 18 Jan 2020 11:32:41 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: IETF SAAG <saag@ietf.org>, Dan Brown <danibrown@blackberry.com>
In-Reply-To: <fef9a825ad9046ce9aca662fc5b52f35@blackberry.com>
References: <CAMm+LwjbST2imHARvngfpBsp1vvABukrC+qXmktgxvAWhDnSxA@mail.gmail.com> <1579100916686.94828@cs.auckland.ac.nz> <5fd6bac7558d45fcac94119e746d7d0e@blackberry.com> <20200117040214.GR80030@kduck.mit.edu> <fef9a825ad9046ce9aca662fc5b52f35@blackberry.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Sat, 18 Jan 2020 11:32:41 -0500
Message-ID: <5365.1579365161@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/0C0p5U7hRkdj2s2jNMC72oGQ1ME>
Subject: Re: [saag] NSA bug in Windows 10
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: Sat, 18 Jan 2020 16:32:45 -0000

Dan Brown <danibrown@blackberry.com> wrote:
    > some kind of weak profiling attack - if there a multiple versions of the
    > real cert.)  Actually, the sender should not even send a copy C0' the root
    > cert, since C1, being allegedly issued by C0, should already identify C0
    > sufficiently, through the issuer field, no?  Who is the sender to tell the
    > receiver to trust C0'?

We had this discussion before, and while what you say is true for a majority
of live web/browser situations, it is not the whole story, and omitting C0
makes life very difficult.

We need the sender to send/include C0 for a great number of data-at-rest
situations, so we can consult and then pin C0.  We also need it for diagnostics.

The bug, is what you said: "the real bug is using the received cert at all"
The received bag of certificates need to be placed in an untrusted place, and
used only if they are validated by a trusted certificate.   The C0
certificate (being likely self-signed) clearly can never validate, so will
remain in the untrusted place.
(The middle place, for those who watched The Good Place)

    > To repeat, my view is that several claims of the fragility arising from the
    > excess of parameters in ECC certs is actually red herring. The fragility is
    > in RFC 3280, which seems to imply that the receiver does not keep C0' and
    > does some kind of secure, but partial match.

I agree.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email