Re: [saag] NSA bug in Windows 10

Dan Brown <danibrown@blackberry.com> Thu, 16 January 2020 16:40 UTC

Return-Path: <danibrown@blackberry.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 3E288120AF4 for <saag@ietfa.amsl.com>; Thu, 16 Jan 2020 08:40:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JTa-VAxDaubt for <saag@ietfa.amsl.com>; Thu, 16 Jan 2020 08:40:54 -0800 (PST)
Received: from smtp-pg11.blackberry.com (smtp-pg11.blackberry.com [68.171.242.227]) (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 D0111120A37 for <saag@ietf.org>; Thu, 16 Jan 2020 08:40:53 -0800 (PST)
Received: from pps.filterd (mhs401ykf.rim.net [127.0.0.1]) by mhs401ykf.rim.net (8.16.0.27/8.16.0.27) with SMTP id 00GGeAMh098521; Thu, 16 Jan 2020 11:40:42 -0500
Received: from xct107cnc.rim.net (xct107cnc.rim.net [10.65.161.207]) by mhs401ykf.rim.net with ESMTP id 2xju3d832m-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 Jan 2020 11:40:42 -0500
Received: from XCH212CNC.rim.net (10.3.27.117) by XCT107CNC.rim.net (10.65.161.207) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 16 Jan 2020 11:40:41 -0500
Received: from XCH210YKF.rim.net (10.2.27.110) by XCH212CNC.rim.net (10.3.27.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Thu, 16 Jan 2020 11:40:41 -0500
Received: from XCH210YKF.rim.net ([fe80::ac8d:3541:704c:478a]) by XCH210YKF.rim.net ([fe80::ac8d:3541:704c:478a%5]) with mapi id 15.01.1847.003; Thu, 16 Jan 2020 11:40:41 -0500
From: Dan Brown <danibrown@blackberry.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, Phillip Hallam-Baker <phill@hallambaker.com>, IETF SAAG <saag@ietf.org>
Thread-Topic: [saag] NSA bug in Windows 10
Thread-Index: AQHVy7SGNI3L+VtQR0yNz6MvRiowqqfsJ7uAgAFTuGA=
Date: Thu, 16 Jan 2020 16:40:41 +0000
Message-ID: <5fd6bac7558d45fcac94119e746d7d0e@blackberry.com>
References: <CAMm+LwjbST2imHARvngfpBsp1vvABukrC+qXmktgxvAWhDnSxA@mail.gmail.com> <1579100916686.94828@cs.auckland.ac.nz>
In-Reply-To: <1579100916686.94828@cs.auckland.ac.nz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [100.64.97.136]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="2.16.840.1.101.3.4.2.1"; boundary="----=_NextPart_000_0034_01D5CC61.C6EFDC80"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-16_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001160136
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/Xw4d9QCpptq5LQYsE2LTHNw65oc>
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: Thu, 16 Jan 2020 16:41:02 -0000

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?

Best regards, 

Dan 

----------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.