IETF Logo Mail Archive

Re: [saag] NSA bug in Windows 10

Benjamin Kaduk <kaduk@mit.edu> Fri, 17 January 2020 04:02 UTC

Return-Path: <kaduk@mit.edu>
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 14BC4120058 for <saag@ietfa.amsl.com>; Thu, 16 Jan 2020 20:02:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 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, URIBL_BLOCKED=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 tbNopZt6IfQH for <saag@ietfa.amsl.com>; Thu, 16 Jan 2020 20:02:29 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F3A212008F for <saag@ietf.org>; Thu, 16 Jan 2020 20:02:29 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00H42EPx032256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Jan 2020 23:02:17 -0500
Date: Thu, 16 Jan 2020 20:02:14 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Dan Brown <danibrown@blackberry.com>
Cc: Peter Gutmann <pgut001@cs.auckland.ac.nz>, Phillip Hallam-Baker <phill@hallambaker.com>, IETF SAAG <saag@ietf.org>
Message-ID: <20200117040214.GR80030@kduck.mit.edu>
References: <CAMm+LwjbST2imHARvngfpBsp1vvABukrC+qXmktgxvAWhDnSxA@mail.gmail.com> <1579100916686.94828@cs.auckland.ac.nz> <5fd6bac7558d45fcac94119e746d7d0e@blackberry.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5fd6bac7558d45fcac94119e746d7d0e@blackberry.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/wWgvz4VZh1OGvm1grWJJ9XkHNXA>
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: Fri, 17 Jan 2020 04:02:31 -0000

On Thu, Jan 16, 2020 at 04:40:41PM +0000, Dan Brown wrote:
> Based on what I hear others say online, I presume this bug resulted a
> relying party using details of a received root certificate instead of a
> details in the true trusted root certificate.
> 
> https://www.rfc-editor.org/rfc/rfc3280#section-6.1.1
> item (d), (4) talks about parameters in the trust anchor certificate, and
> the next paragraph talks about a "delivered ... trustworthy out-of-band".
> 
> If my presumption above is correct, then it seems that this part of RFC3280
> was not followed in this bug, since the parameters were taken from an
> untrustworthy in-band delivery.   That said, I wonder if RFC3280 adequately
> emphasized this point? Could it have used a MUST?

I remember reading something that involved taking an existing signature
made by a trusted root from a legitimate certificate issued by that root,
and re-using that signature with different domain parameters.  That would
seem to imply that the trusted root is properly being used, but the
validation code for the signatures in the chain was flawed.

-Ben

v2.23.0 | Report a Bug | By Email