From nobody Tue Jan 7 06:23:15 2020 Return-Path: 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 EB73B12008C for ; Tue, 7 Jan 2020 06:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 XHDQKruBBt_2 for ; Tue, 7 Jan 2020 06:23:12 -0800 (PST) Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) (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 5E8D712001A for ; Tue, 7 Jan 2020 06:23:12 -0800 (PST) Received: by mail-oi1-f178.google.com with SMTP id a67so17816254oib.6 for ; Tue, 07 Jan 2020 06:23:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5vq4zq4Gs2wtC/ERFhn195yANzj4jZbTHEz9iSYC0dE=; b=YnrUQ4Gk+KtaV/yEL011fiHU+NCScxPem+Nl83IGa3tNyOYEc9ovwmKtTWC03+/F2X zjjfQ+fcl+2wbm9K1yyuewiCQmAS8jyy7IkAId+SCziepHSp5LWAjGAYtToySGYR2t0Q UPfyYc/owbvZZc3p2iFENmXRVVkF8pTt5SUz2c5NqXsYBsl3eLRZv92Xv99H4bAxHxty nWylPTQR43y1rsHAdM/lPGtXG9kHF7V92ZqMMc+UcXvptwlMqaaIE8/bpMQLg+FZN0hd DaavRAnHZv+8pF3SkZ5lWzMbGnZaSeb3tqnaVGI5qtFlfFhK37z7hUxiaj3Bi00bSrKd 7dBw== X-Gm-Message-State: APjAAAXq0V559y12GBMha9nPFY/g1SupYKY51KWDHSqmO/NnuYvM+nYH SQCudlsn9T8iHCi3SYZKfnfCadBVFgfXmnsErE7RGQtxwq0= X-Google-Smtp-Source: APXvYqwlZ5+N8UpNrcdNHoWmkK+qfohfbqe6vWOd5WNNZs9nI6+kMCG7j8G/m3gdw9mzjczHYmmDkb/iCQEa1sAGiss= X-Received: by 2002:aca:3241:: with SMTP id y62mr6935367oiy.31.1578406991119; Tue, 07 Jan 2020 06:23:11 -0800 (PST) MIME-Version: 1.0 From: Phillip Hallam-Baker Date: Tue, 7 Jan 2020 09:23:00 -0500 Message-ID: To: IETF SAAG Content-Type: multipart/alternative; boundary="000000000000044a4b059b8d84d1" Archived-At: Subject: [saag] Side channel resistance, threshold signatures, etc. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 14:23:14 -0000 --000000000000044a4b059b8d84d1 Content-Type: text/plain; charset="UTF-8" As promised, I wrote up the use of threshold schemes for key agreement, key generation and signature: https://www.ietf.org/id/draft-hallambaker-threshold-00.html https://www.ietf.org/id/draft-hallambaker-threshold-sigs-00.html The signature scheme proposed is a threshold scheme, not an aggregate signature. It is not possible to use the scheme as specified to sign documents using arbitrary sets of pre-existing keys. As with 'true' proxy re-encryption, this is a cryptographic capability that imposes significant demands (i.e. requires pairing) but does not provide compelling additional benefit. I think it is clear that notwithstanding the work on new public key systems that are threshold friendly (e.g. BLS), there is great value in extracting the maximum capability from our existing algorithms. The same algorithms will of course apply to other curves besides the CFRG ones. But if we are going to move forward with ECC, best to put all the wood behind the same arrow. One other point is that the first paper could be used to address the NIST objection to the deterministic RFC8032 signature scheme (which I endorse). It is my understanding that the Kocher side channel blinding patent expired last year and so it is now possible for all applications, including open source, to use key splitting against a random number and combination of the results to effect a degree of side channel resistance. It is my personal view that this should be employed for Montgomery curves as well because I do not believe the ladder is as 'constant' as people imagine. What I am trying to work towards here is the specification of a common cryptographic core that could be implemented at the hardware level on mid range CPUs and above to defeat the use of the SPECTRE class hardware attacks and to permit binding of cryptographic material to a specific host without exposing the users to compromise during manufacture (or manufacturers of being accused of the compromise). The basic idea is that the CPU has a single private key 'x' embedded during manufacture such that it cannot be extracted. Applications can get the public key X which is fixed for all the users on the machine. The built in key may be used in two different ways. In either case, the application generates its own key pair {Y, y}. It may then decide to perform all private key operations itself and combine the results or pass y to the coprocessor to be added to the result. The two operations the CPU module will perform would be limited to: 1) given a point P, return x.P 2) given a scalar k, generate a random value 0 < r < L and return {r.P, r + x.k} The smaller the requirements, the more likely it is we can get what we need. So it might well be that a hardware module only supported the Edwards or the Montgomery curves and applications were required to use the isomorphisms to map from one to the other. Two decades after I first attended my first (and last) 'Trusted Computing' WG meeting, deployment of the original TPM model is no closer. I suspect that a great deal of the opposition to TPMs was cleverly orchestrated to discourage proliferation of effective strong cryptography (the $250 million/yr on BULLRUN obviously went somewhere). But regardless, the achilles heel of that scheme was and is the need for a physical token (SIM card / TPM) to effect device portability. The threshold models I have developed allow those restrictions to be avoided. Alice can deploy keys to all her devices that allow them to encrypt, authenticate and sign and retain the ability to recover data from a broken machine, port data between her machines etc. without the need for the crypto processor to be on a pluggable daughter board. The only real limitations of this model come from conflicting requirements. I cannot design a key recovery system that only works when the 'good guys' are using it. --000000000000044a4b059b8d84d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As promised, I wrote up the use of threshold sche= mes for key agreement, key generation and signature:



The signature scheme prop= osed is a threshold scheme, not an aggregate signature. It is not possible = to use the scheme as specified to sign documents using arbitrary sets of pr= e-existing keys. As with 'true' proxy re-encryption, this is a cryp= tographic capability that imposes significant demands (i.e. requires pairin= g) but does not provide compelling additional benefit.

I think it is clear th= at notwithstanding the work on new public key systems that are threshold fr= iendly (e.g. BLS), there is great value in extracting the maximum capabilit= y from our existing algorithms.=C2=A0

The same algorithms will of course apply to other curves= besides the CFRG ones. But if we are going to move forward with ECC, best = to put all the wood behind the same arrow.

One other point is that the first = paper could be used to address the NIST objection to the deterministic RFC8= 032 signature scheme (which I endorse). It is my understanding that the Koc= her side channel blinding patent expired last year and so it is now possibl= e for all applications, including open source, to use key splitting against= a random number and combination of the results to effect a degree of side = channel resistance. It is my personal view that this should be employed for= Montgomery curves as well because I do not believe the ladder is as 'c= onstant' as people imagine.=C2=A0

What I am trying to work towards here is the specification of a= common cryptographic core that could be implemented at the hardware level = on mid range CPUs and above to defeat the use of the SPECTRE class hardware= attacks and to permit binding of cryptographic material to a specific host= without exposing the users to compromise during manufacture (or manufactur= ers of being accused of the compromise).
=
The basic idea is that the CPU has a= single private key 'x' embedded during manufacture such that it ca= nnot be extracted. Applications can get the public key X which is fixed for= all the users on the machine. The built in key may be used in two differen= t ways. In either case, the application generates its own key pair {Y, y}. = It may then decide to perform all private key operations itself and combine= the results or pass y to the coprocessor to be added to the result.=C2=A0<= /div>

Th= e two operations the CPU module will perform would be limited to:

1) given a = point P, return x.P
2) given a scalar k, = generate a random value 0 < r < L and return {r.P, r + x.k}

=
The smaller the requirements, the more l= ikely it is we can get what we need. So it might well be that a hardware mo= dule only supported the Edwards or the Montgomery curves and applications w= ere required to use the isomorphisms to map from one to the other.


=
Two decades after I first attended my first (a= nd last) 'Trusted Computing' WG meeting, deployment of the original= TPM model is no closer. I suspect that a great deal of the opposition to T= PMs was cleverly orchestrated to discourage proliferation of effective stro= ng cryptography (the $250 million/yr on BULLRUN obviously went somewhere). = But regardless, the achilles heel of that scheme was and is the need for a = physical token (SIM card / TPM) to effect device portability.=C2=A0

The thres= hold models I have developed allow those restrictions to be avoided. Alice = can deploy keys to all her devices that allow them to encrypt, authenticate= and sign and retain the ability to recover data from a broken machine, por= t data between her machines etc. without the need for the crypto processor = to be on a pluggable daughter board.

=
The only real limitations of this model = come from conflicting requirements. I cannot design a key recovery system t= hat only works when the 'good guys' are using it.
--000000000000044a4b059b8d84d1-- From nobody Tue Jan 7 07:23:15 2020 Return-Path: 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 677FD120059 for ; Tue, 7 Jan 2020 07:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 87wpBx7KXYvH for ; Tue, 7 Jan 2020 07:23:11 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C5BF120052 for ; Tue, 7 Jan 2020 07:23:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 495F8300B36 for ; Tue, 7 Jan 2020 10:23:09 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id oK5_wjBHo1Dl for ; Tue, 7 Jan 2020 10:23:08 -0500 (EST) Received: from [5.5.33.11] (unknown [204.194.23.17]) by mail.smeinc.net (Postfix) with ESMTPSA id 1F911300B04 for ; Tue, 7 Jan 2020 10:23:08 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Tue, 7 Jan 2020 10:23:08 -0500 To: IETF SAAG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [saag] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 15:23:13 -0000 https://eprint.iacr.org/2020/014 > SHA-1 is a Shambles - First Chosen-Prefix Collision on SHA-1 and > Application to the PGP Web of Trust >=20 > Ga=C3=ABtan Leurent and Thomas Peyrin >=20 > Abstract: The SHA-1 hash function was designed in 1995 and has been > widely used during two decades. A theoretical collision attack was = first > proposed in 2004 [WYY05], but due to its high complexity it was only > implemented in practice in 2017, using a large GPU cluster [SBK+17]. > More recently, an almost practical chosen-prefix collision attack > against SHA-1 has been proposed [LP19]. This more powerful attack = allows > to build colliding messages with two arbitrary prefixes, which is much > more threatening for real protocols. >=20 > In this paper, we report the first practical implementation of this > attack, and its impact on real-world security with a PGP/GnuPG > impersonation attack. We managed to significantly reduce the = complexity > of collisions attack against SHA-1: on an Nvidia GTX 970, > identical-prefix collisions can now be computed with a complexity of > 2^61.2 rather than 2^64.7, and chosen-prefix collisions with a = complexity > of 2^63.4 rather than 2^67.1. When renting cheap GPUs, this translates = to > a cost of 11k US$ for a collision, and 45k US$ for a chosen-prefix > collision, within the means of academic researchers. Our actual attack > required two months of computations using 900 Nvidia GTX 1060 GPUs (we > paid 75k US$ because GPU prices were higher, and we wasted some time > preparing the attack). >=20 > Therefore, the same attacks that have been practical on MD5 since 2009 > are now practical on SHA-1. In particular, chosen-prefix collisions = can > break signature schemes and handshake security in secure channel > protocols (TLS, SSH). We strongly advise to remove SHA-1 from those = type > of applications as soon as possible. We exemplify our cryptanalysis by > creating a pair of PGP/GnuPG keys with different identities, but > colliding SHA-1 certificates. A SHA-1 certification of the first key = can > therefore be transferred to the second key, leading to a forgery. This > proves that SHA-1 signatures now offers virtually no security in > practice. The legacy branch of GnuPG still uses SHA-1 by default for > identity certifications, but after notifying the authors, the modern > branch now rejects SHA-1 signatures (the issue is tracked as > CVE-2019-14855). From nobody Tue Jan 7 10:53:50 2020 Return-Path: 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 CCB2012010E for ; Tue, 7 Jan 2020 10:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 7UuKZ-H7C-yF for ; Tue, 7 Jan 2020 10:53:47 -0800 (PST) Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) (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 E6357120145 for ; Tue, 7 Jan 2020 10:53:46 -0800 (PST) Received: by mail-oi1-f175.google.com with SMTP id l9so382860oii.5 for ; Tue, 07 Jan 2020 10:53:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3nedsFlXDq4obx1qqSaeL8hzGOzqR5XQlSj5XHtgMVM=; b=Yz4y9o4GjcqZ53RIRfwoaUUpMSEYmuTozN4liPK1boF1yA9mkaLjDvLI4pfdLEsFv6 S9k51jrpF5iHct1ujVA1JjMaromodhNpx2JxMJ/3u8iR9jZWTyZqXQ8LiJ/rKVzywsc/ MjQsVoH6VNwxXs+JaGrs12FSm6A26kJkXR0SvI+UmDXoGBPoCVbdra9tWe71SLi0/6lt 3EU3oo2+4152EwcR1qFw9hfB/nN1JamZfiCOceVlZmYIUnCQ01HLSvnAKdnahovoD9m+ zNy5y7uVLl9jM7ji26r3hsrYxv5Fq7PLUGdhFyvvybfr0DpRPHtFnQ41jKxLTwfnqZmp 5HbQ== X-Gm-Message-State: APjAAAVnk/9Z3bixy/B0NvitSjVqr5JiFZUUjymqoK5ia95Y8fng+IF/ 8bRR+md4lF4o82ceMfrsaUqqa5GpACv+KBzo9gLOxFYtDL0= X-Google-Smtp-Source: APXvYqyr7RkKQzdFGgSU1rYbgfrXVPvFyVBBqNuSqEMOMuLhhOI/EYqYRJIAR/OIstbuAlJzigett7I0pr4lVjfZ+ik= X-Received: by 2002:aca:cdd6:: with SMTP id d205mr686879oig.90.1578423225955; Tue, 07 Jan 2020 10:53:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Tue, 7 Jan 2020 13:53:37 -0500 Message-ID: To: Russ Housley Cc: IETF SAAG Content-Type: multipart/alternative; boundary="000000000000b03d55059b914ba1" Archived-At: Subject: Re: [saag] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 18:53:49 -0000 --000000000000b03d55059b914ba1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I was just about to post. As it happens, I was in the middle of making an intro video on digest functions for my free course on crypto. So I guess I will tape it today rather than waiting till Friday (if the heavy equipment laying new gas pipes in the street is quiet enough). The need to move on from SHA-1 was one of the reasons I originally started looking at an improved fingerprint presentation using Base32 encoding that allowed for safe truncation etc. SHA-1 has more than enough bits for many applications, the problem is the algorithm. I would like to move to SHA-2-512/ SHA-3-512 and only 512 bits regardless of the precision required= . https://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html On Tue, Jan 7, 2020 at 10:23 AM Russ Housley wrote: > https://eprint.iacr.org/2020/014 > > > SHA-1 is a Shambles - First Chosen-Prefix Collision on SHA-1 and > > Application to the PGP Web of Trust > > > > Ga=C3=ABtan Leurent and Thomas Peyrin > > > > Abstract: The SHA-1 hash function was designed in 1995 and has been > > widely used during two decades. A theoretical collision attack was firs= t > > proposed in 2004 [WYY05], but due to its high complexity it was only > > implemented in practice in 2017, using a large GPU cluster [SBK+17]. > > More recently, an almost practical chosen-prefix collision attack > > against SHA-1 has been proposed [LP19]. This more powerful attack allow= s > > to build colliding messages with two arbitrary prefixes, which is much > > more threatening for real protocols. > > > > In this paper, we report the first practical implementation of this > > attack, and its impact on real-world security with a PGP/GnuPG > > impersonation attack. We managed to significantly reduce the complexity > > of collisions attack against SHA-1: on an Nvidia GTX 970, > > identical-prefix collisions can now be computed with a complexity of > > 2^61.2 rather than 2^64.7, and chosen-prefix collisions with a complexi= ty > > of 2^63.4 rather than 2^67.1. When renting cheap GPUs, this translates = to > > a cost of 11k US$ for a collision, and 45k US$ for a chosen-prefix > > collision, within the means of academic researchers. Our actual attack > > required two months of computations using 900 Nvidia GTX 1060 GPUs (we > > paid 75k US$ because GPU prices were higher, and we wasted some time > > preparing the attack). > > > > Therefore, the same attacks that have been practical on MD5 since 2009 > > are now practical on SHA-1. In particular, chosen-prefix collisions can > > break signature schemes and handshake security in secure channel > > protocols (TLS, SSH). We strongly advise to remove SHA-1 from those typ= e > > of applications as soon as possible. We exemplify our cryptanalysis by > > creating a pair of PGP/GnuPG keys with different identities, but > > colliding SHA-1 certificates. A SHA-1 certification of the first key ca= n > > therefore be transferred to the second key, leading to a forgery. This > > proves that SHA-1 signatures now offers virtually no security in > > practice. The legacy branch of GnuPG still uses SHA-1 by default for > > identity certifications, but after notifying the authors, the modern > > branch now rejects SHA-1 signatures (the issue is tracked as > > CVE-2019-14855). > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --000000000000b03d55059b914ba1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I w= as just about to post. As it happens, I was in the middle of making an intr= o video on digest functions for my free course on crypto. So I guess I will= tape it today rather than waiting till Friday (if the heavy equipment layi= ng new gas pipes in the street is quiet enough).

The need to move on from SHA-1 was one of the reaso= ns I originally started looking at an improved fingerprint presentation usi= ng Base32 encoding that allowed for safe=C2=A0truncation etc. SHA-1 has mor= e than enough bits for many applications, the problem is the algorithm. I w= ould like to move to SHA-2-512/ SHA-3-512 and only 512 bits regardless of the precision required.


https://mathmesh.com/Documents/draf= t-hallambaker-mesh-udf.html=C2=A0=C2=A0=C2=A0


On Tue, Jan 7, 2020 at 10:= 23 AM Russ Housley <housley@vigi= lsec.com> wrote:
https://eprint.iacr.org/2020/014

> SHA-1 is a Shambles - First Chosen-Prefix Collision on SHA-1 and
> Application to the PGP Web of Trust
>
> Ga=C3=ABtan Leurent and Thomas Peyrin
>
> Abstract: The SHA-1 hash function was designed in 1995 and has been > widely used during two decades. A theoretical collision attack was fir= st
> proposed in 2004 [WYY05], but due to its high complexity it was only > implemented in practice in 2017, using a large GPU cluster [SBK+17]. > More recently, an almost practical chosen-prefix collision attack
> against SHA-1 has been proposed [LP19]. This more powerful attack allo= ws
> to build colliding messages with two arbitrary prefixes, which is much=
> more threatening for real protocols.
>
> In this paper, we report the first practical implementation of this > attack, and its impact on real-world security with a PGP/GnuPG
> impersonation attack. We managed to significantly reduce the complexit= y
> of collisions attack against SHA-1: on an Nvidia GTX 970,
> identical-prefix collisions can now be computed with a complexity of > 2^61.2 rather than 2^64.7, and chosen-prefix collisions with a complex= ity
> of 2^63.4 rather than 2^67.1. When renting cheap GPUs, this translates= to
> a cost of 11k US$ for a collision, and 45k US$ for a chosen-prefix
> collision, within the means of academic researchers. Our actual attack=
> required two months of computations using 900 Nvidia GTX 1060 GPUs (we=
> paid 75k US$ because GPU prices were higher, and we wasted some time > preparing the attack).
>
> Therefore, the same attacks that have been practical on MD5 since 2009=
> are now practical on SHA-1. In particular, chosen-prefix collisions ca= n
> break signature schemes and handshake security in secure channel
> protocols (TLS, SSH). We strongly advise to remove SHA-1 from those ty= pe
> of applications as soon as possible. We exemplify our cryptanalysis by=
> creating a pair of PGP/GnuPG keys with different identities, but
> colliding SHA-1 certificates. A SHA-1 certification of the first key c= an
> therefore be transferred to the second key, leading to a forgery. This=
> proves that SHA-1 signatures now offers virtually no security in
> practice. The legacy branch of GnuPG still uses SHA-1 by default for > identity certifications, but after notifying the authors, the modern > branch now rejects SHA-1 signatures (the issue is tracked as
> CVE-2019-14855).

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
--000000000000b03d55059b914ba1-- From nobody Tue Jan 7 16:06:05 2020 Return-Path: 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 EFBAD120018 for ; Tue, 7 Jan 2020 16:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 WiSYFFoq9uy3 for ; Tue, 7 Jan 2020 16:06:01 -0800 (PST) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 D8DAC120025 for ; Tue, 7 Jan 2020 16:05:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1578441961; x=1609977961; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=oWPFD5Aunw9/aWEyFV1oCngd/6kp6r25fyQjgVptbOA=; b=wo9vHOyzlwdh+VJGKLUC+I88TmrwG+iGGTvhZkSRKHoMSbmXyjWYJoRp y4Utasn+RvKF91rjiFKJEiy0RgVbgHOCHEddaWjOqYwtSKX9X04Kj6//q 8DOU6wuDV3W4UGlqU1b90xKog8rG87y4qGZdBVVnYgtlo2Ow/uUWwK/j5 jdtBfKnisov0H21e4PhhLnAor4YaXW3tpepa51TkoyVFzmD5mpQBCYa1D UckXdjLu2SuOstF0Tq/jA7IG7pNHz5/Fq9H75ytV3Ilo2KKiIreOe/2kG /RzUrRgELHg+EQsK3wp/LxqNRZ3YAO6ZcNlLlNwnJSq/FkLi8UQNxzHAd A==; X-IronPort-AV: E=Sophos;i="5.69,407,1571655600"; d="scan'208";a="108677200" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.5 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-d.UoA.auckland.ac.nz) ([10.6.3.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Jan 2020 13:05:57 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 8 Jan 2020 13:05:57 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Wed, 8 Jan 2020 13:05:57 +1300 From: Peter Gutmann To: Russ Housley , IETF SAAG Thread-Topic: [saag] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 Thread-Index: AQHVxW5peik3PNqOuEiM4/T+DmGoNqff4y66 Date: Wed, 8 Jan 2020 00:05:57 +0000 Message-ID: <1578441957793.93047@cs.auckland.ac.nz> References: In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 00:06:04 -0000 Russ Housley writes:=0A= =0A= >https://eprint.iacr.org/2020/014=0A= >=0A= > SHA-1 is a Shambles - First Chosen-Prefix Collision on SHA-1 and=0A= > Application to the PGP Web of Trust=0A= =0A= I'd commented on this on the cryptography list, my thoughts were:=0A= =0A= -- Snip --=0A= =0A= An interesting paper has just appeared on the IACR e-print archive:=0A= =0A= SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and Applicati= on to=0A= the PGP Web of Trust=0A= =0A= https://eprint.iacr.org/2020/014.pdf=0A= =0A= tl;dr: Attacks sped up by a factor of ~16 over previous work, chosen-prefix= =0A= collision for ~$75k and 2 months effort.=0A= =0A= It's a long (32 pages) but interesting read. The only thing I have a bit o= f=0A= an issue with is the conclusion:=0A= =0A= SHA-1 signatures now offers virtually no security in practice=0A= =0A= It should really be "SHA-1 signatures where the attacker has two months tim= e=0A= and tens of thousands of dollars (there are some cheaper options than $75k)= to=0A= prepare a forgery offer no security in practice".=0A= =0A= Even then, the demonstrated attack relies on the ability to stuff arbitrary= =0A= garbage data into the signed message (in this case into a JPEG image after = the=0A= End-of-Image marker), so add:=0A= =0A= "... and the ability to stuff arbitrary attacker-chosen data into the sig= ned=0A= message..."=0A= =0A= to that.=0A= =0A= Not trying to downplay the findings in the paper, but more to provide some= =0A= perspective on where the major risks lie for people who need to think about= =0A= the use of SHA-1 in legacy products and systems.=0A= From nobody Tue Jan 7 16:29:36 2020 Return-Path: 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 9A666120018 for ; Tue, 7 Jan 2020 16:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.416 X-Spam-Level: X-Spam-Status: No, score=-1.416 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 u0ORhd1z1G_s for ; Tue, 7 Jan 2020 16:29:33 -0800 (PST) Received: from mail-ot1-f68.google.com (mail-ot1-f68.google.com [209.85.210.68]) (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 0B168120020 for ; Tue, 7 Jan 2020 16:29:33 -0800 (PST) Received: by mail-ot1-f68.google.com with SMTP id i15so1930048oto.2 for ; Tue, 07 Jan 2020 16:29:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BDDNOoU/flR7Ymxyfzz35swxxKyP59/MFv1lQ2VNjQY=; b=IYsGEwowNcBlBelG6SBWRHb0FTpW2Vfa+blY43fYh+JcwbGT97XpXPf9o2229UOVn/ ic5wf3UCO7uCMPzZU66INfHm9lwBPSpiex1y2IVZTxp3YD/Z3WR4kF3DOEAbQ1i+7XHe eEcyVH8/zZbB9Rcd6CEL5V005S3xwih283HgeESulyOghoVHm+Ct3i4EPu0r82YN6pZY vtzkXYbVZ8a1CoaY6w4K++ZDdXE+FGGROnccFKbPfZqSUo70OBXdzkbOK6j6CYehgcjY DthhFhn9JAl6VEoWg2/BLzbDIg45z9JoNtM/VtQX721Z0/0XSdY+YMugySgMWwPOU09B m6LQ== X-Gm-Message-State: APjAAAWaXSEmOB33x5uEeuti1XMiPuM+9oEUgQR/vJubUHiOFSwrrE+4 M9UF7iQuH6xD5mmkD8b5A9vl7AhUsmt/OPeOHhY= X-Google-Smtp-Source: APXvYqybmLl3LCz0ThCPRTqIYj6PHmFsbKlCdcfK6KOxpGuR8M+9j2jHPqn0j5suwE7OIF5TQFp6/diW1q2Abq8pxcw= X-Received: by 2002:a05:6830:1481:: with SMTP id s1mr2252924otq.66.1578443372235; Tue, 07 Jan 2020 16:29:32 -0800 (PST) MIME-Version: 1.0 References: <1578441957793.93047@cs.auckland.ac.nz> In-Reply-To: <1578441957793.93047@cs.auckland.ac.nz> From: Phillip Hallam-Baker Date: Tue, 7 Jan 2020 19:29:20 -0500 Message-ID: To: Peter Gutmann Cc: Russ Housley , IETF SAAG Content-Type: multipart/alternative; boundary="000000000000801bca059b95fcff" Archived-At: Subject: Re: [saag] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 00:29:34 -0000 --000000000000801bca059b95fcff Content-Type: text/plain; charset="UTF-8" On Tue, Jan 7, 2020 at 7:06 PM Peter Gutmann wrote: > Russ Housley writes: > > >https://eprint.iacr.org/2020/014 > > > > SHA-1 is a Shambles - First Chosen-Prefix Collision on SHA-1 and > > Application to the PGP Web of Trust > > I'd commented on this on the cryptography list, my thoughts were: > > -- Snip -- > > An interesting paper has just appeared on the IACR e-print archive: > > SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and > Application to > the PGP Web of Trust > > https://eprint.iacr.org/2020/014.pdf > > tl;dr: Attacks sped up by a factor of ~16 over previous work, chosen-prefix > collision for ~$75k and 2 months effort. > > It's a long (32 pages) but interesting read. The only thing I have a bit > of > an issue with is the conclusion: > > SHA-1 signatures now offers virtually no security in practice > > It should really be "SHA-1 signatures where the attacker has two months > time > and tens of thousands of dollars (there are some cheaper options than > $75k) to > prepare a forgery offer no security in practice". > I think we can be fairly clear what the real risk is going to be and I am working on this in the podcast (could not record it today because there were roadworks outside the studio). What will happen is * Short term panic and lots of people explaining there is nothing to worry about. * Five to ten years of complacency. * A successful attack on a significant target that did not transition but proved profitable. $75K will be $5K before long and don't discount the possibility that $75K could be a profitable attack. I am sure that organized crime has noted the Lehman etc insider trading frauds and started planting moles in the banks. $75K would be nothing when they are looking to cash out $100 million. We have observed very significant amounts being paid for zero day attacks. Most likely attack targets will be Git repos and similar applications using SHA-1 hashes internally. The Git project did raise itself from the usual security negligence Torvalds projects suffer from. The IPv6 buffer overrun guards he stripped out of the kernel because he didn't understand them in his 'compiler masturbation' rant is a more likely source of security breach. It speaks of a hostile work environment. --000000000000801bca059b95fcff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jan 7, 2020 at 7:06 PM Peter Gutmann <pgut001@cs.auckland.ac.nz>= ; wrote:
Russ Ho= usley <housley= @vigilsec.com> writes:

>https://eprint.iacr.org/2020/014
>
> SHA-1 is a Shambles - First Chosen-Prefix Collision on SHA-1 and
> Application to the PGP Web of Trust

I'd commented on this on the cryptography list, my thoughts were:

-- Snip --

An interesting paper has just appeared on the IACR e-print archive:

=C2=A0 SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and Appl= ication to
=C2=A0 the PGP Web of Trust

=C2=A0 https://eprint.iacr.org/2020/014.pdf

tl;dr: Attacks sped up by a factor of ~16 over previous work, chosen-prefix=
collision for ~$75k and 2 months effort.

It's a long (32 pages) but interesting read.=C2=A0 The only thing I hav= e a bit of
an issue with is the conclusion:

=C2=A0 SHA-1 signatures now offers virtually no security in practice

It should really be "SHA-1 signatures where the attacker has two month= s time
and tens of thousands of dollars (there are some cheaper options than $75k)= to
prepare a forgery offer no security in practice".

I th= ink we can be fairly clear what the real risk is going to be and I am worki= ng on this in the podcast (could not record it today because there were roa= dworks outside the studio).

What will happen is

* Short term panic and lots of people explaining there is= nothing to worry about.
* Five to ten years of complacency.
* A successful attack on a significant targe= t that did not transition but proved profitable.

$75K will be $5K before long and don't discount= the possibility that $75K could be a profitable attack. I am sure that org= anized crime has noted the Lehman etc insider trading frauds and started pl= anting moles in the banks. $75K would be nothing when they are looking to c= ash out $100 million. We have observed very significant amounts being paid = for zero day attacks.

Most likely attack targets will be Git repos and = similar applications using SHA-1 hashes internally. The Git project did rai= se itself from the usual security negligence Torvalds projects suffer from.= The=C2=A0IPv6 buffer overrun guards he stripped out of the kernel because = he didn't understand them in his 'compiler masturbation' rant i= s a more likely source of security breach. It speaks of a hostile work envi= ronment.
--000000000000801bca059b95fcff-- From nobody Tue Jan 7 17:42:48 2020 Return-Path: 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 0D7CA12081A for ; Tue, 7 Jan 2020 17:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 488Odj2FQCWD for ; Tue, 7 Jan 2020 17:42:44 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 90C94120854 for ; Tue, 7 Jan 2020 17:42:44 -0800 (PST) Received: from xse313.mail2web.com ([66.113.197.59] helo=xse.mail2web.com) by mx66.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1ip0Ms-00025H-0f for saag@ietf.org; Wed, 08 Jan 2020 02:42:42 +0100 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 47ssSc1xHHzC0h for ; Tue, 7 Jan 2020 17:42:40 -0800 (PST) Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1ip0Mq-0007Tc-4u for saag@ietf.org; Tue, 07 Jan 2020 17:42:40 -0800 Received: (qmail 15118 invoked from network); 8 Jan 2020 01:35:58 -0000 Received: from unknown (HELO [192.168.200.66]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 8 Jan 2020 01:35:57 -0000 To: Phillip Hallam-Baker , Peter Gutmann Cc: IETF SAAG References: <1578441957793.93047@cs.auckland.ac.nz> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Tue, 7 Jan 2020 15:35:56 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: 66.113.197.59 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0c2Pj46HODYmpAMVAv0J1pOpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDRitNmXY60Gx0fFyUeQSRQrgN zB/4Jkrw1eDLcif59ftCytnD4F7p8vKydxS5yRcFU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+5aB4itzNZ07CdqP+KMfGjQX2XX9bIsGDSYq5OAASmskY6jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhLSQQ4vSj0QEim26t/Moy0UPX5E73H1QfrH/5kkrV/Cr0bm2vWdo8usP65i82q1C dZgGrpL44wdx9eXqjQjbvUopOMQJvQ/Ck3iiU+4DQAj3fuQgzT3K9JUHTNiGwfwAm3OZmI6+6AcH EU4XbMnrDapXSV0lPHjGZLkASD9YtLp9Owwu37/TJiSPbLp/BALdyXQvzT/Dr4t81AnLRqTQR/Qv UwPy3x0FYtCNEb10sHyQCLHEvD1OqP6bgZ4L66GcgBg66gs5OuzYxJgw5atIxeNDvjI/CYe5WPy0 +t1RP0az9y/nT96fIA7QiNDTYvO3LZxMPnetLBJMh51NiRRoHIC75/eaRypCVt5y9BJJReoYmiK7 x42VjdzChZMe6O/DiWiiIzuXMTE3l4bIsk+O50vjK3mw1OSjSFpX3z5HGUXW08QV3No+S2msRDep v5w/kkG0v17AmegcpQ0tml/sN9lmMy/o83jVXTcfb9k0nLWblJy7uxV6dw8jzlsaNZe6hynMJcjx DydxsJEju76A7X1QIVydqXpZ6MHhiKws9Iiut28r9wo4SqUIg8Yh9hAM0n3LLzx/F2gT3wl8JQJv Bho= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [saag] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 01:42:47 -0000 On 1/7/2020 2:29 PM, Phillip Hallam-Baker wrote: > $75K will be $5K before long and don't discount the possibility that > $75K could be a profitable attack. I am sure that organized crime has > noted the Lehman etc insider trading frauds and started planting moles > in the banks. $75K would be nothing when they are looking to cash out > $100 million. We have observed very significant amounts being paid for > zero day attacks. The paper explains that the actual cost of the attack is $11K, and that the $75K was spent because of trials and errors tuning the attack. Also, they apparently bought the capacity at retail price. So, yes, probably close to $5K already for a capable adversary. Not to mention a botnet with access to a bunch of GPUs. -- Christian Huitema From nobody Tue Jan 7 17:46:24 2020 Return-Path: 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 148D51200D6 for ; Tue, 7 Jan 2020 17:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 Kw1Fzn3I0MVz for ; Tue, 7 Jan 2020 17:46:20 -0800 (PST) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 052D412007C for ; Tue, 7 Jan 2020 17:46:20 -0800 (PST) Received: by mail-il1-x12c.google.com with SMTP id v15so1354414iln.0 for ; Tue, 07 Jan 2020 17:46:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=9MRV/kbm752ezSTC5y9YzdEbiapz9dz2VwkcotwoEmU=; b=Nb4Ve8rbZO0YxVCMVJRgG/OSxzQo/O5eQg8kaEaCoDmRbW7zOp8oenq0ZDyhB8oD1M s4ps2BqKLnTGsVScJScaPvRx0ZFV+4LEQ1AEI1IKpIZo5TCNh0nonMYvEHqPYtMs6k0F RO/zjRuOcIswXYLtdtYIHoGQQosjEcOZb0Xb9e1am6WyninH383c1phjjy5YIh4CUeue vbKVTDWvyoT0TTjDZuoheJtlYgFq5fGFsH+Xs/DVJWWoFDC9qKE59Jb5Mt+j92TMXw++ iSnmuuUblsAkokqf0VvjKp2kEdN0F4N/K86LnNF25X5jr8ySoqa5MncW+jRiQOjqGfl7 r7xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=9MRV/kbm752ezSTC5y9YzdEbiapz9dz2VwkcotwoEmU=; b=mfRhOw1lA+7UOvAVzTvgtbnkexCasCMELnscIARSDv6/q7tFNMj88Ybwdq35CQrSKd 3uzDKc7EB8d8OFIqutANBaCacNa3QmJwjDVivtB9/iknwDPUDboqjfz8mhoOMPA3OVAa Hz6mSEdF6qp56EcdDeHT9WQ+3j43sfRayZ7sqHA1MGa1F0Em38ehFIGaV7jUu4HeUFRb 5e3+Sh/2SPayx6wt+esexNILhwnsIMfihOjPzQzyRK6J4B6IicYy6nHLLu50G/DECnni dD6Co6zqQdR+7My2IKWh3BGBRvVx+oj1zB8c5y5QNK6LFm/MeqMZIWXJdLugdfEsk7a3 T9bw== X-Gm-Message-State: APjAAAVptqULG2X/ROcwXtcGSmvO5/x4/Ar9w5SOiivXs7XlypOktNmw 6U5MsFQCOhnmI+jTEE1OfbcrOQ0A6Dp4nvsDw1QZgq6W3NU= X-Google-Smtp-Source: APXvYqxD4xSV3BS6WkVUJ8R36m697joWXCEEqPeo/LLwJcv2/pUmvwvht6rc6HhQwJEmilXlq/x7d+vUKKzyU3s73bE= X-Received: by 2002:a92:8dda:: with SMTP id w87mr1866655ill.55.1578447979347; Tue, 07 Jan 2020 17:46:19 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Reply-To: noloader@gmail.com From: Jeffrey Walton Date: Tue, 7 Jan 2020 20:46:01 -0500 Message-ID: To: Russ Housley Cc: IETF SAAG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 01:46:22 -0000 On Tue, Jan 7, 2020 at 10:23 AM Russ Housley wrote: > > https://eprint.iacr.org/2020/014 > > > SHA-1 is a Shambles - First Chosen-Prefix Collision on SHA-1 and > > Application to the PGP Web of Trust > > > > Ga=C3=ABtan Leurent and Thomas Peyrin > > > > Abstract: The SHA-1 hash function was designed in 1995 and has been > > widely used during two decades. A theoretical collision attack was firs= t > > proposed in 2004 [WYY05], but due to its high complexity it was only > > implemented in practice in 2017, using a large GPU cluster [SBK+17]. > > More recently, an almost practical chosen-prefix collision attack > > against SHA-1 has been proposed [LP19]. This more powerful attack allow= s > > to build colliding messages with two arbitrary prefixes, which is much > > more threatening for real protocols. > > > > In this paper, we report the first practical implementation of this > > attack, and its impact on real-world security with a PGP/GnuPG > > impersonation attack. We managed to significantly reduce the complexity > > of collisions attack against SHA-1: on an Nvidia GTX 970, > > identical-prefix collisions can now be computed with a complexity of > > 2^61.2 rather than 2^64.7, and chosen-prefix collisions with a complexi= ty > > of 2^63.4 rather than 2^67.1. When renting cheap GPUs, this translates = to > > a cost of 11k US$ for a collision, and 45k US$ for a chosen-prefix > > collision, within the means of academic researchers. Our actual attack > > required two months of computations using 900 Nvidia GTX 1060 GPUs (we > > paid 75k US$ because GPU prices were higher, and we wasted some time > > preparing the attack). > > > > Therefore, the same attacks that have been practical on MD5 since 2009 > > are now practical on SHA-1. In particular, chosen-prefix collisions can > > break signature schemes and handshake security in secure channel > > protocols (TLS, SSH). We strongly advise to remove SHA-1 from those typ= e > > of applications as soon as possible. We exemplify our cryptanalysis by > > creating a pair of PGP/GnuPG keys with different identities, but > > colliding SHA-1 certificates. A SHA-1 certification of the first key ca= n > > therefore be transferred to the second key, leading to a forgery. This > > proves that SHA-1 signatures now offers virtually no security in > > practice. The legacy branch of GnuPG still uses SHA-1 by default for > > identity certifications, but after notifying the authors, the modern > > branch now rejects SHA-1 signatures (the issue is tracked as > > CVE-2019-14855). And if interested, Mozilla's cacert.pem (https://curl.haxx.se/docs/caextract.html) has 52 certificates at risk: $ ./test.exe Load certificates from cacert.pem Certificates total: 138 ecdsa-with-SHA256: 5 ecdsa-with-SHA384: 16 id_sha1WithRSASignature: 52 id_sha256WithRSAEncryption: 56 id_sha256WithRSAEncryption: 8 id_sha512WithRSAEncryption: 1 Jeff From nobody Tue Jan 7 17:49:35 2020 Return-Path: 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 446B41200D6 for ; Tue, 7 Jan 2020 17:49:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ButDE4GuRtLN for ; Tue, 7 Jan 2020 17:49:32 -0800 (PST) Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) (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 2898712007C for ; Tue, 7 Jan 2020 17:49:32 -0800 (PST) Received: by mail-oi1-f178.google.com with SMTP id k4so1334745oik.2 for ; Tue, 07 Jan 2020 17:49:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9EmrldiPCM8xRPz+SCMhS5qbs1VEfUvE+125gZ/vhDM=; b=ndnIgpdBPBCJBYLq/oIysRBGtt8oHPgFH8MbvpiJlcWdEDp+VAJTW/A/bKoymJ5nK8 pB5SKzpFjIPy9abhKJNgDLF8H8a/jyPZpJG744BnVg2i6qFWQ804MsUDAcPQWOGP1QZ1 XSCa4NGF6nW0wUJqgVdQ8McRusEZG8HPzcVDHlbRXADXaLk36fNH+Mh1kKJgj9HGw1bM D8qZH8lR8SOPOCmrNqzM3l2zwlkumPRSZKwoIoFQ4KpbnkXG4zG2yFwGSmVNzaetvflR a7bxGwTztsDD+E0KImYfh4yO528LIF9Xip9IKmeK9YQ1O9Nx35SlCC639AyV/lrw/MLW WPXw== X-Gm-Message-State: APjAAAVLPMuA2wPrL6W/epd/z8yQ/FgS4iun8Rp8GcLsnOMrvDfrhmg1 LnUNfO2LYb1dLlWWpabbv7wnWqSx497Z59s3snM= X-Google-Smtp-Source: APXvYqz/Lw8ogPRsOggCbTGswC9wdwGYUxIsyK3+waUIuL0/cwAyInXMF3y8fv3+1i79qia+Kl1qYqXogdUj9mRo5+s= X-Received: by 2002:aca:3241:: with SMTP id y62mr1194032oiy.31.1578448171417; Tue, 07 Jan 2020 17:49:31 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Tue, 7 Jan 2020 20:49:20 -0500 Message-ID: To: noloader@gmail.com Cc: Russ Housley , IETF SAAG Content-Type: multipart/alternative; boundary="0000000000008dc3ad059b971a5e" Archived-At: Subject: Re: [saag] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 01:49:34 -0000 --0000000000008dc3ad059b971a5e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Those certificates are not actually at risk because they were originally signed when SHA-1 was still trusted. It is the intermediate and EE certs that are the concern. On the cost of attack thing. $11K is well within the amount of computer time that can be stolen... On Tue, Jan 7, 2020 at 8:46 PM Jeffrey Walton wrote: > On Tue, Jan 7, 2020 at 10:23 AM Russ Housley wrote= : > > > > https://eprint.iacr.org/2020/014 > > > > > SHA-1 is a Shambles - First Chosen-Prefix Collision on SHA-1 and > > > Application to the PGP Web of Trust > > > > > > Ga=C3=ABtan Leurent and Thomas Peyrin > > > > > > Abstract: The SHA-1 hash function was designed in 1995 and has been > > > widely used during two decades. A theoretical collision attack was > first > > > proposed in 2004 [WYY05], but due to its high complexity it was only > > > implemented in practice in 2017, using a large GPU cluster [SBK+17]. > > > More recently, an almost practical chosen-prefix collision attack > > > against SHA-1 has been proposed [LP19]. This more powerful attack > allows > > > to build colliding messages with two arbitrary prefixes, which is muc= h > > > more threatening for real protocols. > > > > > > In this paper, we report the first practical implementation of this > > > attack, and its impact on real-world security with a PGP/GnuPG > > > impersonation attack. We managed to significantly reduce the complexi= ty > > > of collisions attack against SHA-1: on an Nvidia GTX 970, > > > identical-prefix collisions can now be computed with a complexity of > > > 2^61.2 rather than 2^64.7, and chosen-prefix collisions with a > complexity > > > of 2^63.4 rather than 2^67.1. When renting cheap GPUs, this translate= s > to > > > a cost of 11k US$ for a collision, and 45k US$ for a chosen-prefix > > > collision, within the means of academic researchers. Our actual attac= k > > > required two months of computations using 900 Nvidia GTX 1060 GPUs (w= e > > > paid 75k US$ because GPU prices were higher, and we wasted some time > > > preparing the attack). > > > > > > Therefore, the same attacks that have been practical on MD5 since 200= 9 > > > are now practical on SHA-1. In particular, chosen-prefix collisions c= an > > > break signature schemes and handshake security in secure channel > > > protocols (TLS, SSH). We strongly advise to remove SHA-1 from those > type > > > of applications as soon as possible. We exemplify our cryptanalysis b= y > > > creating a pair of PGP/GnuPG keys with different identities, but > > > colliding SHA-1 certificates. A SHA-1 certification of the first key > can > > > therefore be transferred to the second key, leading to a forgery. Thi= s > > > proves that SHA-1 signatures now offers virtually no security in > > > practice. The legacy branch of GnuPG still uses SHA-1 by default for > > > identity certifications, but after notifying the authors, the modern > > > branch now rejects SHA-1 signatures (the issue is tracked as > > > CVE-2019-14855). > > And if interested, Mozilla's cacert.pem > (https://curl.haxx.se/docs/caextract.html) has 52 certificates at > risk: > > $ ./test.exe > Load certificates from cacert.pem > Certificates total: 138 > > ecdsa-with-SHA256: 5 > ecdsa-with-SHA384: 16 > id_sha1WithRSASignature: 52 > id_sha256WithRSAEncryption: 56 > id_sha256WithRSAEncryption: 8 > id_sha512WithRSAEncryption: 1 > > Jeff > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --0000000000008dc3ad059b971a5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tho= se certificates are not actually at risk because they were originally signe= d when SHA-1 was still trusted. It is the intermediate and EE certs that ar= e the concern.
=
On the cos= t of attack thing. $11K is well within the amount of computer time that can= be stolen...
<= br>

<= div class=3D"gmail_default" style=3D"font-size:small">

<= div class=3D"gmail_quote">
On Tue, Jan= 7, 2020 at 8:46 PM Jeffrey Walton <noloader@gmail.com> wrote:
On Tue, Jan 7, 2020 at 10:23 AM Russ Housley <housley@vigilsec.com> wrote:
>
> https://eprint.iacr.org/2020/014
>
> > SHA-1 is a Shambles - First Chosen-Prefix Collision on SHA-1 and<= br> > > Application to the PGP Web of Trust
> >
> > Ga=C3=ABtan Leurent and Thomas Peyrin
> >
> > Abstract: The SHA-1 hash function was designed in 1995 and has be= en
> > widely used during two decades. A theoretical collision attack wa= s first
> > proposed in 2004 [WYY05], but due to its high complexity it was o= nly
> > implemented in practice in 2017, using a large GPU cluster [SBK+1= 7].
> > More recently, an almost practical chosen-prefix collision attack=
> > against SHA-1 has been proposed [LP19]. This more powerful attack= allows
> > to build colliding messages with two arbitrary prefixes, which is= much
> > more threatening for real protocols.
> >
> > In this paper, we report the first practical implementation of th= is
> > attack, and its impact on real-world security with a PGP/GnuPG > > impersonation attack. We managed to significantly reduce the comp= lexity
> > of collisions attack against SHA-1: on an Nvidia GTX 970,
> > identical-prefix collisions can now be computed with a complexity= of
> > 2^61.2 rather than 2^64.7, and chosen-prefix collisions with a co= mplexity
> > of 2^63.4 rather than 2^67.1. When renting cheap GPUs, this trans= lates to
> > a cost of 11k US$ for a collision, and 45k US$ for a chosen-prefi= x
> > collision, within the means of academic researchers. Our actual a= ttack
> > required two months of computations using 900 Nvidia GTX 1060 GPU= s (we
> > paid 75k US$ because GPU prices were higher, and we wasted some t= ime
> > preparing the attack).
> >
> > Therefore, the same attacks that have been practical on MD5 since= 2009
> > are now practical on SHA-1. In particular, chosen-prefix collisio= ns can
> > break signature schemes and handshake security in secure channel<= br> > > protocols (TLS, SSH). We strongly advise to remove SHA-1 from tho= se type
> > of applications as soon as possible. We exemplify our cryptanalys= is by
> > creating a pair of PGP/GnuPG keys with different identities, but<= br> > > colliding SHA-1 certificates. A SHA-1 certification of the first = key can
> > therefore be transferred to the second key, leading to a forgery.= This
> > proves that SHA-1 signatures now offers virtually no security in<= br> > > practice. The legacy branch of GnuPG still uses SHA-1 by default = for
> > identity certifications, but after notifying the authors, the mod= ern
> > branch now rejects SHA-1 signatures (the issue is tracked as
> > CVE-2019-14855).

And if interested, Mozilla's cacert.pem
(https://curl.haxx.se/docs/caextract.html) has 52 certif= icates at
risk:

$ ./test.exe
Load certificates from cacert.pem
Certificates total: 138

ecdsa-with-SHA256: 5
ecdsa-with-SHA384: 16
id_sha1WithRSASignature: 52
id_sha256WithRSAEncryption: 56
id_sha256WithRSAEncryption: 8
id_sha512WithRSAEncryption: 1

Jeff

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
--0000000000008dc3ad059b971a5e-- From nobody Tue Jan 7 19:18:41 2020 Return-Path: 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 A3E4C120043 for ; Tue, 7 Jan 2020 19:18:39 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 3b0F9LAXJknz for ; Tue, 7 Jan 2020 19:18:36 -0800 (PST) Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) (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 7FD6912002E for ; Tue, 7 Jan 2020 19:18:36 -0800 (PST) Received: by mail-qk1-f174.google.com with SMTP id t129so1424506qke.10 for ; Tue, 07 Jan 2020 19:18:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GucBbzGciWw3pXmyc1OSyVIYq0RzBJOZnW5XVyQn3K4=; b=Sa/+cPjP8u9bymdsqW2hCCKgYunyzLtyo0rMgIUEb5pDLjW90SKLPp98G9g8gpc6t8 wX5odSiXZVQzilp/cmqBEBttMgnwM0dfqqkRnbEoXfLrzewrXw22J9j/fa6syz0l0Ps2 A9Wxnbf+GktWWf5ggTbIIaoaEpumkx9ecZ09H4BKaD6K7NatBFjlPXco9s4VoFQ6Ldye lB2Prmw6ejL/EAkFU0pM7j8iekVZXDFHTJljNwKpIisZbHkNLGJStvHun4Kqs2k/CQg7 15lLUJxjYCB0fvSA6nfKXtkwYIUJVwu+3V+Ltae5rVT5OQGaNASCjcVdVCGYDAnKezlg jE0w== X-Gm-Message-State: APjAAAUG1hGVy2kqvoCnfM9O27F6ntfi5H37HBvzZWoAEb+4OwC8ODRV /ZjYrW5VaudeBFeaKXI5MZ5H8hAKxfYqY8fCcMgrMg== X-Google-Smtp-Source: APXvYqzOSIfZW0LBsT+9+2/Ym68xy3hMS3zX11T7OqFA9TgYnnBvViyhfx9GlByqgUCKUPj6IB3dUcHRptKOR4YEgns= X-Received: by 2002:a05:620a:9c9:: with SMTP id y9mr2300897qky.397.1578453514213; Tue, 07 Jan 2020 19:18:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Andrey Jivsov Date: Tue, 7 Jan 2020 19:18:22 -0800 Message-ID: To: Phillip Hallam-Baker Cc: noloader@gmail.com, IETF SAAG Content-Type: multipart/alternative; boundary="0000000000000274c6059b9859ae" Archived-At: Subject: Re: [saag] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 03:18:40 -0000 --0000000000000274c6059b9859ae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Even more precise, the hash algorithm in X.509 certificate trust anchors doesn't matter for security. Self-signed X.509 certs are the most common trust anchors. If a self-signed cert is a part of a certificate chain, it must be a trust anchor. Therefore, the hash algorithm in a self-signed X.509 certificate never matters for security. This should include compliance reasons of "no SHA-1" because the signature field on self-signed cert should never be verified (we can, but it just wastes compute cycles). Remarkably, the above straightforward facts are for some reason not well-understood and companies make an effort to remove X.509 trust anchors with SHA-1 in signatures over them. On Tue, Jan 7, 2020, 5:49 PM Phillip Hallam-Baker wrote: > Those certificates are not actually at risk because they were originally > signed when SHA-1 was still trusted. It is the intermediate and EE certs > that are the concern. > > On the cost of attack thing. $11K is well within the amount of computer > time that can be stolen... > > > > > On Tue, Jan 7, 2020 at 8:46 PM Jeffrey Walton wrote: > >> On Tue, Jan 7, 2020 at 10:23 AM Russ Housley >> wrote: >> > >> > https://eprint.iacr.org/2020/014 >> > >> > > SHA-1 is a Shambles - First Chosen-Prefix Collision on SHA-1 and >> > > Application to the PGP Web of Trust >> > > >> > > Ga=C3=ABtan Leurent and Thomas Peyrin >> > > >> > > Abstract: The SHA-1 hash function was designed in 1995 and has been >> > > widely used during two decades. A theoretical collision attack was >> first >> > > proposed in 2004 [WYY05], but due to its high complexity it was only >> > > implemented in practice in 2017, using a large GPU cluster [SBK+17]. >> > > More recently, an almost practical chosen-prefix collision attack >> > > against SHA-1 has been proposed [LP19]. This more powerful attack >> allows >> > > to build colliding messages with two arbitrary prefixes, which is mu= ch >> > > more threatening for real protocols. >> > > >> > > In this paper, we report the first practical implementation of this >> > > attack, and its impact on real-world security with a PGP/GnuPG >> > > impersonation attack. We managed to significantly reduce the >> complexity >> > > of collisions attack against SHA-1: on an Nvidia GTX 970, >> > > identical-prefix collisions can now be computed with a complexity of >> > > 2^61.2 rather than 2^64.7, and chosen-prefix collisions with a >> complexity >> > > of 2^63.4 rather than 2^67.1. When renting cheap GPUs, this >> translates to >> > > a cost of 11k US$ for a collision, and 45k US$ for a chosen-prefix >> > > collision, within the means of academic researchers. Our actual atta= ck >> > > required two months of computations using 900 Nvidia GTX 1060 GPUs (= we >> > > paid 75k US$ because GPU prices were higher, and we wasted some time >> > > preparing the attack). >> > > >> > > Therefore, the same attacks that have been practical on MD5 since 20= 09 >> > > are now practical on SHA-1. In particular, chosen-prefix collisions >> can >> > > break signature schemes and handshake security in secure channel >> > > protocols (TLS, SSH). We strongly advise to remove SHA-1 from those >> type >> > > of applications as soon as possible. We exemplify our cryptanalysis = by >> > > creating a pair of PGP/GnuPG keys with different identities, but >> > > colliding SHA-1 certificates. A SHA-1 certification of the first key >> can >> > > therefore be transferred to the second key, leading to a forgery. Th= is >> > > proves that SHA-1 signatures now offers virtually no security in >> > > practice. The legacy branch of GnuPG still uses SHA-1 by default for >> > > identity certifications, but after notifying the authors, the modern >> > > branch now rejects SHA-1 signatures (the issue is tracked as >> > > CVE-2019-14855). >> >> And if interested, Mozilla's cacert.pem >> (https://curl.haxx.se/docs/caextract.html) has 52 certificates at >> risk: >> >> $ ./test.exe >> Load certificates from cacert.pem >> Certificates total: 138 >> >> ecdsa-with-SHA256: 5 >> ecdsa-with-SHA384: 16 >> id_sha1WithRSASignature: 52 >> id_sha256WithRSAEncryption: 56 >> id_sha256WithRSAEncryption: 8 >> id_sha512WithRSAEncryption: 1 >> >> Jeff >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --0000000000000274c6059b9859ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Even more precise, the hash algorithm in X.509 certificat= e trust anchors doesn't matter for security. Self-signed X.509 certs ar= e the most common trust anchors.=C2=A0

If a self-signed cert is a part of a certificate chain, it must b= e a trust anchor. Therefore, the hash algorithm in a self-signed X.509 cert= ificate never matters for security. This should include compliance reasons = of "no SHA-1" because the signature field on self-signed cert sho= uld never be verified (we can, but it just wastes compute cycles).

Remarkably, the above straightfo= rward facts are for some reason not well-understood and companies make an e= ffort to remove X.509 trust anchors with SHA-1 in signatures over them.

On Tue, Jan 7, 2020, 5:49 PM Phillip Hallam-Baker <phill@hallambaker.com> wrote:
Those certificates are not actually at risk because th= ey were originally signed when SHA-1 was still trusted. It is the intermedi= ate and EE certs that are the concern.

On the cost of attack thing. $11K is well within the amount o= f computer time that can be stolen...




On Tue, Jan 7, 2020 at 8:46 PM Jeffrey Walton <noloader@gma= il.com> wrote:
On Tue, Jan 7, 2020 at 10:23 AM Russ Housley <housley@vigilsec.c= om> wrote:
>
> https://eprint.iacr.org/2020/014
>
> > SHA-1 is a Shambles - First Chosen-Prefix Collision on SHA-1 and<= br> > > Application to the PGP Web of Trust
> >
> > Ga=C3=ABtan Leurent and Thomas Peyrin
> >
> > Abstract: The SHA-1 hash function was designed in 1995 and has be= en
> > widely used during two decades. A theoretical collision attack wa= s first
> > proposed in 2004 [WYY05], but due to its high complexity it was o= nly
> > implemented in practice in 2017, using a large GPU cluster [SBK+1= 7].
> > More recently, an almost practical chosen-prefix collision attack=
> > against SHA-1 has been proposed [LP19]. This more powerful attack= allows
> > to build colliding messages with two arbitrary prefixes, which is= much
> > more threatening for real protocols.
> >
> > In this paper, we report the first practical implementation of th= is
> > attack, and its impact on real-world security with a PGP/GnuPG > > impersonation attack. We managed to significantly reduce the comp= lexity
> > of collisions attack against SHA-1: on an Nvidia GTX 970,
> > identical-prefix collisions can now be computed with a complexity= of
> > 2^61.2 rather than 2^64.7, and chosen-prefix collisions with a co= mplexity
> > of 2^63.4 rather than 2^67.1. When renting cheap GPUs, this trans= lates to
> > a cost of 11k US$ for a collision, and 45k US$ for a chosen-prefi= x
> > collision, within the means of academic researchers. Our actual a= ttack
> > required two months of computations using 900 Nvidia GTX 1060 GPU= s (we
> > paid 75k US$ because GPU prices were higher, and we wasted some t= ime
> > preparing the attack).
> >
> > Therefore, the same attacks that have been practical on MD5 since= 2009
> > are now practical on SHA-1. In particular, chosen-prefix collisio= ns can
> > break signature schemes and handshake security in secure channel<= br> > > protocols (TLS, SSH). We strongly advise to remove SHA-1 from tho= se type
> > of applications as soon as possible. We exemplify our cryptanalys= is by
> > creating a pair of PGP/GnuPG keys with different identities, but<= br> > > colliding SHA-1 certificates. A SHA-1 certification of the first = key can
> > therefore be transferred to the second key, leading to a forgery.= This
> > proves that SHA-1 signatures now offers virtually no security in<= br> > > practice. The legacy branch of GnuPG still uses SHA-1 by default = for
> > identity certifications, but after notifying the authors, the mod= ern
> > branch now rejects SHA-1 signatures (the issue is tracked as
> > CVE-2019-14855).

And if interested, Mozilla's cacert.pem
(https://curl.haxx.se/docs/caextract.html) ha= s 52 certificates at
risk:

$ ./test.exe
Load certificates from cacert.pem
Certificates total: 138

ecdsa-with-SHA256: 5
ecdsa-with-SHA384: 16
id_sha1WithRSASignature: 52
id_sha256WithRSAEncryption: 56
id_sha256WithRSAEncryption: 8
id_sha512WithRSAEncryption: 1

Jeff

_______________________________________________
saag mailing list
saag@= ietf.org
https://www.ietf.org/mailman/listinfo/saag<= br>
_______________________________________________
saag mailing list
saag@= ietf.org
https://www.ietf.org/mailman/listinfo/saag<= br>
--0000000000000274c6059b9859ae-- From nobody Tue Jan 7 19:22:18 2020 Return-Path: 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 C8B561200F5 for ; Tue, 7 Jan 2020 19:22:17 -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 OViSAFyP8Ht1 for ; Tue, 7 Jan 2020 19:22:16 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F092F1200EB for ; Tue, 7 Jan 2020 19:22:15 -0800 (PST) Received: from [192.168.46.129] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 31D40795; Wed, 8 Jan 2020 03:22:14 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Alan DeKok In-Reply-To: Date: Tue, 7 Jan 2020 22:22:12 -0500 Cc: Phillip Hallam-Baker , IETF SAAG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andrey Jivsov X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: Re: [saag] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 03:22:18 -0000 > On Jan 7, 2020, at 10:18 PM, Andrey Jivsov = wrote: >=20 > Even more precise, the hash algorithm in X.509 certificate trust = anchors doesn't matter for security. Self-signed X.509 certs are the = most common trust anchors.=20 >=20 > If a self-signed cert is a part of a certificate chain, it must be a = trust anchor. Therefore, the hash algorithm in a self-signed X.509 = certificate never matters for security. This should include compliance = reasons of "no SHA-1" because the signature field on self-signed cert = should never be verified (we can, but it just wastes compute cycles). >=20 > Remarkably, the above straightforward facts are for some reason not = well-understood and companies make an effort to remove X.509 trust = anchors with SHA-1 in signatures over them. My $0.02 is it's because it's easier to say "get rid of SHA1" than to = explain to people where / when it can be used, and why. I'm not sure = that they're wrong. Alan DeKok. From nobody Wed Jan 8 23:17:03 2020 Return-Path: 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 84731120025 for ; Wed, 8 Jan 2020 23:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 rnKZRj9T8cYV for ; Wed, 8 Jan 2020 23:17:00 -0800 (PST) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 EF884120020 for ; Wed, 8 Jan 2020 23:16:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1578554220; x=1610090220; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hU2H7zLL1hds3ZlSuxQY7SiZG9dcPF1QzW8Z1V+Bvng=; b=uusXtArrBfCceCTu7gaPrXJyaFGFQS+qW/+PK1HEPVDTSQq29yh/M4tq 4SCJFl7qAU4moJe0WfGOpDQeVxe0OmvUOj8NRgQGsNw94tCs24KxsycZC WlEa5iaEQlPo0V74K6OLjegYDah95wvSwwu0Gx7cdzOH1AIREwLiLt2ZP bBF1cwUAlx6TtV3zYHD7mU30Fez3TuJXHNwsCfqwZZsdmidoP3Aox4VU7 XMa29BaCS2L9VIyBR3k1FnwxkKbuuc6d2Ts2757ILqRn2g+bTJo7cT5b5 YcUydSgGb6/hlpoXpzemPFcxmEl1Eem8XnshGPsimeW+ATnKQQI9BZgZw g==; X-IronPort-AV: E=Sophos;i="5.69,413,1571655600"; d="scan'208";a="108894448" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from uxcn13-tdc-e.uoa.auckland.ac.nz ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 09 Jan 2020 20:16:56 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.9) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 9 Jan 2020 20:16:55 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Thu, 9 Jan 2020 20:16:55 +1300 From: Peter Gutmann To: Phillip Hallam-Baker , "noloader@gmail.com" CC: IETF SAAG Thread-Topic: [saag] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 Thread-Index: AQHVxW5peik3PNqOuEiM4/T+DmGoNqffJfeAgAAA7gCAAsXzEA== Date: Thu, 9 Jan 2020 07:16:55 +0000 Message-ID: <1578554217695.69920@cs.auckland.ac.nz> References: , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 07:17:02 -0000 Phillip Hallam-Baker writes:=0A= =0A= >Those certificates are not actually at risk because they were originally= =0A= >signed when SHA-1 was still trusted. It is the intermediate and EE certs t= hat=0A= >are the concern.=0A= =0A= In terms of the web PKI, they're also not at risk because they're not=0A= defending against anything that non-nation-state attackers care about. And= =0A= I'm not being snarky there, I mean that literally, there's no point in=0A= attackers investing anything more than the minimum necessary in trying to= =0A= forge certs for web sites because they can do just as well without them (Re= fs:=0A= Too many to list here, but start with the APWG data if you need something t= o=0A= go from).=0A= =0A= However, let's look at the actual threat a bit more closely, and in particu= lar=0A= from the point of view of someone who has legacy infrastructure they need t= o=0A= work with and wants to know where and what needs shoring up. The attack=0A= requires that someone be able to stuff arbitrary binary data that the victi= m=0A= won't check into a signed message, as well as causing the victim to=0A= reinterpret the message in an entirely different manner than originally=0A= intended.=0A= =0A= This happens to work quite well for OpenPGP/GPG, but is more tricky for cer= ts=0A= both because there's no attackerControlledData extension (yet [0]) and beca= use=0A= of the amount of decoration that ASN.1 adds to anything that's being encode= d.=0A= So what the attacker would have to do is define a new extension=0A= attackerControlledData and create a cert where it's present in there, to=0A= mirror the (mis-)use of JPEG images with attached binary garbage in OpenPGP= /=0A= GPG (this is from reading the paper on-screen, I still need to get a printe= d=0A= version to study properly, in particular to try and understand whether the= =0A= process described in section 6.1 can even be applied to an X.509 cert), and= =0A= also to figure out how to get the victim to reinterpret what's being signed= as=0A= was done for the OpenPGP data.=0A= =0A= A simple countermeasure there for long-lived signatures where this type of= =0A= attack is a threat (assuming the ASN.1-reinterpretation is achievable), e.g= .=0A= X.509 certs in legacy deployments, is that if SHA-1 is being used, reject= =0A= certs with an unknown extension, or one with type-and-value fields of unkno= wn=0A= type.=0A= =0A= Peter.=0A= =0A= [0] Watch out for an April 1 RFC "The attackerControlledData extension for= =0A= X.509" :-).=0A= From nobody Thu Jan 9 07:00:35 2020 Return-Path: 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 07AA312008B for ; Thu, 9 Jan 2020 07:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=ST5Cy/PD; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=ZCmNfzEK 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 evgrrZCCLLCY for ; Thu, 9 Jan 2020 07:00:10 -0800 (PST) Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20]) (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 C044B1200DF for ; Thu, 9 Jan 2020 07:00:05 -0800 (PST) Received: from pps.filterd (m0170389.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 009Et4ko003792; Thu, 9 Jan 2020 10:00:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=smtpout1; bh=3UJoah5gQatfoQCrwuG2ZBamvraoEr95XPe5hqrykJM=; b=ST5Cy/PDJqjw8vQbgEvmmdCLNcjUj89F1Smm04KvN0c1Q7/zmPE+A7dU0dg4D8t9ioLK jmPceA440Cy5Hlu/UfTe8Dsewr8D/qDUc//SUwZqePP/tHDQ/V3RbBw393qxMUYoSsFl QaGodnYU+Ejgg5BJ9uuiXcSY507FI3ZE2B/DCmBF7FceunUcMkOtNy4VF5Il8L7iIcil AEOnrH5K1ZBtW+G9SEzCQf6+wTByouA1HslgldNy0YKvKVJxxsJWN1EJHtq/qQXpkspV cVZsJVx4xL2P3mmTFqEvXnHom/e+Iunwqo9mRugVds5jQN/urQ2A9cQVVKfIj+4zZevy 7g== Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0a-00154904.pphosted.com with ESMTP id 2xaqkn5hc7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Jan 2020 09:59:59 -0500 Received: from pps.filterd (m0144103.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 009EvvMV008744; Thu, 9 Jan 2020 09:59:59 -0500 Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2172.outbound.protection.outlook.com [104.47.58.172]) by mx0b-00154901.pphosted.com with ESMTP id 2xe24hc1k4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 09 Jan 2020 09:59:58 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iwZfVz6doTsZSS7hLUwCa14572oybn7EjqebcP7dytKtwObmZoUfFPaUXayy/z0VONIWCPqNR0Duu5al3Vf6IXRPY2xqXAJ115b/R3483Z5RO8tdrP/8XSK14AmZ+Mnfcwh/+APSkpIl7rOGN7S2O8xA4kTUxURyvOllZRa/dQT1y8tHB2s7Y5zl1Z18nJPdXI8cpJEj8rkSSLdGQMXi5A1WIReTJsAQlkZDK2x+zGtQs5Oeva6krEDsrk34aRwy7yaZYqrTdPF/gSFV+hKglnXJHWIjz918GabtpPg6gptts3H94pwZFpQicAGmKMMZEMoZVmQQ+WXUcuvt/ICLfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3UJoah5gQatfoQCrwuG2ZBamvraoEr95XPe5hqrykJM=; b=O2NN6j+9Ob88jZMv9cVGn30NbP1EeAxUOKPqYupsF4uBzV06YPqexWDteXvrG5DK7BI9t3MHG3+VSYolZ6DvnfDIXXFFCTa5HiXdu823KwaWw/Wk9c513N0kK5MnHz90GnFib2zQm/DcRpu2uEdnsfdyKjmA6tRprdqcv75BKEdvlwUf168QqRaOtpWVw0FGwhvQBQngx5ALFgrCNgKJseTjp/BFU9Nv4c5zyaofA+tvqJ0WV66b4mFiumDbIScuGNk73yytTKvGMq1cs8Yfbpvjaz44Nkoxnj2YpCgF6wf4XvXT7HKafpM8hG59yDkT2mB6LHrMdBo+g22zAm84dA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Dell.onmicrosoft.com; s=selector1-Dell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3UJoah5gQatfoQCrwuG2ZBamvraoEr95XPe5hqrykJM=; b=ZCmNfzEK4yMYdtLqVzBp+oBL3cd2AOW2e3ZgTR3zeSW96b3fqaoj94+AQ0dPKLzUgVlLwrR6CJFUSG7OG87DPhcfxuf7IZeE0qB4rDKVrA6H/MIfZkC9fX7DJhTZqiP7yyHN6oTrArZc1YJukrQkQSZl/n8/JfhiUlpH+SZ4kv0= Received: from DM6PR19MB4042.namprd19.prod.outlook.com (10.186.141.148) by DM6PR19MB2425.namprd19.prod.outlook.com (20.179.105.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.11; Thu, 9 Jan 2020 14:59:57 +0000 Received: from DM6PR19MB4042.namprd19.prod.outlook.com ([fe80::5df8:ac7f:9f09:51c7]) by DM6PR19MB4042.namprd19.prod.outlook.com ([fe80::5df8:ac7f:9f09:51c7%5]) with mapi id 15.20.2623.010; Thu, 9 Jan 2020 14:59:57 +0000 From: "Black, David" To: Peter Gutmann , Phillip Hallam-Baker , "noloader@gmail.com" CC: IETF SAAG , "Black, David" Thread-Topic: [saag] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 Thread-Index: AQHVxW5zZBsfWuxPRUuCbBT/7kcBQaffJfeAgAAA7gCAAsXzEIAAgqYw Date: Thu, 9 Jan 2020 14:59:56 +0000 Message-ID: References: , <1578554217695.69920@cs.auckland.ac.nz> In-Reply-To: <1578554217695.69920@cs.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2020-01-09T14:59:55.9636307Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public x-originating-ip: [72.74.71.221] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f71ab83c-4ede-4352-f715-08d79514979a x-ms-traffictypediagnostic: DM6PR19MB2425: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4 x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02778BF158 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(7502003)(13464003)(189003)(199004)(81156014)(81166006)(2906002)(8676002)(498600001)(186003)(26005)(5660300002)(54906003)(966005)(110136005)(52536014)(107886003)(55016002)(6506007)(53546011)(76116006)(8936002)(4326008)(9686003)(71200400001)(86362001)(7696005)(33656002)(66946007)(66446008)(64756008)(66556008)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR19MB2425; H:DM6PR19MB4042.namprd19.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: dell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jLeJm6x3wz1wFGUqq+vP+xloxt9aghdRznxyGGF2kOXXD1EuFLohiL1YOxeJeEq09aKjzka+byR5PMow+ApqfbfZAn1btUbTUwTOsFat6paT5P5fHyYsotqMg/TnMFcDh9thCFZL94WSuZlnRNPP1O0dgu2Pi+lgq0+60Raexe3/uWzmkzEptDxHGeZXOaT2aGLOoCVHJbddaT3el2HFcREL6wgo7AVDhMBqJeo+vKjjWe1q0YaU6s1KYAumw3DfvQCGh0xZMqfHysb+uDf68lbV0dJo9stZkpLMKImGViHdWkHiAcSg+7WrwGXJeQ1F9TeVWVOV+/tPzhaVx1KJvRtMXDH/tEoiNJJrap1pxg4wzGBOpuTDyzIHzmen3coklDuBcDjqO1XMOZDYT0IEB8My6EyI8i1UP0t/QQ+196RDgTwr3ZYC+Jmk1VLiEnWathhWaUKbcuDPHKFPNQjjnUHY+/Ckh2xZId1SfD473rZmuI8GR5LVdZCCMrb/ncqBBD31EZvY520J9vrvSHczVSr9R/QZEDPXey6WuBg79KEvG5IB28J2YL1yFKyyB2AseXz+euFrZhtavnhUoj3puw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Dell.com X-MS-Exchange-CrossTenant-Network-Message-Id: f71ab83c-4ede-4352-f715-08d79514979a X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2020 14:59:56.9822 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: b+3Dof99FHSeJxIY7RlFkFetHKTi9OwjAcqsvNifiNZJs9RfClayoY6yZaMasLAm8mJ0jht157/HHiwtfVZefw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR19MB2425 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-09_02:2020-01-09, 2020-01-09 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 phishscore=0 adultscore=0 bulkscore=0 clxscore=1011 suspectscore=0 impostorscore=0 malwarescore=0 priorityscore=1501 lowpriorityscore=0 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001090131 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 malwarescore=0 bulkscore=0 mlxlogscore=999 lowpriorityscore=0 mlxscore=0 spamscore=0 suspectscore=0 phishscore=0 priorityscore=1501 adultscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001090131 Archived-At: Subject: Re: [saag] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 15:00:29 -0000 > [0] Watch out for an April 1 RFC "The attackerControlledData extension fo= r > X.509" :-). Be careful what you wish for ... after all, RFC 1149 was implemented :-) !! https://en.wikipedia.org/wiki/IP_over_Avian_Carriers Thanks, --David > -----Original Message----- > From: saag On Behalf Of Peter Gutmann > Sent: Thursday, January 9, 2020 2:17 AM > To: Phillip Hallam-Baker; noloader@gmail.com > Cc: IETF SAAG > Subject: Re: [saag] SHA-1 is a Shambles: First Chosen-Prefix Collision on= SHA- > 1 >=20 >=20 > [EXTERNAL EMAIL] >=20 > Phillip Hallam-Baker writes: >=20 > >Those certificates are not actually at risk because they were originally > >signed when SHA-1 was still trusted. It is the intermediate and EE certs= that > >are the concern. >=20 > In terms of the web PKI, they're also not at risk because they're not > defending against anything that non-nation-state attackers care about. A= nd > I'm not being snarky there, I mean that literally, there's no point in > attackers investing anything more than the minimum necessary in trying to > forge certs for web sites because they can do just as well without them (= Refs: > Too many to list here, but start with the APWG data if you need something= to > go from). >=20 > However, let's look at the actual threat a bit more closely, and in parti= cular > from the point of view of someone who has legacy infrastructure they need= to > work with and wants to know where and what needs shoring up. The attack > requires that someone be able to stuff arbitrary binary data that the vic= tim > won't check into a signed message, as well as causing the victim to > reinterpret the message in an entirely different manner than originally > intended. >=20 > This happens to work quite well for OpenPGP/GPG, but is more tricky for c= erts > both because there's no attackerControlledData extension (yet [0]) and be= cause > of the amount of decoration that ASN.1 adds to anything that's being enco= ded. > So what the attacker would have to do is define a new extension > attackerControlledData and create a cert where it's present in there, to > mirror the (mis-)use of JPEG images with attached binary garbage in OpenP= GP/ > GPG (this is from reading the paper on-screen, I still need to get a prin= ted > version to study properly, in particular to try and understand whether th= e > process described in section 6.1 can even be applied to an X.509 cert), a= nd > also to figure out how to get the victim to reinterpret what's being sign= ed as > was done for the OpenPGP data. >=20 > A simple countermeasure there for long-lived signatures where this type o= f > attack is a threat (assuming the ASN.1-reinterpretation is achievable), e= .g. > X.509 certs in legacy deployments, is that if SHA-1 is being used, reject > certs with an unknown extension, or one with type-and-value fields of unk= nown > type. >=20 > Peter. >=20 > [0] Watch out for an April 1 RFC "The attackerControlledData extension fo= r > X.509" :-). >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Thu Jan 9 08:46:04 2020 Return-Path: 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 BBC3512007C for ; Thu, 9 Jan 2020 08:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Vvvlo480t8Kx for ; Thu, 9 Jan 2020 08:46:01 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 948B5120019 for ; Thu, 9 Jan 2020 08:46:00 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id j1so7982726lja.2 for ; Thu, 09 Jan 2020 08:46:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S/30eO1y9D31f9PhLD0dyxF5gahRGPZKw5aC4TXfhxk=; b=OMEEz50MlBk+VeYZcKj94+CRn3E9KWVWVCDBxdfSg0tPcaW2xrfrR1FMGECVozZpqp n9n3zpiLnFSrC/BleL0p0LzXH+lhSFCdm6NNxdz7n+fKTmoi4NsHVGtoZeLqU7hvsgAK vTPxu9giQk0rj9WJbYFbIQPAqrUoyZS5+xdyOHZtS5osjsuCoxd8E8ymbmMG4wR1mI3a 9PuUGlexNty7e5gVWwQMMz4qXpMwDDaYEKbdJyvZsG2BM0IGRTuFGpkqDRDY1hKmRurL TSmGM0EuZdhhDLrjCbtyiuaCaUUNms9q1/l5EBhpqPBFu/YwswXTFOcA3SjUS52zYYnY 3GRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=S/30eO1y9D31f9PhLD0dyxF5gahRGPZKw5aC4TXfhxk=; b=JBS8xU+4IiARAN1HL7yIXDjb8jC5pg8QoupOXf2OX5pSH5urT4f3oD6kzAG9KkHq0f /bZGdSVk45DRPuBPmpDZfVHDceSMdXqobzy5dZmYbXrlDDX3BgPjfHS2vfsIXXuQvqJM 50HTzirfE/dGkGP5x6/ts44duAldOuUYN+bfhFZI83DpvdMx5sXRFsCzn01DSR2zkDUv yXtoXVPCff3JRjs+d2NMp6cpnXPnK9Cz1XIRig3BpsNvPG/3XdVl8yBPm93PHjJvGsdN e0x5+QIq6peL1KspfWCKuEdhTmdR2IEOoVMcwn8Ukj5An6QZYDkki05175dNl4o25mCr Xbzg== X-Gm-Message-State: APjAAAXp2F7B2NuwpPIYVXqIefkVk97T82xFb4wzTBopTbk9Kz7ZB8H7 hEicSMB0g5jYrXo8sS/WcNptTzps0X3VP5iTAes= X-Google-Smtp-Source: APXvYqzqc5jFt3pff2YlFwxxooe+P5WYUbmj1ZSkG8o13kdIbutiejcu+Amr8DG3Fp+HLnchLmIjum8MZu+RKkMEzR4= X-Received: by 2002:a2e:80cc:: with SMTP id r12mr7140951ljg.154.1578588358587; Thu, 09 Jan 2020 08:45:58 -0800 (PST) MIME-Version: 1.0 References: <1578554217695.69920@cs.auckland.ac.nz> In-Reply-To: <1578554217695.69920@cs.auckland.ac.nz> From: Watson Ladd Date: Thu, 9 Jan 2020 11:45:47 -0500 Message-ID: To: Peter Gutmann Cc: Phillip Hallam-Baker , noloader@gmail.com, IETF SAAG Content-Type: multipart/alternative; boundary="0000000000005c39b2059bb7be4d" Archived-At: Subject: Re: [saag] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 16:46:03 -0000 --0000000000005c39b2059bb7be4d Content-Type: text/plain; charset="UTF-8" On Thu, Jan 9, 2020 Peter Gutman wrote > > A simple countermeasure there for long-lived signatures where this type of > attack is a threat (assuming the ASN.1-reinterpretation is achievable), > e.g. > X.509 certs in legacy deployments, is that if SHA-1 is being used, reject > certs with an unknown extension, or one with type-and-value fields of > unknown > type. > Let's look at actual exploitation of a chosen prefix attack in the CA ecosystem. This happened twice, once as a talk demo and another time as part of a cyberattack. http://deweger.xs4all.nl/papers/[41]StSoApLeMoOsdW-RogueCA-Crypto[2009].pdf Did the attackers succeed? Yes Did they need a custom extension? No Does the countermeasure work? No Why is this less work then disabling SHA-1 verification 14 years after Wang's attacks, 3 years after the Web PKI disabled SHA-1 etc? There are some other countermeasures like injecting randomized large serial numbers, but these aren't followed uniformly by CAs outside the Web PKI. Beyond cryptography there are all manner of other attacks that require updating. It's clear that slow update cycles and backwards compatibility have had substantial negative impacts on security. --0000000000005c39b2059bb7be4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jan 9, 2020 Peter Gutman wrote

A simple countermeasure there for long-lived signatures where this type of<= br> attack is a threat (assuming the ASN.1-reinterpretation is achievable), e.g= .
X.509 certs in legacy deployments, is that if SHA-1 is being used, reject certs with an unknown extension, or one with type-and-value fields of unkno= wn
type.

Let's look at actual exploitation of a chosen prefix attack in the= CA ecosystem. This happened twice, once as a talk demo and another time as= part of a cyberattack.


Di= d the attackers succeed? Yes
Did they need a custom = extension? No
Does the countermeasure work? No
=

Why is this less work then di= sabling SHA-1 verification 14 years after Wang's attacks, 3 years after= the Web PKI disabled SHA-1 etc?

There are some other countermeasures like injecting randomized la= rge serial numbers, but these aren't followed uniformly by CAs outside = the Web PKI.

Beyond cryp= tography there are all manner of other attacks that require updating.=C2=A0= It's clear that slow update cycles and backwards compatibility have had= substantial negative impacts on security.
--0000000000005c39b2059bb7be4d-- From nobody Thu Jan 9 17:28:50 2020 Return-Path: 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 7E28B120288 for ; Thu, 9 Jan 2020 17:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 pOeJyy1ETzvr for ; Thu, 9 Jan 2020 17:28:47 -0800 (PST) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 D6C79120131 for ; Thu, 9 Jan 2020 17:28:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1578619727; x=1610155727; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Y9qVb0Uhv5ygUXrt0+QSsTgtVyq2VC35kuuPxkPKnF8=; b=AynjYf8LFkatJ8KFZzf89eVKZb40bKWyoxrD67msbACXud8VU+2hXWLb yGZw+bKJxhpnUSowuiePTZOKIEwsZdwOtuNtUXy1VFXz0zUyqSj/Wh7aH MHEqMAvj/CSISxgAQL0WidSPfcAk+yj/prcXTRO61Os71InFs7NbSuyUb 6b9jw2ZkVkIZdQbo56dN7/F71N/s6+8n9fgWqUY7zmlmIZgvRwj8///lj dVT8eT9hEcJWXnpEKqNZgmARCK4JZFdtbKah7fUvVq4JYgOo/F1X10GX5 vaLfF4mBLFDYPaZcQytyfT9SVrevLsbSnePY9DGU/h5pnAiPqwRgSLQM9 Q==; X-IronPort-AV: E=Sophos;i="5.69,414,1571655600"; d="scan'208";a="109020941" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from uxcn13-tdc-e.uoa.auckland.ac.nz ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 10 Jan 2020 14:28:42 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.9) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 10 Jan 2020 14:28:42 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Fri, 10 Jan 2020 14:28:41 +1300 From: Peter Gutmann To: Watson Ladd CC: Phillip Hallam-Baker , "noloader@gmail.com" , IETF SAAG Thread-Topic: [saag] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 Thread-Index: AQHVxW5peik3PNqOuEiM4/T+DmGoNqffJfeAgAAA7gCAAsXzEP//xtmAgAFr1gE= Date: Fri, 10 Jan 2020 01:28:41 +0000 Message-ID: <1578619724689.8862@cs.auckland.ac.nz> References: <1578554217695.69920@cs.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [saag] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 01:28:49 -0000 Watson Ladd writes:=0A= =0A= >Did the attackers succeed? Yes=0A= >Did they need a custom extension? No=0A= >Does the countermeasure work? No=0A= Was the hash function and its weakness practically identical to MD5? No=0A= Did the CA that was attacked randomise serial numbers? No=0A= =0A= Again, this is just to understand how to mitigate problems for legacy stuff= ,=0A= not to try and prolong SHA-1 use indefinitely, but it would be good to=0A= understand where the exact risks for SHA-1 use lie.=0A= =0A= Peter.=0A= From nobody Thu Jan 9 17:44:46 2020 Return-Path: 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 8655B120808 for ; Thu, 9 Jan 2020 17:44:44 -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 UdOdrLBZqr48 for ; Thu, 9 Jan 2020 17:44:42 -0800 (PST) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACE5D120131 for ; Thu, 9 Jan 2020 17:44:42 -0800 (PST) Received: by straasha.imrryr.org (Postfix, from userid 1001) id DD50F2B1B57; Thu, 9 Jan 2020 20:44:41 -0500 (EST) Date: Thu, 9 Jan 2020 20:44:41 -0500 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20200110014441.GK73491@straasha.imrryr.org> Reply-To: saag@ietf.org References: <1578554217695.69920@cs.auckland.ac.nz> <1578619724689.8862@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1578619724689.8862@cs.auckland.ac.nz> User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: Subject: Re: [saag] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 01:44:45 -0000 On Fri, Jan 10, 2020 at 01:28:41AM +0000, Peter Gutmann wrote: > Again, this is just to understand how to mitigate problems for legacy stuff, > not to try and prolong SHA-1 use indefinitely, but it would be good to > understand where the exact risks for SHA-1 use lie. In the DNSSEC space, it now seems a good time to emphasize the deprecation (RFC8642) of algorithms 5 and 7 which sign with RSA-SHA1. https://tools.ietf.org/html/rfc8624#section-3.1 the potential avenues for abuse are expored at: https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html the attack is still comparatively expensive, and the attacks are contigent on some additional operational practices, but it seems there's enough exposure that is likely to only get worse, that it is much easier to tell users to move along to stronger algorithms than try to explain which use-cases remain safe, and which not. -- Viktor. From nobody Wed Jan 15 07:00:18 2020 Return-Path: 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 6C80C120077 for ; Wed, 15 Jan 2020 06:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 iCcR2nhKDnk3 for ; Wed, 15 Jan 2020 06:59:28 -0800 (PST) Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) (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 DF245120026 for ; Wed, 15 Jan 2020 06:59:27 -0800 (PST) Received: by mail-oi1-f178.google.com with SMTP id c16so15640147oic.3 for ; Wed, 15 Jan 2020 06:59:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=NZgXTehp5P8mGYd5Clqcl9VCeWXqnkUch5IXaGZos+s=; b=reHgb+cPRBhs5+NAYsE/rWaLGrZKfc77oyEBMtKG+M6ByhhsY1EJFdC+qHOyOX1dcb wME3aa5UpfxdvCDGOB00EJ3eV3ufdjacXhQvQG/Pi4VdB7vrlXBnHLiyI9IfYc+2Vmtt w19JSaETlFhzqWXnkHgRv1I9Y/5UKXhWy7sQoHBdz2EzFiFETHjMC+3KuqCjRB/bDLrb I97s3uwcZHrdlgBFHM2tT1tO+9XbvEYBUphQFxeEflUZrdWWd5XPOOHigyUDI8VmSOK5 aTO+4gHJ1wrb0J8GlmSL1VgJUFnbaREgO6yY/JD5XWy2xuGaFT8xCKtVaCeeqSBUy00n ACOw== X-Gm-Message-State: APjAAAW/+EN4paADvHz4r5wZL5QSXYQCEUAq4NqBj5AH7axN7GT9wJBM WWcJyTND7UQytrfSJxFogyhc1Ak4VpOZo1yLDE0UU2i1 X-Google-Smtp-Source: APXvYqwbixnF+YvTx1AKHuKVq9yTn/FPrICPZmKTw6/ibE0uegoRcfGj4WHeZGqgsjANV/5Id620Rwf96iEhEbyIQt0= X-Received: by 2002:a54:4f04:: with SMTP id e4mr77369oiy.111.1579100366882; Wed, 15 Jan 2020 06:59:26 -0800 (PST) MIME-Version: 1.0 From: Phillip Hallam-Baker Date: Wed, 15 Jan 2020 09:59:15 -0500 Message-ID: To: IETF SAAG Content-Type: multipart/alternative; boundary="0000000000006ece5a059c2ef4f2" Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 14:59:30 -0000 --0000000000006ece5a059c2ef4f2 Content-Type: text/plain; charset="UTF-8" I have been reading the reports in the press. >From what I gather, the attack allows an incompetent or malicious CA to craft a malicious certificate. It may also be possible for a CSR to be crafted that could result in a CA issuing a bad EE cert. >From the limited information I can find, it would appear that we don't actually have much of a problem as the whole WebPKI is predicated on the idea that CAs are trusted and they have pretty much infinite ways to defect. Has anyone checked the Certificate Transparency logs to see if any bogus certs matching the NSA pattern are recorded? I would expect not as we require specific NIST curves that have specific names. --0000000000006ece5a059c2ef4f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I h= ave been reading the reports in the press.

From what I gather, the attack allows an incompetent or m= alicious CA to craft a malicious certificate. It may also be possible for a= CSR to be crafted that could result in a CA issuing a bad EE cert.

From the limited information I= can find, it would appear that we don't actually have much of a proble= m as the whole WebPKI is predicated on the idea that CAs are trusted and th= ey have pretty much infinite ways to defect.

Has anyone checked the Certificate Transparency logs t= o see if any bogus certs matching the NSA pattern are recorded? I would exp= ect not as we require specific NIST curves that have specific names.
<= /div> --0000000000006ece5a059c2ef4f2-- From nobody Wed Jan 15 07:09:50 2020 Return-Path: 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 1D70E1200DB for ; Wed, 15 Jan 2020 07:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 WGEK5Nzd3s2k for ; Wed, 15 Jan 2020 07:08:53 -0800 (PST) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 997DA1200DE for ; Wed, 15 Jan 2020 07:08:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1579100927; x=1610636927; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=DZHTUCKzFFcRSeU1QJr7I9EgfH0gWqz3kT6R+2/Bx7k=; b=2T10F7AmAxaucT70TU4xRlm3CbX9Goo9+YqTqdiqxL3EHPLQ0ZTPqrUf 27+bsjo9AUYpjLKdOggrePFPDOLnRbsNPCxebnapBbzy8P5hUFYI+bWV0 amXVQAQ6eLYCet9WCHy210LAQTqq7S2L0eI8982N08vvVo5ZcHHTMdvXf 3YZy9dGwein+OiMr4mfcVsfLnSqrf9ZRFszEQqz3HTkm6WT2sGRj+UXxJ v69UXAOH5+k8U+ESAFuNzhCnBKOqlkSBfSv60d99zvAqpMLH+Vp2J1ud8 DGRcCWCCJZKxae+M0m0S48aCoOLqnspt991l5Q1sWBTDmsOM6Jqyhj5bv Q==; X-IronPort-AV: E=Sophos;i="5.70,322,1574074800"; d="scan'208";a="109892851" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-tdc-a.UoA.auckland.ac.nz) ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 16 Jan 2020 04:08:44 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.2) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 16 Jan 2020 04:08:37 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Thu, 16 Jan 2020 04:08:37 +1300 From: Peter Gutmann To: Phillip Hallam-Baker , IETF SAAG Thread-Topic: [saag] NSA bug in Windows 10 Thread-Index: AQHVy7SFV0v01oMYaUOc3bty1eNrZafr0x0x Date: Wed, 15 Jan 2020 15:08:37 +0000 Message-ID: <1579100916686.94828@cs.auckland.ac.nz> References: In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 15:08:59 -0000 Phillip Hallam-Baker writes:=0A= =0A= >Has anyone checked the Certificate Transparency logs to see if any bogus= =0A= >certs matching the NSA pattern are recorded? I would expect not as we requ= ire=0A= >specific NIST curves that have specific names.=0A= =0A= Speculation: The universal standard for ECDSA is the NIST curves, with some= =0A= minor subset using the Brainpool curves, but in any case named curves.=0A= However, the NSA being the NSA, I'll bet they use their own curves and not = the=0A= NIST ones [0], which were created in secret by some dodgy US TLA and then f= ed=0A= to NIST. So the reason for the NSA choosing to disclose the vulnerability = may=0A= be that it principally affects them and no-one else, which also means there= 's=0A= not much chance of anything appearing in the CT logs.=0A= =0A= Oh, and rumors that, since it's the NSA that's recommending the fix to a=0A= Microsoft product, they've told them to double the security of their ROT13= =0A= implementation by applying it twice, are entirely false.=0A= =0A= Peter.=0A= =0A= [0] Suite B, which did use NIST curves, seems to have fallen by the wayside= .=0A= From nobody Thu Jan 16 08:41:04 2020 Return-Path: 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 ; 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 ; 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 ; 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 To: Peter Gutmann , Phillip Hallam-Baker , IETF SAAG 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: <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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 16:41:02 -0000 ------=_NextPart_000_0034_01D5CC61.C6EFDC80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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. ------=_NextPart_000_0034_01D5CC61.C6EFDC80 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCIdUw ggXJMIIDsaADAgECAgUA9lfgwDANBgkqhkiG9w0BAQ0FADB8MQswCQYDVQQGEwJDQTEbMBkGA1UE CgwSQmxhY2tCZXJyeSBMaW1pdGVkMSIwIAYDVQQLDBlCbGFja0JlcnJ5IEVudGVycHJpc2UgUEtJ MSwwKgYDVQQDDCNCbGFja0JlcnJ5IEVudGVycHJpc2UgUlNBIFJvb3QgQ0EgMTAeFw0xMzEyMTMx NzQ1NDdaFw0zODEyMTMxNzQ1NDdaMHwxCzAJBgNVBAYTAkNBMRswGQYDVQQKDBJCbGFja0JlcnJ5 IExpbWl0ZWQxIjAgBgNVBAsMGUJsYWNrQmVycnkgRW50ZXJwcmlzZSBQS0kxLDAqBgNVBAMMI0Js YWNrQmVycnkgRW50ZXJwcmlzZSBSU0EgUm9vdCBDQSAxMIICIDANBgkqhkiG9w0BAQEFAAOCAg0A MIICCAKCAgEAxkXAf/EHxa1okuoiPnKhHeaDfSRXq35g7JH34MqiM2cxMsL+WMe/8792DLEAe5Lm FLURmrkBiqwgzkrpejF1WBUaqrM0nGSkxTfO9ywXFHKZnK2wyxE+uNdIN5KzuzijEFJpnHxapdJg k8VmsgSnn+wTyRF8J/2DsaKV7UPYNkoGGZtCggI6Dh92G9AUKzZBSjfaZRfwStEv26wVgM8CiqSa O2FuwYriu+To03yDNiC0XOaGbPLyPAdyJbY71Bud3RQE1wciQV0nLwXnyCBmDK127NkjdewY4nAF TVuKaTVCqAdGKRo5idywpSHknZy01AvOJNuvL/BkN9Nv9nflelSml5TJNhfSa2hDRmHvr0+Jns+A qORC2WlvCybRGHkmTjpYLLMnIVprNBWPCCE6B/RaoLvcTvDeUwBVoqYzLSfLT6jAoXVcJM+XT948 TzAgCKcJg4oupgiMtYyL/oktajJbnpiLtRZ3jRX2hEgRW8tJZckvlxtrBGxQLYWNVe48OdBhbNnO bByGN2o0/GAttfkM8WrdjnCNv5YZ1d1eZPqCJicQ7ML4xRzUPwD1u7YvgdVRFidB3CsxM9nnlnam MYWQIV5nUuyK/1NUTiAEhGBYOsLeemgvPz41TsjERujbzHcj8MM3zMdwhWr86Dp1292C/bwyNgMm OfVgsHnZRnECAQOjVDBSMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQW BBT4aYn4Y57vaF6BMGJwUqMO3bKWCDAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG9w0BAQ0FAAOC AgEArBVGo/mS9/+yWzGI03ae5osTFt3v2acQVj1OrqSABZQXTdOXjJL31Q4QJABZlwllzKeIlFne 3c9yn39i3QMhoSjqkn4NjbPjKiiyzOLoI0PGq5UTQtpGm7X/EaXkcYDFhrIHnGfC9dmB5WeuwMwX fmKwUtiLPhgtgjGBqkxSOiFFbBUBiLGs/muE4IYbKJGPKqilOBLpeK1Kyp8zXIrJLLQ0zzkK6TkQ x6RULQ+px3geS5UWkrsFXCHK/x9vBxH313O7RV7vvwt2Opc0HFw9LzF50jie/wqx9HD3tm0GgvqD Aabtlao1V1mfLpk8k+nrWd589ZZSHmQMVFvzETnrS0BS4wZssImORAbv6tVCHZSf6gu1XApnxMaM Hy8qmL9lfkoTaxF7cxzzwrj5P49Xj+n4NZT95GyYNAoU3AhAFrQV+H6BXFTOHNX/ALubYWg5x+xu JFi+7HTcaCjZzjSGLWG3kilqn6JkT229jgYClzN8EylemXv3yz1vVjXbTRZNDK9G/p1Jj2SxlBC/ mTBvedATbkIMVm5Wzl8cE3rIp+A9lZ+bS9CfVx5OthHQxXn0fuVCakWp4a+KTsTtFlqbtVMesdcU Q1uMk8Tap11X43bkAyX25l76ejxuVCZYZaOxZFt689bVqRFh4DjyfagCRu65eQgOu013aZiAc28i WCEwggdJMIIGMaADAgECAgpyAx1HAAEAAlASMA0GCSqGSIb3DQEBCwUAMFYxEzARBgoJkiaJk/Is ZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xKjAoBgNVBAMTIUJsYWNrQmVycnkgQ29ycG9y YXRlIElzc3VpbmcgQ0EgMTAeFw0xOTA0MTcyMDU4MjRaFw0yMDAyMjYyMjM2NTVaMIGpMRMwEQYK CZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMQ0wCwYDVQQLEwRBTUVSMQswCQYD VQQLEwJDQTEUMBIGA1UECxMLTWlzc2lzc2F1Z2ExDjAMBgNVBAsTBVVzZXJzMRIwEAYDVQQDEwlE YW4gQnJvd24xJzAlBgkqhkiG9w0BCQEWGGRhbmlicm93bkBibGFja2JlcnJ5LmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALQHoYbI3q25dSCAl6YGPubc51/jvsRg5VZl6f8cADT/ N6anVBzRl77zYVSEmqlrHG2/x++rOxdzcAi/LP+L7IEiU/TX+EyPR4OSLf3sQTJg/CzZLhKT+ouR CH1jn0QgFviHE4Ni0no/E4x+N0zjmhWpF7WcoaNbY0ZVW5g1jy7KtEoLwDGFylPVsrwLMzud4wjJ 32R/McoCAqaWr/vgUOoHYY6K+5fGp7wNyvhhc0sG+8ku2vNWhBo7sufwdehGISQsaBXS+Wqgy7g1 qNePiR/5i8OFgEFjO//iozFIeTPoFbSd+k4y/jv7wD+yLvVy84q9LteXpv92aFR+aTJxkEkCAwEA AaOCA8MwggO/MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIe/l0uGuYEkhsGBMoPb8iWC3NgB gQCxwyqHn/RAAgFkAgELMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjALBgNVHQ8EBAMC BsAwDAYDVR0TAQH/BAIwADBPBgNVHSABAf8ERTBDMEEGCisGAQQBm0oTAQIwMzAxBggrBgEFBQcC ARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTAnBgkrBgEEAYI3FQoEGjAY MAoGCCsGAQUFBwMEMAoGCCsGAQUFBwMCMB0GA1UdDgQWBBTb4N+ts9rY1LbQOi40ca8/M4cXVTAf BgNVHSMEGDAWgBQaL0tL2wfJSTuJ1jIIJ6KeC/MPazCCATIGA1UdHwSCASkwggElMIIBIaCCAR2g ggEZhkBodHRwOi8vY3JsLnJpbS5uZXQvQmxhY2tCZXJyeSUyMENvcnBvcmF0ZSUyMElzc3Vpbmcl MjBDQSUyMDEuY3JshoHUbGRhcDovLy9DTj1CbGFja0JlcnJ5JTIwQ29ycG9yYXRlJTIwSXNzdWlu ZyUyMENBJTIwMSxDTj1NQ0EwMTBDTkMsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2Vz LENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZp Y2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQw ggEDBggrBgEFBQcBAQSB9jCB8zAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AucmltLm5ldC9vY3Nw MIHKBggrBgEFBQcwAoaBvWxkYXA6Ly8vQ049QmxhY2tCZXJyeSUyMENvcnBvcmF0ZSUyMElzc3Vp bmclMjBDQSUyMDEsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jQUNlcnRpZmljYXRlP2Jhc2U/ b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBNBgNVHREERjBEoCgGCisGAQQBgjcU AgOgGgwYZGFuaWJyb3duQGJsYWNrYmVycnkuY29tgRhkYW5pYnJvd25AYmxhY2tiZXJyeS5jb20w DQYJKoZIhvcNAQELBQADggEBAEoWAOg0VEQNS86VaoPS9opseSqdMyxa/SyUNcoqeTRgadtmv1FX zUPytJUDgHQrMAmpHCurdPASknaqoHOaOyTf2AfJO9a36jIq+yC+7ybZFfiXOaFKOvAcDOpS0O25 PVZdG202Nt/g5hrOyd/hUplu0xz4h8CvihzW7AuUsBOBJn7vW5dvggrRx28FSBUARj4plfhNoGoI XJfFghQ1fWmjg8o9NjhTpXKDTy7kMNkUX2g+HACq4tzf0sjthqTFpGsAq+PhqFxKQLZ8GRAq67F+ mHWEvZArnHnDAk4JpqlGMZTVXRWZzW+21feqnog1FU6kgtM5/8uvtrEMQSe8Dn8wgggFMIIF7aAD AgECAgRDFVhfMA0GCSqGSIb3DQEBDQUAMHwxCzAJBgNVBAYTAkNBMRswGQYDVQQKDBJCbGFja0Jl cnJ5IExpbWl0ZWQxIjAgBgNVBAsMGUJsYWNrQmVycnkgRW50ZXJwcmlzZSBQS0kxLDAqBgNVBAMM I0JsYWNrQmVycnkgRW50ZXJwcmlzZSBSU0EgUm9vdCBDQSAxMB4XDTE0MDIyNjE2MjM1NloXDTI0 MDIyNjE2MjM1NloweTELMAkGA1UEBhMCQ0ExGzAZBgNVBAoMEkJsYWNrQmVycnkgTGltaXRlZDEi MCAGA1UECwwZQmxhY2tCZXJyeSBFbnRlcnByaXNlIFBLSTEpMCcGA1UEAwwgQmxhY2tCZXJyeSBD b3Jwb3JhdGUgUG9saWN5IENBIDEwggIgMA0GCSqGSIb3DQEBAQUAA4ICDQAwggIIAoICAQC6JvZA kPpT2uIOJ8w4/hBW8IhdwmDtvzMEVmnYEmmr1cnQaD3NVSIxDfNFG2dVVeZJB4qmLwLkjMf0dgDo LtaPRaqZ2kW+fWuEeWqG4sRxCIWMgrdppkQoCenWGIiW7Q59bdNLk9MsiP2FPgFMVhSvXN38vl9t AEssQDmwPVnr9nBbBhW4OnaM2JDw0B5YEnMyXBJwslA+n4YDOTfzbIB5rzdzkG/Cy+Ss7NtOEIG1 Hfeur5RzruqaVRINsbk884T1TjR4q2BMhTE2uSjaANXkl+IM1YsfmIgCj/AKr4KhEAeM4to10mA8 3fUVLZzn5YPo8/jikzQ0qTge/7Yj2veffvkYkWG1pZGJvlofl/bi/62vrmrTkx9lDKLMl5zuK8qF znvSWVhntGsHWO0ZI+uSz5h7Alr0dOTdTOr1+SR2SzqL+uReyf2ViywiAEf7JtZj4QU2rlN7rxOi Suf7mz0D8RelA6TXaGlAe/q35kqAcciJZjMugO7+XG2chzjci5c/q+LJJTwz3M+QgSI21MhTcytC itBl0WFSg/vmE26nQnuryhWUoNvryGEP2xarae/oCiKZo41nc6LcVXCoJfq/pE5OKUhAi1N/RH26 OdDb3kOjdDdLIKY/yVThed1zESsuCUNkgy9APj5LgS95nSG/oQ9LlLL5g4YQd8WrwdFIZQIBA6OC ApIwggKOMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQ7uMF3 DZ6tQ1j8Ja4V0LfykTKFmzAfBgNVHSMEGDAWgBT4aYn4Y57vaF6BMGJwUqMO3bKWCDCBhgYIKwYB BQUHAQEEejB4MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5yaW0ubmV0L29jc3AwUAYIKwYBBQUH MAKGRGh0dHA6Ly9jcnQucmltLm5ldC9CbGFja0JlcnJ5JTIwRW50ZXJwcmlzZSUyMFJTQSUyMFJv b3QlMjBDQSUyMDEuY3J0MIIBNwYDVR0fBIIBLjCCASowggEmoIIBIqCCAR6GRGh0dHA6Ly9jcmwu cmltLm5ldC9CbGFja0JlcnJ5JTIwRW50ZXJwcmlzZSUyMFJTQSUyMFJvb3QlMjBDQSUyMDEuY3Js hoHVbGRhcDovLy9DTj1CbGFja0JlcnJ5JTIwRW50ZXJwcmlzZSUyMFJTQSUyMFJvb3QlMjBDQSUy MDEsQ049Um9vdENBLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNl cyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0 aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MDcGA1UdIAQwMC4w LAYEVR0gADAkMCIGCCsGAQUFBwIBFhZodHRwOi8vY3AucmltLm5ldC9jcHMvMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA0GCSqGSIb3DQEBDQUAA4ICAQC38TN+ EWKxTPBOf+yu0+eJD75HI0K1/VbX+/gkxxxthB+0rhaBVrJzU3j/ifE8ST9Icc+JgORZzCjZYUz7 Lj9DbvxbtUdaJGi7CHjjxgFm7aQkPX2BvpYHjjYeQ0349boayww1AG6iX42F/Gm+P4/UT4Jv5lo5 UepzMz8mgnOnAEqpzo7NFUixXZnLTTML6g8Co+Kpwl/gDOtTcXdit2SE4qugUCI9+4UIdO5cIFUK 2vkuev3JsjuUCl0p8g/591PyDxIUoRWt9I+8nkeDmdhr/Lyuh2OY82OXqCc7TdPPRdJdo0nWCJZu OxPrK1cJPPM/FMM7EwSruS1mFbMsHyXcmUBdfm8LudkPHPpszGlQ2cAcENzgyGCd2OWlggpp+y35 JIo9eKnLC5BGio6eno6MvfNMM5DzIr5hoVfLsbJUvlIIwOaqhWWPIjiQJgS8vAAZBONh6AXXs8TA smu0yt2cSp00HvUWAyJi8eOVUOiu+f7iXXUw+xhEcOyggo4JmJ4g+qM8wzx8pc4soKVMx4SLXXlR /uO3RNZ5ZNaVc3+qIqg4EbhGNQxyCGChFYemYvRdLmjqO0sGfofYaqRdhIBpKZYk7vDOwj0ZStzg TT55OAYF0jY+A9RXSiu6xm04F3C/2G7S19sHlhK28Prjf1Ahu5NwTnpaKdM5UiX4/SrKLTCCDK4w ggqWoAMCAQICBAsRTXAwDQYJKoZIhvcNAQELBQAweTELMAkGA1UEBhMCQ0ExGzAZBgNVBAoMEkJs YWNrQmVycnkgTGltaXRlZDEiMCAGA1UECwwZQmxhY2tCZXJyeSBFbnRlcnByaXNlIFBLSTEpMCcG A1UEAwwgQmxhY2tCZXJyeSBDb3Jwb3JhdGUgUG9saWN5IENBIDEwHhcNMTkwMjI2MjIzNjU1WhcN MjAwMjI2MjIzNjU1WjBWMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmlt MSowKAYDVQQDEyFCbGFja0JlcnJ5IENvcnBvcmF0ZSBJc3N1aW5nIENBIDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDVHL/KEgF8NzTToTzGn4ZzdjfvMRN9YG1zaPkekwXrknWRKOTw 30fjw6bP7CF60nnJwGSVhoQ1DkNqVz0ZPI35dJW3EBEUyNVAtOGb+fiNmDsOKk2gbe+zwLb1ttrN 7BOgIDuqJKlujUBYxBk6Cl44KOoKwSzuvxuFHP7T6oev23Jh+DZmkm7M60iVLDzHjchFru696K8b vSiczJw0AVqWymaupeFveprrdJUz1y/G0Q0GoeZ3NFH0azM8JS6MB7Sz1zO/9SdlxvrRu0mCEN8E OgUTfG1l1sDILs7IhM9gUBF+tHJpeFc+xuSHpx7spkRzhESmuFD4h+6IIJ/B7SofAgMBAAGjgghf MIIIWzASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUGi9LS9sH yUk7idYyCCeingvzD2swHwYDVR0jBBgwFoAUO7jBdw2erUNY/CWuFdC38pEyhZswgYEGCCsGAQUF BwEBBHUwczAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AucmltLm5ldC9vY3NwMEsGCCsGAQUFBzAC hj9odHRwOi8vY3J0LnJpbS5uZXQvQmxhY2tCZXJyeSUyMENvcnBvcmF0ZSUyMFBvbGljeSUyMENB JTIwMS5jcnQwggEsBgNVHR8EggEjMIIBHzCCARugggEXoIIBE4Y/aHR0cDovL2NybC5yaW0ubmV0 L0JsYWNrQmVycnklMjBDb3Jwb3JhdGUlMjBQb2xpY3klMjBDQSUyMDEuY3JshoHPbGRhcDovLy9D Tj1CbGFja0JlcnJ5JTIwQ29ycG9yYXRlJTIwUG9saWN5JTIwQ0ElMjAxLENOPVN1YkNBLENOPUNE UCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9u LERDPXdpbmRvd3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVj dENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIGEgYDVR0gBIIGCTCCBgUwQQYKKwYBBAGbShQC ATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEG CisGAQQBm0oTAQMwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVt ZW50Lmh0bTBBBgorBgEEAZtKEwECMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nw cy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3Au cmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTAgMwMzAxBggrBgEFBQcCARYl aHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwICMDMwMQYI KwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGb ShMCATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRt MEEGCisGAQQBm0oTAwMwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3Rh dGVtZW50Lmh0bTBBBgorBgEEAZtKEwMCMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0 L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMDATAzMDEGCCsGAQUFBwIBFiVodHRwOi8v Y3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTBAAwMzAxBggrBgEFBQcC ARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwUDMDMw MQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYB BAGbShMFAjAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQu aHRtMEEGCisGAQQBm0oTBQEwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQ U3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwYDMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0u bmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMGAjAzMDEGCCsGAQUFBwIBFiVodHRw Oi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTBgEwMzAxBggrBgEF BQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwcD MDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYK KwYBBAGbShMHAjAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1l bnQuaHRtMEEGCisGAQQBm0oTBwEwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3Bz L0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwgDMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5y aW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMIAjAzMDEGCCsGAQUFBwIBFiVo dHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTCAEwMzAxBggr BgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTAQBgkrBgEEAYI3 FQEEAwIBATAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTANBgkqhkiG9w0BAQsFAAOCAgEAbML2 XftFHnmxEj1R+YXOw1IvY2cr3KtA2X5HweMk8WeDorircFlDGIP09Dgj2eEn7F8yg4vevOjtOj/O u+nMfxe2XdsxqbkOfOGncy2IQY0jp8Dznqg7iTJm2q5Rz+RhyICipwRhXVGhPz+UaBqzgPMRbOCy GVJFOfzIvI6IAARtWbFpDCIkIliQ36kd8UlXuAeCOqwLOQSenuL4kV+oaCKu1mNz3hC5jurnrTrt gPDYG0koEg40cxd4rv7Dy78U9jps82PFiMiA+yomtYZEsveyHHdsPupz8BN2Q6Oww99nR1ME+ING FK9r7dhEj6xAMVJ/eS2JHwtNSU3gxhhcQm/ZaP8Isfc7JKSI86II78DCyVVAJrMrt+pkNYWw8KDi yxuN5HxfGTBykx9H4lxdDTYT8AS1kf3GJUXo3/8+09g8ZIfbiSm5l96jvAL62ix/aSwFT01T7sTn CgPAcutQSnWoONApDZvqzDSJRwAtdkX+DMn2lDlocTpw99a8WkWJpNyyImvV5OeO/ra5RMCH9f2V /SerRLOQDBIjss7S3x48Fw0VsYxEIBxMV45X47lpwGfXK5oi9OuLGHBkLFavyFpLvbSDpFHfhUiD Ae2DviaDWkyLVZJXWdrujxEW2tchEcuytZw6i9k41/4mgOiy6HYwhRJhknXr5YQJ5wu5rwQxggI8 MIICOAIBATBkMFYxEzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xKjAo BgNVBAMTIUJsYWNrQmVycnkgQ29ycG9yYXRlIElzc3VpbmcgQ0EgMQIKcgMdRwABAAJQEjANBglg hkgBZQMEAgEFAKCBqjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0y MDAxMTYxNjQwMzlaMC8GCSqGSIb3DQEJBDEiBCBhJTpcvpjRyrQL+5q6A/zz5u1dVnw+DRQuFpUw O5U6MTA/BgkqhkiG9w0BCQ8xMjAwMAsGCWCGSAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUD BAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUABIIBAGmCLGf0SNM3VsNvUB2+dNy/ohXGdzxaOGe1 YIVs+EBoiNikfZHL/BpT9zBGHcYSWGZWlD1n5rM/BKl7GTVnaVZsS5WscWkxGjVmQLTKjusrIBaH pKMWlE7ef2f7NinVyQMIteqHg1CJxob7tLsq81KAxhCH4Ree8kCvHspgZEkHFozKzX91AXQz0EEi dULP2qCEdpA7o/m+PokE1l5vHm0PtFkBT216vYrYgw0Majtq/gJbsJlqAAZitO5E5ExQ5OhZK4ob F9VvJ260IDtmiVtetFcylqU/pU0UiF83+fOHEpUbIM/pMFIu4TKgfhLERmIX+dWeqZ4W9miB3roe yR8AAAAAAAA= ------=_NextPart_000_0034_01D5CC61.C6EFDC80-- From nobody Thu Jan 16 09:41:45 2020 Return-Path: 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 99E1C120071 for ; Thu, 16 Jan 2020 09:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 K914MFQBc2H8 for ; Thu, 16 Jan 2020 09:41:39 -0800 (PST) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 E051612004A for ; Thu, 16 Jan 2020 09:41:38 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id e12so19553082qto.2 for ; Thu, 16 Jan 2020 09:41:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=webX0vdTLNdp7nHBX0Bwgvf2QETcRPXuTWQkh9FPNM4=; b=jDaJLaSVBp663fdMVmP0D7T2a5YOBuVHW4MXlg/Va/IdWRBWcejKjMjLUT2bsXX2Wb C9EmVyIimky9w1fvfgnW/zk35OQf7jZvyIMy/4BqwTbhjqkLpVbFKQPCVLlAc2GGzZf4 VTFfl2CckTkN91XbznBf1t6u1R69vJH1tYQrZJtD0IU80bDCh36OCTmS53iMu1gFx1A4 EolanXGkFRXq4RFypvLwGOq1SzM79ZdVVWkggCbai9lExuRBIYyw91gq/nSJnqKQdOun jVIO+oNILYuOwnwNbjQ7H3LIEsLcqUU9Ez4n9MRaoIJbwLM0PQhiIWNLyOEem+ORC7op W3/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=webX0vdTLNdp7nHBX0Bwgvf2QETcRPXuTWQkh9FPNM4=; b=K9R8EA9gjbtGlizRmthfoJhSDrRQxfSlCi6eP1mtlrkV4sGVA2D7hCKN/SHgBSgUCZ n+PPIXPR9h/Grnyw1F8WlDcYNL1EZNyr+ZDTV+j4o5hLYjFkxo2wGAM58dnsg28Qu5/s O6W562O2dTxEQOmFqv5kFy3ezBT3f7EEDoAArSUPMpUg3ZBl6Xy3yiLWHf1xzI7nX1Kk TmkWj8gpai8UFXGCisJwjddfHckXpxSVEiW0odAI7HKvPasJmDVNuIVHdopOxDHmVVUK Dn7qFz8F7u+vcmSJ8rPRw5gXWB5pMCNIrzpqyDcYE6PAMFtHW+NRfC/jhZUzn3Qpyw6g 3BRg== X-Gm-Message-State: APjAAAU0UHaYLeKZjF15E2oJ57ah/77uqMO6MSj/bvRRMtznK21TWM54 2RJkwki/ySTsIw4Q/JjDGoOt2U/x X-Google-Smtp-Source: APXvYqzUGpA6tfsQJgvDQh4/Fjlt0BSPTLHUe4VNAmAwHeyS7YNF+gsT/ooA2yI1k0yeT7XapOt3uQ== X-Received: by 2002:ac8:685:: with SMTP id f5mr3456498qth.199.1579196497015; Thu, 16 Jan 2020 09:41:37 -0800 (PST) Received: from SantoshBrain (pool-173-73-187-14.washdc.fios.verizon.net. [173.73.187.14]) by smtp.gmail.com with ESMTPSA id 124sm10357491qko.11.2020.01.16.09.41.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jan 2020 09:41:36 -0800 (PST) From: "Santosh Chokhani" To: "'Dan Brown'" , "'Peter Gutmann'" , "'Phillip Hallam-Baker'" , "'IETF SAAG'" References: <1579100916686.94828@cs.auckland.ac.nz> <5fd6bac7558d45fcac94119e746d7d0e@blackberry.com> In-Reply-To: <5fd6bac7558d45fcac94119e746d7d0e@blackberry.com> Date: Thu, 16 Jan 2020 12:41:36 -0500 Message-ID: <064801d5cc94$3403ad60$9c0b0820$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKl11GAQLD3rY2S+c7LAPGMdstm3gLEHkejAbgA8LOmKZbvIA== Content-Language: en-us Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 17:41:44 -0000 There is a paper I wrote circa 1995-96 on parameter substitution related attack and developed a state machine for parameter inheritance for signature verification in certificate chain and CRLs. -----Original Message----- From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Dan Brown Sent: Thursday, January 16, 2020 11:41 AM To: Peter Gutmann ; Phillip Hallam-Baker ; IETF SAAG Subject: Re: [saag] NSA bug in Windows 10 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. From nobody Thu Jan 16 20:02:32 2020 Return-Path: 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 ; 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 ; 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 ; 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 To: Dan Brown Cc: Peter Gutmann , Phillip Hallam-Baker , IETF SAAG Message-ID: <20200117040214.GR80030@kduck.mit.edu> References: <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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nobody Thu Jan 16 22:54:34 2020 Return-Path: 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 04E68120236 for ; Thu, 16 Jan 2020 22:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 6Rj7TALQARHa for ; Thu, 16 Jan 2020 22:54:29 -0800 (PST) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 A08F6120046 for ; Thu, 16 Jan 2020 22:54:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1579244069; x=1610780069; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gT2UbGudngdFeGILGvIuzYImJv4ncKgUb/CZZC7sn6E=; b=KXclAi5+s1Aysihq80yTkLIk+CbrU8Xj2qts1tD2UY2BZcYerEai62hc hFeOMKvm7NlDkIHXfZrFrj4JapGdAlMClJjn6sYq1tcTOatBgrRrORSmY B4PZNU8Sfi5JjCtwlwXOtzyy37lUSu8Z4L8RJvUdgUC1fmRBiVVzm/2fl YCBctdOVqrXotdnMCN4P45zEc1VpDuPWtW8GdsGjvOvAhxS5hAA0oarBH FpyJvaUVyD8NsQDoJV9CGSUl+WpmVZXJHD69i/E5ehj034wIx2bttPX/J mEwhV+obiD9L9wUAPZQoJbRDclmneISbGcoC3hyKxykojDJnoPBmoqR91 A==; X-IronPort-AV: E=Sophos;i="5.70,329,1574074800"; d="scan'208";a="110195604" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.3 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-tdc-b.UoA.auckland.ac.nz) ([10.6.3.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 17 Jan 2020 19:54:26 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-b.UoA.auckland.ac.nz (10.6.3.3) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 17 Jan 2020 19:54:26 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Fri, 17 Jan 2020 19:54:25 +1300 From: Peter Gutmann To: Benjamin Kaduk , Dan Brown CC: Phillip Hallam-Baker , IETF SAAG Thread-Topic: [saag] NSA bug in Windows 10 Thread-Index: AQHVy7SFV0v01oMYaUOc3bty1eNrZafr0x0xgADS7ICAAL5tAIABCdjZ Date: Fri, 17 Jan 2020 06:54:25 +0000 Message-ID: <1579244066105.22121@cs.auckland.ac.nz> References: <1579100916686.94828@cs.auckland.ac.nz> <5fd6bac7558d45fcac94119e746d7d0e@blackberry.com>, <20200117040214.GR80030@kduck.mit.edu> In-Reply-To: <20200117040214.GR80030@kduck.mit.edu> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 06:54:32 -0000 Benjamin Kaduk writes:=0A= =0A= >I remember reading something that involved [...]=0A= =0A= Based on, admittedly, zero reading of stuff around this so far (trying to f= ind=0A= some time this weekend), I assume it's of the type covered here:=0A= =0A= Digital Signature Schemes with Domain Parameters=0A= https://lasec.epfl.ch/pub/lasec/doc/Vau04b.pdf=0A= =0A= Or at least that's one possible vuln that you get from not checking domain= =0A= parameters.=0A= =0A= Peter.=0A= From nobody Fri Jan 17 05:36:40 2020 Return-Path: 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 75B9F12004E for ; Fri, 17 Jan 2020 05:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 1DQw7I2Pee0d for ; Fri, 17 Jan 2020 05:36:35 -0800 (PST) Received: from esa2.isaracorp.com (esa2.isaracorp.com [207.107.152.176]) (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 0697612001A for ; Fri, 17 Jan 2020 05:36:34 -0800 (PST) IronPort-SDR: hO4xHeqM782UMCV8tKJNYtgVJGclkyJmvjGG762t/FoUX19Zf7Zi8dPJn+s94POnM9MrRsCTuz tr3X+flog0WdoAhUj8fU3+xrJ3rjZdjbiSowOS8kEdZvH+3h8FD39aBn1+Q1HjAMkpImlirHJa 8GasSyHx4SmW1J2JHijbJocQBKhAiSUPDbnAfHOPU2J3iBKxhGBSquPyyReW2Ke4PdKbDMDH8f m6BK+ysVA0/I2xQllEFbZDgjI6GB+rXIyvoP+Rrn3GLKfxhmCzOn7S7nV5zeZ+JKpq76CQ+BkM tZ4= X-URL-LookUp-ScanningError: 1 Received: from unknown (HELO V0501WEXGPR01.isaracorp.com) ([10.5.8.20]) by ip2.isaracorp.com with ESMTP; 17 Jan 2020 13:36:30 +0000 Received: from V0501WEXGPR01.isaracorp.com (10.5.8.20) by V0501WEXGPR02.isaracorp.com (10.5.9.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1847.3; Fri, 17 Jan 2020 08:37:06 -0500 Received: from V0501WEXGPR01.isaracorp.com ([fe80::d802:5aec:db34:beba]) by V0501WEXGPR01.isaracorp.com ([fe80::d802:5aec:db34:beba%7]) with mapi id 15.01.1847.005; Fri, 17 Jan 2020 08:37:06 -0500 From: Daniel Van Geest To: Peter Gutmann , Benjamin Kaduk , Dan Brown CC: IETF SAAG Thread-Topic: [External]Re: [saag] NSA bug in Windows 10 Thread-Index: AQHVzTs1pVBAbScFtUeDqEEHLtV82Q== Date: Fri, 17 Jan 2020 13:37:06 +0000 Message-ID: <47B98698-1B77-498C-983C-F0CD6D3515CF@isara.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.5.52] Content-Type: multipart/alternative; boundary="_000_47B986981B77498C983CF0CD6D3515CFisaracom_" MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 13:36:39 -0000 --_000_47B986981B77498C983CF0CD6D3515CFisaracom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGJlc3Qgc3VtbWFyeSBJ4oCZdmUgc2VlbiBpcyBoZXJlOg0KaHR0cHM6Ly9ibG9nLnRyYWls b2ZiaXRzLmNvbS8yMDIwLzAxLzE2L2V4cGxvaXRpbmctdGhlLXdpbmRvd3MtY3J5cHRvYXBpLXZ1 bG5lcmFiaWxpdHkvDQoNCkluIHNob3J0LCBhIHJlY2VpdmVkIHJvb3Qgd2FzIGJlaW5nIGNvbXBh cmVkIHRvIHRoZSB0cnVzdGVkIHJvb3QgYmFzZWQgb25seSBvbg0KdGhlIHB1YmxpYyBrZXksIGJ1 dCB0aGUgcHJpdmF0ZSBrZXkgYW5kIHBhcmFtZXRlcnMgb2YgdGhlIHJlY2VpdmVkIHJvb3Qgd2Fz DQpnZW5lcmF0ZWQgZnJvbSB0aGUgdHJ1c3RlZCBwdWJsaWMga2V5IHVzaW5nIFZhdWRlbmF5LiAg VGhlbiB2ZXJpZmljYXRpb24gd2FzDQpkb25lIHVzaW5nIHRoZSByZWNlaXZlZCByb290IHNpbmNl IGl0IHdhcyDigJx0aGUgc2FtZeKAnSBhcyB0aGUgdHJ1c3RlZCByb290Lg0KDQpEYW5pZWwgVmFu IEdlZXN0DQoNCg0KT24gMjAyMC0wMS0xNywgNjo1NSBBTSwgInNhYWcgb24gYmVoYWxmIG9mIFBl dGVyIEd1dG1hbm4iIDxzYWFnLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNhYWctYm91bmNlc0Bp ZXRmLm9yZz4gb24gYmVoYWxmIG9mIHBndXQwMDFAY3MuYXVja2xhbmQuYWMubno8bWFpbHRvOnBn dXQwMDFAY3MuYXVja2xhbmQuYWMubno+PiB3cm90ZToNCg0KQmVuamFtaW4gS2FkdWsgPGthZHVr QG1pdC5lZHU8bWFpbHRvOmthZHVrQG1pdC5lZHU+PiB3cml0ZXM6DQoNCkkgcmVtZW1iZXIgcmVh ZGluZyBzb21ldGhpbmcgdGhhdCBpbnZvbHZlZCBbLi4uXQ0KDQpCYXNlZCBvbiwgYWRtaXR0ZWRs eSwgemVybyByZWFkaW5nIG9mIHN0dWZmIGFyb3VuZCB0aGlzIHNvIGZhciAodHJ5aW5nIHRvIGZp bmQNCnNvbWUgdGltZSB0aGlzIHdlZWtlbmQpLCBJIGFzc3VtZSBpdCdzIG9mIHRoZSB0eXBlIGNv dmVyZWQgaGVyZToNCg0KRGlnaXRhbCBTaWduYXR1cmUgU2NoZW1lcyB3aXRoIERvbWFpbiBQYXJh bWV0ZXJzDQpodHRwczovL2xhc2VjLmVwZmwuY2gvcHViL2xhc2VjL2RvYy9WYXUwNGIucGRmDQoN Ck9yIGF0IGxlYXN0IHRoYXQncyBvbmUgcG9zc2libGUgdnVsbiB0aGF0IHlvdSBnZXQgZnJvbSBu b3QgY2hlY2tpbmcgZG9tYWluDQpwYXJhbWV0ZXJzLg0KDQpQZXRlci4NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNhYWcgbWFpbGluZyBsaXN0DQpz YWFnQGlldGYub3JnPG1haWx0bzpzYWFnQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zYWFnDQoNCg== --_000_47B986981B77498C983CF0CD6D3515CFisaracom_ Content-Type: text/html; charset="utf-8" Content-ID: <5AA28370EECF8A48B536322CF9A950F3@isara.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tQ0Ei IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBiZXN0IHN1bW1hcnkgSeKAmXZlIHNlZW4gaXMgaGVy ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8v YmxvZy50cmFpbG9mYml0cy5jb20vMjAyMC8wMS8xNi9leHBsb2l0aW5nLXRoZS13aW5kb3dzLWNy eXB0b2FwaS12dWxuZXJhYmlsaXR5LyI+aHR0cHM6Ly9ibG9nLnRyYWlsb2ZiaXRzLmNvbS8yMDIw LzAxLzE2L2V4cGxvaXRpbmctdGhlLXdpbmRvd3MtY3J5cHRvYXBpLXZ1bG5lcmFiaWxpdHkvPC9h PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBzaG9ydCwgYSByZWNlaXZlZCByb290IHdhcyBi ZWluZyBjb21wYXJlZCB0byB0aGUgdHJ1c3RlZCByb290IGJhc2VkIG9ubHkgb248bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBwdWJsaWMga2V5LCBidXQgdGhlIHByaXZh dGUga2V5IGFuZCBwYXJhbWV0ZXJzIG9mIHRoZSByZWNlaXZlZCByb290IHdhczxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Z2VuZXJhdGVkIGZyb20gdGhlIHRydXN0ZWQgcHVi bGljIGtleSB1c2luZyBWYXVkZW5heS4gJm5ic3A7VGhlbiB2ZXJpZmljYXRpb24gd2FzPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kb25lIHVzaW5nIHRoZSByZWNlaXZlZCBy b290IHNpbmNlIGl0IHdhcyDigJx0aGUgc2FtZeKAnSBhcyB0aGUgdHJ1c3RlZCByb290LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5EYW5pZWwgVmFuIEdlZXN0PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiAyMDIwLTAxLTE3LCA2OjU1IEFNLCAm cXVvdDtzYWFnIG9uIGJlaGFsZiBvZiBQZXRlciBHdXRtYW5uJnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86c2FhZy1ib3VuY2VzQGlldGYub3JnIj5zYWFnLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9u IGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOnBndXQwMDFAY3MuYXVja2xhbmQuYWMubnoiPnBn dXQwMDFAY3MuYXVja2xhbmQuYWMubno8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5CZW5qYW1pbiBLYWR1ayAm bHQ7PGEgaHJlZj0ibWFpbHRvOmthZHVrQG1pdC5lZHUiPmthZHVrQG1pdC5lZHU8L2E+Jmd0OyB3 cml0ZXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNCNUM0 REYgNC41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7bWFy Z2luLXJpZ2h0OjBjbSIgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkkg cmVtZW1iZXIgcmVhZGluZyBzb21ldGhpbmcgdGhhdCBpbnZvbHZlZCBbLi4uXTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5C YXNlZCBvbiwgYWRtaXR0ZWRseSwgemVybyByZWFkaW5nIG9mIHN0dWZmIGFyb3VuZCB0aGlzIHNv IGZhciAodHJ5aW5nIHRvIGZpbmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPnNvbWUgdGltZSB0aGlz IHdlZWtlbmQpLCBJIGFzc3VtZSBpdCdzIG9mIHRoZSB0eXBlIGNvdmVyZWQgaGVyZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+RGlnaXRhbCBTaWdu YXR1cmUgU2NoZW1lcyB3aXRoIERvbWFpbiBQYXJhbWV0ZXJzPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48YSBocmVmPSJodHRwczovL2xhc2VjLmVwZmwuY2gvcHViL2xhc2VjL2RvYy9WYXUwNGIucGRm Ij5odHRwczovL2xhc2VjLmVwZmwuY2gvcHViL2xhc2VjL2RvYy9WYXUwNGIucGRmPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PciBhdCBsZWFz dCB0aGF0J3Mgb25lIHBvc3NpYmxlIHZ1bG4gdGhhdCB5b3UgZ2V0IGZyb20gbm90IGNoZWNraW5n IGRvbWFpbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+cGFyYW1ldGVycy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+UGV0ZXIuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5zYWFnIG1h aWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGEgaHJlZj0ibWFpbHRvOnNhYWdAaWV0 Zi5vcmciPnNhYWdAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NhYWciPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_47B986981B77498C983CF0CD6D3515CFisaracom_-- From nobody Fri Jan 17 10:07:38 2020 Return-Path: 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 35579120089 for ; Fri, 17 Jan 2020 10:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 qd1yHLeMpmcl for ; Fri, 17 Jan 2020 10:07:32 -0800 (PST) Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) (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 249A8120043 for ; Fri, 17 Jan 2020 10:07:32 -0800 (PST) Received: by mail-ot1-f51.google.com with SMTP id w21so23266895otj.7 for ; Fri, 17 Jan 2020 10:07:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0pPmGWcGS0u+19xWBRY60+/Po0iurmfSzpLy7bz7AXI=; b=TO8LfNoye/sv86aWwjxqnLNLyUSPARNx0XEBjO8P9zQ3U7K8wzek+Bhm6UOSb0PoGv HPfDQYTfpskMfS3Z5ag3UKGk8C228uXlG9DKRFh+2GTMMxO3ZWyAVj0hN6fkeiJH9U8n wIH/rQRY1K4xtWYRfP7j15QkTpvkd6g0zsfobULQVQ323BKkw320uVZgC2PQXRnrxlwL T/AOeFbm9nG8ubaHYh7igKEaLjoyXijorIbAp0YVvOIZdbbrJpcyH2AqowEcUN+zBhTf G8LsG2Ye0fAt0mIyvwuclc+5Pq4nLczeQaQ6qhSAL8w66QdN/GKcpR1KDn1nQkUIUZd0 Y2qg== X-Gm-Message-State: APjAAAWrdI4YfclCkQUW3sOeDel38a7cBSV6LHA46sNvWgY+M2uT/ulF 2nj3/n2c58D8xaZYASQ+2fb5QBVNoOhbSMr6UN0= X-Google-Smtp-Source: APXvYqwWkOru2uvkJjXESLimIJXfX829mQ0IKVk7GalYiikq/Y2lZDpvBCVamEzIpPaixKqEUlfPQQzs51FXNMssaqA= X-Received: by 2002:a9d:6758:: with SMTP id w24mr7413889otm.155.1579284451458; Fri, 17 Jan 2020 10:07:31 -0800 (PST) MIME-Version: 1.0 References: <1579100916686.94828@cs.auckland.ac.nz> <5fd6bac7558d45fcac94119e746d7d0e@blackberry.com> <20200117040214.GR80030@kduck.mit.edu> In-Reply-To: <20200117040214.GR80030@kduck.mit.edu> From: Phillip Hallam-Baker Date: Fri, 17 Jan 2020 13:07:19 -0500 Message-ID: To: Benjamin Kaduk Cc: Dan Brown , Peter Gutmann , IETF SAAG Content-Type: multipart/alternative; boundary="000000000000ba8152059c59d044" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 18:07:36 -0000 --000000000000ba8152059c59d044 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 16, 2020 at 11:02 PM Benjamin Kaduk wrote: > 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 > OK so the attack seems to be Root cert specifies Key A = {CurveA, PointA} Root cert signs subordinate cert creating signature {CurveA, PointB} Mallet can now generate a new signature {CurveM, PointB} which will validate because the pathmath isn't checking the domain params, only the curve point. OMG we are doomed. --000000000000ba8152059c59d044 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jan 16, 2020 at 11:02 PM Benjamin Kaduk <= ;kaduk@mit.edu> wrote:
On Thu, Jan 16, 2020 at 04:4= 0:41PM +0000, Dan Brown wrote:
> Based on what I hear others say online, I presume this bug resulted a<= br> > 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#se= ction-6.1.1
> item (d), (4) talks about parameters in the trust anchor certificate, = and
> the next paragraph talks about a "delivered ... trustworthy out-o= f-band".
>
> If my presumption above is correct, then it seems that this part of RF= C3280
> was not followed in this bug, since the parameters were taken from an<= br> > untrustworthy in-band delivery.=C2=A0 =C2=A0That said, I wonder if RFC= 3280 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.=C2=A0 That wo= uld
seem to imply that the trusted root is properly being used, but the
validation code for the signatures in the chain was flawed.

-Ben

OK so the attack seems to be

Root cert specifies Key A =3D {CurveA, PointA}

Root cert signs subordinate = cert creating signature=C2=A0{CurveA, PointB}

Mallet can now generate a new= signature {CurveM, PointB} which will validate because the pathmath isn= 9;t checking the domain params, only the curve point.

OMG we are doomed.


=C2=A0
--000000000000ba8152059c59d044-- From nobody Fri Jan 17 10:47:42 2020 Return-Path: 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 1F129120043 for ; Fri, 17 Jan 2020 10:47:40 -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 LZBmgXwtln3s for ; Fri, 17 Jan 2020 10:47:37 -0800 (PST) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A461C120025 for ; Fri, 17 Jan 2020 10:47:37 -0800 (PST) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 0337B43181; Fri, 17 Jan 2020 13:47:37 -0500 (EST) Date: Fri, 17 Jan 2020 13:47:36 -0500 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20200117184736.GU73491@straasha.imrryr.org> Reply-To: saag@ietf.org References: <1579100916686.94828@cs.auckland.ac.nz> <5fd6bac7558d45fcac94119e746d7d0e@blackberry.com> <20200117040214.GR80030@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 18:47:40 -0000 On Fri, Jan 17, 2020 at 01:07:19PM -0500, Phillip Hallam-Baker wrote: > OK so the attack seems to be > > Root cert specifies Key A = {CurveA, PointA} In particular, the curve coefficients, the curve *generator* and the root CA's public key (point). > Root cert signs subordinate cert creating signature {CurveA, PointB} The attacker creates a fake root cert with a different *generator*, the simplest case is 'generator == public point, private key = 1'. > Mallet can now generate a new signature {CurveM, PointB} which will > validate because the pathmath isn't checking the domain params, only the > curve point. Mallet can generate any desired certificate chain with the new root CA key. No need to match anything pre-existing. The new chains will pass validation. -- Viktor. From nobody Fri Jan 17 10:54:52 2020 Return-Path: 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 9AD691200A4 for ; Fri, 17 Jan 2020 10:54:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9zneRQgeaOCs for ; Fri, 17 Jan 2020 10:54:47 -0800 (PST) Received: from smtp-pc10.blackberry.com (smtp-pc10.blackberry.com [74.82.81.42]) (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 143311200B5 for ; Fri, 17 Jan 2020 10:54:46 -0800 (PST) Received: from pps.filterd (mhs400cnc.rim.net [127.0.0.1]) by mhs400cnc.rim.net (8.16.0.27/8.16.0.27) with SMTP id 00HIprqs036693; Fri, 17 Jan 2020 13:54:30 -0500 Received: from xct105cnc.rim.net (xct105cnc.rim.net [10.65.161.205]) by mhs400cnc.rim.net with ESMTP id 2xkc469147-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Jan 2020 13:54:28 -0500 Received: from XCH213CNC.rim.net (10.3.27.118) by XCT105CNC.rim.net (10.65.161.205) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 17 Jan 2020 13:54:28 -0500 Received: from XCH210YKF.rim.net (10.2.27.110) by XCH213CNC.rim.net (10.3.27.118) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Fri, 17 Jan 2020 13:54:27 -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; Fri, 17 Jan 2020 13:54:27 -0500 From: Dan Brown To: Benjamin Kaduk CC: Peter Gutmann , Phillip Hallam-Baker , IETF SAAG Thread-Topic: [saag] NSA bug in Windows 10 Thread-Index: AQHVy7SGNI3L+VtQR0yNz6MvRiowqqfsJ7uAgAFTuGCAARbCAIAAm+mg Date: Fri, 17 Jan 2020 18:54:27 +0000 Message-ID: References: <1579100916686.94828@cs.auckland.ac.nz> <5fd6bac7558d45fcac94119e746d7d0e@blackberry.com> <20200117040214.GR80030@kduck.mit.edu> In-Reply-To: <20200117040214.GR80030@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [100.64.97.122] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_008D_01D5CD3D.9D648F50" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-17_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-2001170144 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 18:54:50 -0000 ------=_NextPart_000_008D_01D5CD3D.9D648F50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Benjamin Kaduk > > > > 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. Well, that attack does not match what I read. In what I read, a fake root cert is sent, and the receiver uses it. Some claim the bug is an incomplete match between the fake and real root cert, but I claim the real bug is using the received cert at all. The receiver should just use the real root cert. The receiver should keep a full copy of the real root cert, to do this. The receiver should discard received root cert. (But, perhaps, if the sender sends a root cert, then the receiver may insist on an exact match, although such checks might allow 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'? RFC 3280 is written as if the receiver did not have the real root cert C0, but, for some reason has enough information about C0 to conduct a partial - but secure if all the steps are done - match with a sent version C0' of C0. 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. By the way, new algorithms, from the land of PQC, are arriving soon, to a PKI near you. Off hand, I have no clue what parameters these new algorithms. But I guess that they will ship with some kind of parameters, since both the new algorithms and quantum computer are a moving target. Instead of decrying parameters, just verify the signed parameters, use a real root for the root parameters. ---------------------------------------------------------------------- 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. ------=_NextPart_000_008D_01D5CD3D.9D648F50 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCIdUw ggXJMIIDsaADAgECAgUA9lfgwDANBgkqhkiG9w0BAQ0FADB8MQswCQYDVQQGEwJDQTEbMBkGA1UE CgwSQmxhY2tCZXJyeSBMaW1pdGVkMSIwIAYDVQQLDBlCbGFja0JlcnJ5IEVudGVycHJpc2UgUEtJ MSwwKgYDVQQDDCNCbGFja0JlcnJ5IEVudGVycHJpc2UgUlNBIFJvb3QgQ0EgMTAeFw0xMzEyMTMx NzQ1NDdaFw0zODEyMTMxNzQ1NDdaMHwxCzAJBgNVBAYTAkNBMRswGQYDVQQKDBJCbGFja0JlcnJ5 IExpbWl0ZWQxIjAgBgNVBAsMGUJsYWNrQmVycnkgRW50ZXJwcmlzZSBQS0kxLDAqBgNVBAMMI0Js YWNrQmVycnkgRW50ZXJwcmlzZSBSU0EgUm9vdCBDQSAxMIICIDANBgkqhkiG9w0BAQEFAAOCAg0A MIICCAKCAgEAxkXAf/EHxa1okuoiPnKhHeaDfSRXq35g7JH34MqiM2cxMsL+WMe/8792DLEAe5Lm FLURmrkBiqwgzkrpejF1WBUaqrM0nGSkxTfO9ywXFHKZnK2wyxE+uNdIN5KzuzijEFJpnHxapdJg k8VmsgSnn+wTyRF8J/2DsaKV7UPYNkoGGZtCggI6Dh92G9AUKzZBSjfaZRfwStEv26wVgM8CiqSa O2FuwYriu+To03yDNiC0XOaGbPLyPAdyJbY71Bud3RQE1wciQV0nLwXnyCBmDK127NkjdewY4nAF TVuKaTVCqAdGKRo5idywpSHknZy01AvOJNuvL/BkN9Nv9nflelSml5TJNhfSa2hDRmHvr0+Jns+A qORC2WlvCybRGHkmTjpYLLMnIVprNBWPCCE6B/RaoLvcTvDeUwBVoqYzLSfLT6jAoXVcJM+XT948 TzAgCKcJg4oupgiMtYyL/oktajJbnpiLtRZ3jRX2hEgRW8tJZckvlxtrBGxQLYWNVe48OdBhbNnO bByGN2o0/GAttfkM8WrdjnCNv5YZ1d1eZPqCJicQ7ML4xRzUPwD1u7YvgdVRFidB3CsxM9nnlnam MYWQIV5nUuyK/1NUTiAEhGBYOsLeemgvPz41TsjERujbzHcj8MM3zMdwhWr86Dp1292C/bwyNgMm OfVgsHnZRnECAQOjVDBSMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQW BBT4aYn4Y57vaF6BMGJwUqMO3bKWCDAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG9w0BAQ0FAAOC AgEArBVGo/mS9/+yWzGI03ae5osTFt3v2acQVj1OrqSABZQXTdOXjJL31Q4QJABZlwllzKeIlFne 3c9yn39i3QMhoSjqkn4NjbPjKiiyzOLoI0PGq5UTQtpGm7X/EaXkcYDFhrIHnGfC9dmB5WeuwMwX fmKwUtiLPhgtgjGBqkxSOiFFbBUBiLGs/muE4IYbKJGPKqilOBLpeK1Kyp8zXIrJLLQ0zzkK6TkQ x6RULQ+px3geS5UWkrsFXCHK/x9vBxH313O7RV7vvwt2Opc0HFw9LzF50jie/wqx9HD3tm0GgvqD Aabtlao1V1mfLpk8k+nrWd589ZZSHmQMVFvzETnrS0BS4wZssImORAbv6tVCHZSf6gu1XApnxMaM Hy8qmL9lfkoTaxF7cxzzwrj5P49Xj+n4NZT95GyYNAoU3AhAFrQV+H6BXFTOHNX/ALubYWg5x+xu JFi+7HTcaCjZzjSGLWG3kilqn6JkT229jgYClzN8EylemXv3yz1vVjXbTRZNDK9G/p1Jj2SxlBC/ mTBvedATbkIMVm5Wzl8cE3rIp+A9lZ+bS9CfVx5OthHQxXn0fuVCakWp4a+KTsTtFlqbtVMesdcU Q1uMk8Tap11X43bkAyX25l76ejxuVCZYZaOxZFt689bVqRFh4DjyfagCRu65eQgOu013aZiAc28i WCEwggdJMIIGMaADAgECAgpyAx1HAAEAAlASMA0GCSqGSIb3DQEBCwUAMFYxEzARBgoJkiaJk/Is ZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xKjAoBgNVBAMTIUJsYWNrQmVycnkgQ29ycG9y YXRlIElzc3VpbmcgQ0EgMTAeFw0xOTA0MTcyMDU4MjRaFw0yMDAyMjYyMjM2NTVaMIGpMRMwEQYK CZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMQ0wCwYDVQQLEwRBTUVSMQswCQYD VQQLEwJDQTEUMBIGA1UECxMLTWlzc2lzc2F1Z2ExDjAMBgNVBAsTBVVzZXJzMRIwEAYDVQQDEwlE YW4gQnJvd24xJzAlBgkqhkiG9w0BCQEWGGRhbmlicm93bkBibGFja2JlcnJ5LmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALQHoYbI3q25dSCAl6YGPubc51/jvsRg5VZl6f8cADT/ N6anVBzRl77zYVSEmqlrHG2/x++rOxdzcAi/LP+L7IEiU/TX+EyPR4OSLf3sQTJg/CzZLhKT+ouR CH1jn0QgFviHE4Ni0no/E4x+N0zjmhWpF7WcoaNbY0ZVW5g1jy7KtEoLwDGFylPVsrwLMzud4wjJ 32R/McoCAqaWr/vgUOoHYY6K+5fGp7wNyvhhc0sG+8ku2vNWhBo7sufwdehGISQsaBXS+Wqgy7g1 qNePiR/5i8OFgEFjO//iozFIeTPoFbSd+k4y/jv7wD+yLvVy84q9LteXpv92aFR+aTJxkEkCAwEA AaOCA8MwggO/MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIe/l0uGuYEkhsGBMoPb8iWC3NgB gQCxwyqHn/RAAgFkAgELMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjALBgNVHQ8EBAMC BsAwDAYDVR0TAQH/BAIwADBPBgNVHSABAf8ERTBDMEEGCisGAQQBm0oTAQIwMzAxBggrBgEFBQcC ARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTAnBgkrBgEEAYI3FQoEGjAY MAoGCCsGAQUFBwMEMAoGCCsGAQUFBwMCMB0GA1UdDgQWBBTb4N+ts9rY1LbQOi40ca8/M4cXVTAf BgNVHSMEGDAWgBQaL0tL2wfJSTuJ1jIIJ6KeC/MPazCCATIGA1UdHwSCASkwggElMIIBIaCCAR2g ggEZhkBodHRwOi8vY3JsLnJpbS5uZXQvQmxhY2tCZXJyeSUyMENvcnBvcmF0ZSUyMElzc3Vpbmcl MjBDQSUyMDEuY3JshoHUbGRhcDovLy9DTj1CbGFja0JlcnJ5JTIwQ29ycG9yYXRlJTIwSXNzdWlu ZyUyMENBJTIwMSxDTj1NQ0EwMTBDTkMsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2Vz LENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZp Y2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQw ggEDBggrBgEFBQcBAQSB9jCB8zAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AucmltLm5ldC9vY3Nw MIHKBggrBgEFBQcwAoaBvWxkYXA6Ly8vQ049QmxhY2tCZXJyeSUyMENvcnBvcmF0ZSUyMElzc3Vp bmclMjBDQSUyMDEsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jQUNlcnRpZmljYXRlP2Jhc2U/ b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBNBgNVHREERjBEoCgGCisGAQQBgjcU AgOgGgwYZGFuaWJyb3duQGJsYWNrYmVycnkuY29tgRhkYW5pYnJvd25AYmxhY2tiZXJyeS5jb20w DQYJKoZIhvcNAQELBQADggEBAEoWAOg0VEQNS86VaoPS9opseSqdMyxa/SyUNcoqeTRgadtmv1FX zUPytJUDgHQrMAmpHCurdPASknaqoHOaOyTf2AfJO9a36jIq+yC+7ybZFfiXOaFKOvAcDOpS0O25 PVZdG202Nt/g5hrOyd/hUplu0xz4h8CvihzW7AuUsBOBJn7vW5dvggrRx28FSBUARj4plfhNoGoI XJfFghQ1fWmjg8o9NjhTpXKDTy7kMNkUX2g+HACq4tzf0sjthqTFpGsAq+PhqFxKQLZ8GRAq67F+ mHWEvZArnHnDAk4JpqlGMZTVXRWZzW+21feqnog1FU6kgtM5/8uvtrEMQSe8Dn8wgggFMIIF7aAD AgECAgRDFVhfMA0GCSqGSIb3DQEBDQUAMHwxCzAJBgNVBAYTAkNBMRswGQYDVQQKDBJCbGFja0Jl cnJ5IExpbWl0ZWQxIjAgBgNVBAsMGUJsYWNrQmVycnkgRW50ZXJwcmlzZSBQS0kxLDAqBgNVBAMM I0JsYWNrQmVycnkgRW50ZXJwcmlzZSBSU0EgUm9vdCBDQSAxMB4XDTE0MDIyNjE2MjM1NloXDTI0 MDIyNjE2MjM1NloweTELMAkGA1UEBhMCQ0ExGzAZBgNVBAoMEkJsYWNrQmVycnkgTGltaXRlZDEi MCAGA1UECwwZQmxhY2tCZXJyeSBFbnRlcnByaXNlIFBLSTEpMCcGA1UEAwwgQmxhY2tCZXJyeSBD b3Jwb3JhdGUgUG9saWN5IENBIDEwggIgMA0GCSqGSIb3DQEBAQUAA4ICDQAwggIIAoICAQC6JvZA kPpT2uIOJ8w4/hBW8IhdwmDtvzMEVmnYEmmr1cnQaD3NVSIxDfNFG2dVVeZJB4qmLwLkjMf0dgDo LtaPRaqZ2kW+fWuEeWqG4sRxCIWMgrdppkQoCenWGIiW7Q59bdNLk9MsiP2FPgFMVhSvXN38vl9t AEssQDmwPVnr9nBbBhW4OnaM2JDw0B5YEnMyXBJwslA+n4YDOTfzbIB5rzdzkG/Cy+Ss7NtOEIG1 Hfeur5RzruqaVRINsbk884T1TjR4q2BMhTE2uSjaANXkl+IM1YsfmIgCj/AKr4KhEAeM4to10mA8 3fUVLZzn5YPo8/jikzQ0qTge/7Yj2veffvkYkWG1pZGJvlofl/bi/62vrmrTkx9lDKLMl5zuK8qF znvSWVhntGsHWO0ZI+uSz5h7Alr0dOTdTOr1+SR2SzqL+uReyf2ViywiAEf7JtZj4QU2rlN7rxOi Suf7mz0D8RelA6TXaGlAe/q35kqAcciJZjMugO7+XG2chzjci5c/q+LJJTwz3M+QgSI21MhTcytC itBl0WFSg/vmE26nQnuryhWUoNvryGEP2xarae/oCiKZo41nc6LcVXCoJfq/pE5OKUhAi1N/RH26 OdDb3kOjdDdLIKY/yVThed1zESsuCUNkgy9APj5LgS95nSG/oQ9LlLL5g4YQd8WrwdFIZQIBA6OC ApIwggKOMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQ7uMF3 DZ6tQ1j8Ja4V0LfykTKFmzAfBgNVHSMEGDAWgBT4aYn4Y57vaF6BMGJwUqMO3bKWCDCBhgYIKwYB BQUHAQEEejB4MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5yaW0ubmV0L29jc3AwUAYIKwYBBQUH MAKGRGh0dHA6Ly9jcnQucmltLm5ldC9CbGFja0JlcnJ5JTIwRW50ZXJwcmlzZSUyMFJTQSUyMFJv b3QlMjBDQSUyMDEuY3J0MIIBNwYDVR0fBIIBLjCCASowggEmoIIBIqCCAR6GRGh0dHA6Ly9jcmwu cmltLm5ldC9CbGFja0JlcnJ5JTIwRW50ZXJwcmlzZSUyMFJTQSUyMFJvb3QlMjBDQSUyMDEuY3Js hoHVbGRhcDovLy9DTj1CbGFja0JlcnJ5JTIwRW50ZXJwcmlzZSUyMFJTQSUyMFJvb3QlMjBDQSUy MDEsQ049Um9vdENBLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNl cyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0 aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MDcGA1UdIAQwMC4w LAYEVR0gADAkMCIGCCsGAQUFBwIBFhZodHRwOi8vY3AucmltLm5ldC9jcHMvMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA0GCSqGSIb3DQEBDQUAA4ICAQC38TN+ EWKxTPBOf+yu0+eJD75HI0K1/VbX+/gkxxxthB+0rhaBVrJzU3j/ifE8ST9Icc+JgORZzCjZYUz7 Lj9DbvxbtUdaJGi7CHjjxgFm7aQkPX2BvpYHjjYeQ0349boayww1AG6iX42F/Gm+P4/UT4Jv5lo5 UepzMz8mgnOnAEqpzo7NFUixXZnLTTML6g8Co+Kpwl/gDOtTcXdit2SE4qugUCI9+4UIdO5cIFUK 2vkuev3JsjuUCl0p8g/591PyDxIUoRWt9I+8nkeDmdhr/Lyuh2OY82OXqCc7TdPPRdJdo0nWCJZu OxPrK1cJPPM/FMM7EwSruS1mFbMsHyXcmUBdfm8LudkPHPpszGlQ2cAcENzgyGCd2OWlggpp+y35 JIo9eKnLC5BGio6eno6MvfNMM5DzIr5hoVfLsbJUvlIIwOaqhWWPIjiQJgS8vAAZBONh6AXXs8TA smu0yt2cSp00HvUWAyJi8eOVUOiu+f7iXXUw+xhEcOyggo4JmJ4g+qM8wzx8pc4soKVMx4SLXXlR /uO3RNZ5ZNaVc3+qIqg4EbhGNQxyCGChFYemYvRdLmjqO0sGfofYaqRdhIBpKZYk7vDOwj0ZStzg TT55OAYF0jY+A9RXSiu6xm04F3C/2G7S19sHlhK28Prjf1Ahu5NwTnpaKdM5UiX4/SrKLTCCDK4w ggqWoAMCAQICBAsRTXAwDQYJKoZIhvcNAQELBQAweTELMAkGA1UEBhMCQ0ExGzAZBgNVBAoMEkJs YWNrQmVycnkgTGltaXRlZDEiMCAGA1UECwwZQmxhY2tCZXJyeSBFbnRlcnByaXNlIFBLSTEpMCcG A1UEAwwgQmxhY2tCZXJyeSBDb3Jwb3JhdGUgUG9saWN5IENBIDEwHhcNMTkwMjI2MjIzNjU1WhcN MjAwMjI2MjIzNjU1WjBWMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmlt MSowKAYDVQQDEyFCbGFja0JlcnJ5IENvcnBvcmF0ZSBJc3N1aW5nIENBIDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDVHL/KEgF8NzTToTzGn4ZzdjfvMRN9YG1zaPkekwXrknWRKOTw 30fjw6bP7CF60nnJwGSVhoQ1DkNqVz0ZPI35dJW3EBEUyNVAtOGb+fiNmDsOKk2gbe+zwLb1ttrN 7BOgIDuqJKlujUBYxBk6Cl44KOoKwSzuvxuFHP7T6oev23Jh+DZmkm7M60iVLDzHjchFru696K8b vSiczJw0AVqWymaupeFveprrdJUz1y/G0Q0GoeZ3NFH0azM8JS6MB7Sz1zO/9SdlxvrRu0mCEN8E OgUTfG1l1sDILs7IhM9gUBF+tHJpeFc+xuSHpx7spkRzhESmuFD4h+6IIJ/B7SofAgMBAAGjgghf MIIIWzASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUGi9LS9sH yUk7idYyCCeingvzD2swHwYDVR0jBBgwFoAUO7jBdw2erUNY/CWuFdC38pEyhZswgYEGCCsGAQUF BwEBBHUwczAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AucmltLm5ldC9vY3NwMEsGCCsGAQUFBzAC hj9odHRwOi8vY3J0LnJpbS5uZXQvQmxhY2tCZXJyeSUyMENvcnBvcmF0ZSUyMFBvbGljeSUyMENB JTIwMS5jcnQwggEsBgNVHR8EggEjMIIBHzCCARugggEXoIIBE4Y/aHR0cDovL2NybC5yaW0ubmV0 L0JsYWNrQmVycnklMjBDb3Jwb3JhdGUlMjBQb2xpY3klMjBDQSUyMDEuY3JshoHPbGRhcDovLy9D Tj1CbGFja0JlcnJ5JTIwQ29ycG9yYXRlJTIwUG9saWN5JTIwQ0ElMjAxLENOPVN1YkNBLENOPUNE UCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9u LERDPXdpbmRvd3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVj dENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIGEgYDVR0gBIIGCTCCBgUwQQYKKwYBBAGbShQC ATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEG CisGAQQBm0oTAQMwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVt ZW50Lmh0bTBBBgorBgEEAZtKEwECMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nw cy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3Au cmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTAgMwMzAxBggrBgEFBQcCARYl aHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwICMDMwMQYI KwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGb ShMCATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRt MEEGCisGAQQBm0oTAwMwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3Rh dGVtZW50Lmh0bTBBBgorBgEEAZtKEwMCMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0 L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMDATAzMDEGCCsGAQUFBwIBFiVodHRwOi8v Y3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTBAAwMzAxBggrBgEFBQcC ARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwUDMDMw MQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYB BAGbShMFAjAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQu aHRtMEEGCisGAQQBm0oTBQEwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQ U3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwYDMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0u bmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMGAjAzMDEGCCsGAQUFBwIBFiVodHRw Oi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTBgEwMzAxBggrBgEF BQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwcD MDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYK KwYBBAGbShMHAjAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1l bnQuaHRtMEEGCisGAQQBm0oTBwEwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3Bz L0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwgDMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5y aW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMIAjAzMDEGCCsGAQUFBwIBFiVo dHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTCAEwMzAxBggr BgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTAQBgkrBgEEAYI3 FQEEAwIBATAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTANBgkqhkiG9w0BAQsFAAOCAgEAbML2 XftFHnmxEj1R+YXOw1IvY2cr3KtA2X5HweMk8WeDorircFlDGIP09Dgj2eEn7F8yg4vevOjtOj/O u+nMfxe2XdsxqbkOfOGncy2IQY0jp8Dznqg7iTJm2q5Rz+RhyICipwRhXVGhPz+UaBqzgPMRbOCy GVJFOfzIvI6IAARtWbFpDCIkIliQ36kd8UlXuAeCOqwLOQSenuL4kV+oaCKu1mNz3hC5jurnrTrt gPDYG0koEg40cxd4rv7Dy78U9jps82PFiMiA+yomtYZEsveyHHdsPupz8BN2Q6Oww99nR1ME+ING FK9r7dhEj6xAMVJ/eS2JHwtNSU3gxhhcQm/ZaP8Isfc7JKSI86II78DCyVVAJrMrt+pkNYWw8KDi yxuN5HxfGTBykx9H4lxdDTYT8AS1kf3GJUXo3/8+09g8ZIfbiSm5l96jvAL62ix/aSwFT01T7sTn CgPAcutQSnWoONApDZvqzDSJRwAtdkX+DMn2lDlocTpw99a8WkWJpNyyImvV5OeO/ra5RMCH9f2V /SerRLOQDBIjss7S3x48Fw0VsYxEIBxMV45X47lpwGfXK5oi9OuLGHBkLFavyFpLvbSDpFHfhUiD Ae2DviaDWkyLVZJXWdrujxEW2tchEcuytZw6i9k41/4mgOiy6HYwhRJhknXr5YQJ5wu5rwQxggI8 MIICOAIBATBkMFYxEzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xKjAo BgNVBAMTIUJsYWNrQmVycnkgQ29ycG9yYXRlIElzc3VpbmcgQ0EgMQIKcgMdRwABAAJQEjANBglg hkgBZQMEAgEFAKCBqjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0y MDAxMTcxODU0MTlaMC8GCSqGSIb3DQEJBDEiBCBBZkYpzlAwpDBKV8DR/Hak/CUJg8sjo+vTvmtq kYQuMDA/BgkqhkiG9w0BCQ8xMjAwMAsGCWCGSAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUD BAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUABIIBAD3RrnPBbaASKB+QE+7yUyTa42F5yuu26LYY 3Gg9Q5VbRqpZl44ZLWSIIMCGRy56mzpvHzEjh2MRW5RD0Vl9TxyHkLPWhBP9zBA/SmrwEShwrRas iWAhOCSB9OYzlYP2uTRmXAcAW8pvJC9KYKAj2EK6+QowQC1MIE/y/3AImCVqr27RNmBJNBrUgYet M9PtbmjFEq603kEiFqHJYxGXh2nJsPEPvzxzb1JQ94ox6COWVKj46Nc4e2rwW3pGrda8QqkHKU19 emMjezUqedSfBLQJcQ6juesiSRy/t2zVTXNawukc3jxH1SpKSrhOmgu+BT3UUeEg/aTYfEY4+bAh yrQAAAAAAAA= ------=_NextPart_000_008D_01D5CD3D.9D648F50-- From nobody Fri Jan 17 12:43:34 2020 Return-Path: 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 D78141200F3 for ; Fri, 17 Jan 2020 12:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.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 iJNVNPR1UMi9 for ; Fri, 17 Jan 2020 12:43:24 -0800 (PST) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 CAB8612006B for ; Fri, 17 Jan 2020 12:43:23 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id a13so27770643ljm.10 for ; Fri, 17 Jan 2020 12:43:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BEKZOIx4AXNTOWW97/ua8nO+/hSteLB/EAbk+cmXfBU=; b=WEYU68sIOjxx0m2RA+MlhE78xrCPjSMH21epO4I9omb46Y1+C39tG6CtcvDMBbyoYh wNVTsbnWRP/WkN4bN+c0MX41YmElHK+arUJwmEeYub0TLc2WFkZCFadEsWvbKC2PZMuA PpeHCSyGYwAQ8rugJV2Tfr+Z56vEonmLeuwARy0tc3IVx2b/obWmJO/0ZAVYgVTnGvd1 8ANyJI/IBylNLmAJy+xA5d7B6Dd/TEHbSItCnhKDoTH1tG+XLja+r2bOVpZnSYLucyWV U0oaj3WNGY7FGz92HwRYKf8HOTx6ghzvuNZIKN01puDdrpA5rdVCC7YkcJswyZJSHpxd QJ7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BEKZOIx4AXNTOWW97/ua8nO+/hSteLB/EAbk+cmXfBU=; b=uEcRHMDFVF8AYreF8Gewr4ixF3cJR7sKgT3ttnhGE2A2H+yQyJUdl2bV1tHTaEXTvw MgUKjqRCa1CJcBFQwXpLT6acE59tqW6jdeOoB2DK0VKrGAW0z1LQreeybOH8ZFTaJVpj NwTqrGlg3rTKkhy78MZ5Ajnbgi5P0IeVB5cC70RjWV29kH94V1C0U/H03xA40XT3xpqB YagXnaHlkMxyBV2qpIUigXLJpIf3gNFBQx8sKnx0Fre4fuzHWb/Us0tQGETF3eBud5Gy TTuEEQ+w/8JLu8T/FRvtPhIaGkXt1bJg7opQpuUqkdRjk+c/r/E39Q5fUmhjY7SEQHFj QWKA== X-Gm-Message-State: APjAAAXPnVodTb8wUwVbMCacT32GmEZukW7ZMSEI/ei68SCFmFoLFFBg ipfjZvDK/osnaPkJUjUUaTh0wYLAQ98qRM8vIf4bCKbe4AGg/P8TGMvJZ+G1ezPVeC8iWDAg0oq 5aQ4js9Bq4OrSiY96Sg== X-Google-Smtp-Source: APXvYqymQWziLXd91hPvqIu8c7wVtloY5sq5MuEQ3dibuU9WoxFwVfapyqvnctNRTLKL4OVEBcQk1Np55EdV2pbtfUE= X-Received: by 2002:a2e:9687:: with SMTP id q7mr6494577lji.232.1579293802072; Fri, 17 Jan 2020 12:43:22 -0800 (PST) MIME-Version: 1.0 References: <3088D698-1616-4A74-9CBC-4A9345E46C15@ericsson.com> In-Reply-To: <3088D698-1616-4A74-9CBC-4A9345E46C15@ericsson.com> From: Brian Campbell Date: Fri, 17 Jan 2020 13:42:55 -0700 Message-ID: To: Francesca Palombini Cc: "saag@ietf.org" , "secdispatch@ietf.org" Content-Type: multipart/alternative; boundary="00000000000011a392059c5bfe4e" Archived-At: Subject: Re: [saag] SECDISPATCH WG Summary from IETF 106 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 20:43:27 -0000 --00000000000011a392059c5bfe4e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Apologies folks, I'm responsible for the rushed and awkward presentation about reverse proxies and TLS client certificates at the very end of the SECDISPATCH session in Singapore, which is mentioned below with "no draft yet--> needs draft". It took me a little while to get through the work but I'm happy to share that there is now an actual draft available. Here it is in the fancy new HTML format: https://www.ietf.org/id/draft-bdc-something-something-certificate-01.html as well as the good ol status page: https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/ On Tue, Nov 19, 2019 at 9:34 PM Francesca Palombini wrote: > The SECDISPATCH WG met on Tuesday November 19. The agenda items were > dispatched as follows: > > > > (1) Problem statement for post-quantum multi-algorithm PKI (Max Pala) > > drafts: https://datatracker.ietf.org/doc/draft-pq-pkix-problem-statement= / > > > https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/ > > --> dispatch to LAMPS WG (confirm on mailing list) > > > > (2) OCSPv2 - Improving OCSP Responses (Max Pala) > > LAMPS & PKIX discussions: > > Draft: https://tools.ietf.org/html/draft-pala-ocspv2-00 > > --> create a BoF for small focused WG > > > > (3) Privacy Pass Protocol (Nick Sullivan) > > drafts: https://datatracker.ietf.org/doc/draft-privacy-pass/ > > --> work on charter text then BoF for small focused WG > > > > (4) HTTP Request signing (Justin Richer) > > draft: https://tools.ietf.org/html/draft-cavage-http-signatures > > --> dispatched to HTTPBIS WG > > > > (5) Communication Network Perspective on Malware Lifecycle (Joachim Fabin= i) > > draft: > https://datatracker.ietf.org/doc/draft-fabini-smart-malware-lifecycle/ > > --> check the IAB project (talk to Ted) > > > > (6) Securing protocols between proxies and backend (HTTP?) servers (Brian > Campbell) > > draft: Looking for support/contributors, no draft yet > > --> needs draft > > > > Detailed minutes will be coming in the next couple of weeks. > > > > Thanks, > Francesca > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000011a392059c5bfe4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Apologies folks, I'm responsible for the rushed = and awkward presentation about reverse proxies and TLS client certificates = at the very end of the SECDISPATCH session in Singapore, which is mentioned= below with "no draft yet--> needs draft". It took me a little= while to get through the work but I'm happy to share that there is now= an actual draft available. Here it is in the fancy new HTML format: https://www.ietf.org/id/draft-bdc-something-somethin= g-certificate-01.html as well as the good ol status page: https://datatracker.ietf.org/doc/draft-bdc-something-some= thing-certificate/


On Tue, Nov 19, 2019 at 9:3= 4 PM Francesca Palombini <francesca.palombini=3D40ericsson.com@dmarc.ietf.org> wrote:

The SECDISPATCH WG me= t on Tuesday November 19.=C2=A0 The agenda items were dispatched as follows= :

=C2=A0<= /span>

(1) Problem statement= for post-quantum multi-algorithm PKI (Max Pala)

drafts:= =C2=A0 https://datatracker.ietf.org/doc/draft-pq-pkix-= problem-statement/

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracke= r.ietf.org/doc/draft-ounsworth-pq-composite-sigs/<= /p>

--> dispatch to LAMPS WG (confirm on mailin= g list)

=C2=A0<= /span>

(2) OCSPv2 - Improvin= g OCSP Responses (Max Pala)

LAMPS & PKIX disc= ussions:

Draft:=C2=A0 htt= ps://tools.ietf.org/html/draft-pala-ocspv2-00

--> create a BoF f= or small focused WG

=C2=A0<= /span>

(3) Priva= cy Pass Protocol (Nick Sullivan)

drafts: <= a href=3D"https://datatracker.ietf.org/doc/draft-privacy-pass/" target=3D"_= blank">https://datatracker.ietf.org/doc/draft-privacy-pass/

--> work on charte= r text then BoF for small focused WG

=C2=A0<= /span>

(4) HTTP Request sign= ing (Justin Richer)

draft: https://tools.ietf.org/html/draft-cavage-http-signatures=

--> dispatched to = HTTPBIS WG

=C2=A0<= /span>

(5) Communication Net= work Perspective on Malware Lifecycle (Joachim Fabini)=

draft: https://datatracker.ietf.org/doc/draft-fabini-smart= -malware-lifecycle/

--> check the IAB = project (talk to Ted)

=C2=A0<= /span>

(6) Securing protocol= s between proxies and backend (HTTP?) servers (Brian Campbell)

draft: Looking for su= pport/contributors, no draft yet

--> needs draft=

=C2=A0<= /span>

Detailed minutes will= be coming in the next couple of weeks.

=C2=A0<= /span>

Thanks,
Francesca


<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000011a392059c5bfe4e-- From nobody Fri Jan 17 15:58:44 2020 Return-Path: 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 D9AA8120086 for ; Fri, 17 Jan 2020 15:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 aQuKH7G_rB5F for ; Fri, 17 Jan 2020 15:58:41 -0800 (PST) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 DBFBC12006B for ; Fri, 17 Jan 2020 15:58:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1579305521; x=1610841521; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YUP6JvdAacTUtxsNItW0Rg2ZMaL3F2GsX+LCPbpUMH0=; b=V7kctJko27gVmBUfljl7Nyfy9AtddEPhMTyJCUxH3QbOPoX3W7tq1HDb hR2iPqGKPt0DqmRoGAzL0gCfrdO5iTfjcFFNgumq3eHqgWetX+zIeXPXo m7N0UvwWBIddYnzq2l+47ugm+kJLgzfTheqMpfZnoEV4mbDXwTm7+oGL8 +Voy/2iIfUi/HVay8zjp/rsLD3aEMKH96+vr+pe3LTULuf8z3B12cxe1Z LT0CdlK3vKKammqs2FPzdESImqhtj5NSVTZccCy/xjRuYe4f2VhoSM+e+ MSSZIy04In++XFk6gTbxhG+LDFCPmAv5NwKDwpOTYnKATVXxysPiFdCbj Q==; X-IronPort-AV: E=Sophos;i="5.70,332,1574074800"; d="scan'208";a="110288608" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from uxcn13-tdc-e.uoa.auckland.ac.nz ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 18 Jan 2020 12:58:38 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.9) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 18 Jan 2020 12:58:37 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Sat, 18 Jan 2020 12:58:38 +1300 From: Peter Gutmann To: Daniel Van Geest , Benjamin Kaduk , Dan Brown CC: IETF SAAG Thread-Topic: Re: [saag] NSA bug in Windows 10 Thread-Index: AQHVzTs1pVBAbScFtUeDqEEHLtV82afviW6d Date: Fri, 17 Jan 2020 23:58:37 +0000 Message-ID: <1579305517015.80416@cs.auckland.ac.nz> References: <47B98698-1B77-498C-983C-F0CD6D3515CF@isara.com> In-Reply-To: <47B98698-1B77-498C-983C-F0CD6D3515CF@isara.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 23:58:44 -0000 Daniel Van Geest writes:=0A= =0A= >The best summary I=92ve seen is here:=0A= >https://blog.trailofbits.com/2020/01/16/exploiting-the-windows-cryptoapi-v= ulnerability/=0A= =A0=0A= There's also good summaries here, along with test vectors:=0A= =0A= https://github.com/kudelskisecurity/chainoffools=0A= (text at https://research.kudelskisecurity.com/2020/01/15/cve-2020-0601-t= he-chainoffools-attack-explained-with-poc)=0A= https://github.com/ollypwn/cve-2020-0601=0A= =0A= Peter.=0A= From nobody Fri Jan 17 18:26:20 2020 Return-Path: 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 854CC12008C for ; Fri, 17 Jan 2020 18:26:18 -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 bvwWYeez0CWm for ; Fri, 17 Jan 2020 18:26:16 -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 A0A8A120041 for ; Fri, 17 Jan 2020 18:26:16 -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 00I2PvW4024543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Jan 2020 21:26:00 -0500 Date: Fri, 17 Jan 2020 18:25:57 -0800 From: Benjamin Kaduk To: Dan Brown Cc: Peter Gutmann , Phillip Hallam-Baker , IETF SAAG Message-ID: <20200118022557.GT80030@kduck.mit.edu> References: <1579100916686.94828@cs.auckland.ac.nz> <5fd6bac7558d45fcac94119e746d7d0e@blackberry.com> <20200117040214.GR80030@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 02:26:18 -0000 On Fri, Jan 17, 2020 at 06:54:27PM +0000, Dan Brown wrote: > > > -----Original Message----- > > From: Benjamin Kaduk > > > > > > 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. > > Well, that attack does not match what I read. > > In what I read, a fake root cert is sent, and the receiver uses it. Some > claim the bug is an incomplete match between the fake and real root cert, > but I claim the real bug is using the received cert at all. It seems that I had read too quickly or not read enough. Thanks everyone for correcting me, and sorry for spreading confusion. -Ben From nobody Sat Jan 18 08:32:46 2020 Return-Path: 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 ; 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 ; 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 ; 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 To: IETF SAAG , Dan Brown In-Reply-To: References: <1579100916686.94828@cs.auckland.ac.nz> <5fd6bac7558d45fcac94119e746d7d0e@blackberry.com> <20200117040214.GR80030@kduck.mit.edu> 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 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2020 16:32:45 -0000 --=-=-= Content-Type: text/plain Dan Brown 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 , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4jMykACgkQgItw+93Q 3WVwOAf+NfnpCioHJbiDKuJ6ZuUQVNLGsTOJk/PW3CNZRO2ZMhKlrkJ5cCneGORg o6H5q3r48E/LwQGos2gbueVHyr7a/VGQbSUSBwdqOo/iKGdANXo5xr5WxVKAxw5d gQOUW6eRI5cP4KOLGbrD4Fz0VqWnqDRzSLU1RdaIIm7aOqGZcvB7XuPXjPKVrp5D E2vhR68YXhT9NcLuSvXkdD7zYWBs7Aj57aKbPVgvadsZE0QcSDp3KzPhjwwlfqfZ hZjVg5zCMG2SFUM8kf7EFPyc6j2/9u7MAPkjfGNEubfnNF1xXgW5HWsIpQxoCcNn LZWL3hycuc5Z+bazuY+dWG3JY++0WA== =QesY -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jan 21 10:18:33 2020 Return-Path: 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 851CA12099C; Tue, 21 Jan 2020 10:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=entrustdatacardcorp.onmicrosoft.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 6NzdGvcKQDFT; Tue, 21 Jan 2020 10:18:26 -0800 (PST) Received: from mx2.entrustdatacard.com (mx2.entrustdatacard.com [204.124.80.222]) (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 6B09212097F; Tue, 21 Jan 2020 10:18:26 -0800 (PST) IronPort-SDR: RcVWFl/HC4li5abS2M5cmz3y65SRLSv7Wl5tSilJH21Yi1l4c3tqPucBD42mpm0SVQLM6zzTWB XycSev/y3axw== X-IronPort-AV: E=Sophos;i="5.70,346,1574143200"; d="scan'208,217";a="7897255" Received: from pmspex02.corporate.datacard.com (HELO owa.entrustdatacard.com) ([192.168.211.30]) by pmspesa04inside.corporate.datacard.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 21 Jan 2020 12:18:24 -0600 Received: from pmspex01.corporate.datacard.com (192.168.211.29) by pmspex02.corporate.datacard.com (192.168.211.30) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 21 Jan 2020 12:18:24 -0600 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (172.28.1.8) by pmspex01.corporate.datacard.com (192.168.211.29) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 21 Jan 2020 12:18:23 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oL3hJaGUdVn1IP9eIbeoM7v28mHtlMmmSr3msUiBHaM0ydH5PF0Rdo6yB8+DZPYSDFN3U1eiX6LNVBEFbkjWrynsrlwzVvVLfLUWemwMQQK3e752tf94rrug5PGjJQobUTor4vbXbQBZuRVAOGj21jPjadHHUFF+3qtuV+Cztus036tgEd00piBUkmPA5nGuRfId3YRyLy6zWN7wOqyNdqIvpkcITKCPEGARfsQwTBDcQ8eo4jT2ShTSKTjTId169xgB1FgJymyK7H550VHHMlToTVWnpyhHGF0iJ9WS7QnxgEopCfwVATZQgyA8RuvfBx4YLBnbA833b3hHrpjJ5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J772LbiZsnIUsrsUqgZQP5DiINRyr3GWklgfnKHzaT8=; b=Jl1hodAKz/kun1CW4EdQUNLAp4HVFxaxSmL6G7C7irpc2nf2rJWXJQ1MjWUGWspGP4cLJMAHvqtNeE39dEcqUjMDykDeIsRUI84EgtziZOkC7PJT8SvJ/Mtfexv1ChcBjkPJ5cmq6BZIEd2Gg/nB82cuvfzBsYXg4FQRQI0MoYqKIzHfF0V8rFRBYGffRudjMUXzdTugVs0LZQNBRNjbB9mH4t5SW97p+xEXx2nV4UAmGglcNSQdthUex/ECvuRj/nZ7JKn8rU69Mf/dsMf+DVhsHAcwVDfLBoKMUYH4AUP3Owb2pNUUdhDf3dG+Hye96Dq9LHsU1wsE23gU0JGh7A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=entrustdatacard.com; dmarc=pass action=none header.from=entrustdatacard.com; dkim=pass header.d=entrustdatacard.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=entrustdatacardcorp.onmicrosoft.com; s=selector1-entrustdatacardcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J772LbiZsnIUsrsUqgZQP5DiINRyr3GWklgfnKHzaT8=; b=fX4wVStCMeEYrGZr+oeb3IJIzsA7YfJA4kARsosS/CXAwaOYTq4Jlu8HM3NEDFjEzY1NeSckBUR8FHBPcMLkvSTUl0TIhhkAeH5gfZrcxdr7zaUQa8qSKBwH8jqMVkFbBbiUOw9fybiewby79BSFVB0pTLmToJhgo2W5ioYc1YQ= Received: from DM6PR11MB3883.namprd11.prod.outlook.com (10.255.61.32) by DM6PR11MB3995.namprd11.prod.outlook.com (10.255.61.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19; Tue, 21 Jan 2020 18:18:23 +0000 Received: from DM6PR11MB3883.namprd11.prod.outlook.com ([fe80::34ac:ed41:2759:3392]) by DM6PR11MB3883.namprd11.prod.outlook.com ([fe80::34ac:ed41:2759:3392%6]) with mapi id 15.20.2644.027; Tue, 21 Jan 2020 18:18:23 +0000 From: Mike Ounsworth To: Brian Campbell , "Francesca Palombini" CC: "secdispatch@ietf.org" , "saag@ietf.org" Thread-Topic: [EXTERNAL]Re: [Secdispatch] SECDISPATCH WG Summary from IETF 106 Thread-Index: AQHVn1vFDxHCv1ors0i+tXiIXiWbjqfvrqyAgAAb1cA= Date: Tue, 21 Jan 2020 18:18:23 +0000 Message-ID: References: <3088D698-1616-4A74-9CBC-4A9345E46C15@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Mike.Ounsworth@entrustdatacard.com; x-originating-ip: [70.76.144.81] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 17fc2fef-d3ec-400d-127b-08d79e9e4d37 x-ms-traffictypediagnostic: DM6PR11MB3995: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0289B6431E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(136003)(366004)(39860400002)(189003)(199004)(76116006)(66446008)(64756008)(66556008)(66476007)(66946007)(66574012)(71200400001)(110136005)(316002)(54906003)(55016002)(5660300002)(478600001)(21615005)(966005)(9686003)(52536014)(81156014)(2906002)(8676002)(8936002)(81166006)(7696005)(33656002)(6506007)(4326008)(26005)(186003)(53546011)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR11MB3995; H:DM6PR11MB3883.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6Iy6cWK36QcMdw+2TOGDDPuOcGIAV+2Bc5REKfvP28FSJAI53twG1OmuUH/jqvQAJYoWRAifiTKXkA3lPcSqMn2RWfFX17Tpp2EqeTImai/pAzEoYjbenGoJ91z2KyB1vRVmfkPrYVjm02/Nh/4x/TItHECFiVKbzHHUg1+SqyC65i/+Fji2GtJaJTpZHMYme3MfyyaEp5yWXAvUewQJ678U8xsws2+hLj+ob/ydFbTtpWCo0D1PoQYRvV7M5icjdTkVphkzsVwHyZtUhf/w4RqPTj042l6yIOOB5sdBjRhDOjZZsaA3MFmhgr2V2vQ/3zvRQFZ3pgVF0XXCm3HwqKxibZJ3DCsa7kl02QTvqvAtRYT77/GxgNdr/yl9O+WdWwNgbqbcplzTBhSLobd2T9Q0opOFIc5ux51kNF9YbxfmzNtm7nnucv8Ta5V+gbIQ/A4RlhAmzC4jkc4x5kqHuENXMWDJ/Q8Q71VWiWjCULp6k3Lza7rqDti3uPvaRQNxi7KIiwQ0mE1rqJZz9pLPFQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB3883B6A92EE8946978C6D7E69B0D0DM6PR11MB3883namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 17fc2fef-d3ec-400d-127b-08d79e9e4d37 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2020 18:18:23.2311 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f46cf439-27ef-4acf-a800-15072bb7ddc1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: STru4m9K9VmxL5NXKkzFGcJq+aGWdVdioAxrupcOTSJ2S9fOoZ7X2/Uzo7YFTN0ZQx8A7SuEd2VE4Qs2AdoFNATHB8teDBQkVjUO87lVJAifOCGo5mwk45IlfkQcOBpi X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3995 X-OriginatorOrg: entrustdatacard.com Archived-At: Subject: Re: [saag] [EXTERNAL]Re: [Secdispatch] SECDISPATCH WG Summary from IETF 106 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 18:18:31 -0000 --_000_DM6PR11MB3883B6A92EE8946978C6D7E69B0D0DM6PR11MB3883namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IHRoaXMgZWZmb3J0IQ0KDQpUaGUgbGFjayBvZiBzdWNoIGEgaGVhZGVyIGhhcyBi ZWVuIGEgcGFpbiBwb2ludCBmb3IgbWlncmF0aW5nIGFwcGxpY2F0aW9ucyB3aXRoIGNsaWVudC1j ZXJ0IGRyaXZlbiBhdXRoIG1lY2hhbmlzbXMgaW50byB0aGUgY2xvdWQuDQoNCi0tLQ0KTWlrZSBP dW5zd29ydGgNClNvZnR3YXJlIFNlY3VyaXR5IEFyY2hpdGVjdCwgRW50cnVzdCBEYXRhY2FyZA0K DQpGcm9tOiBTZWNkaXNwYXRjaCA8c2VjZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVo YWxmIE9mIEJyaWFuIENhbXBiZWxsDQpTZW50OiBKYW51YXJ5IDE3LCAyMDIwIDI6NDMgUE0NClRv OiBGcmFuY2VzY2EgUGFsb21iaW5pIDxmcmFuY2VzY2EucGFsb21iaW5pPTQwZXJpY3Nzb24uY29t QGRtYXJjLmlldGYub3JnPg0KQ2M6IHNlY2Rpc3BhdGNoQGlldGYub3JnOyBzYWFnQGlldGYub3Jn DQpTdWJqZWN0OiBbRVhURVJOQUxdUmU6IFtTZWNkaXNwYXRjaF0gU0VDRElTUEFUQ0ggV0cgU3Vt bWFyeSBmcm9tIElFVEYgMTA2DQoNCldBUk5JTkc6IFRoaXMgZW1haWwgb3JpZ2luYXRlZCBvdXRz aWRlIG9mIEVudHJ1c3QgRGF0YWNhcmQuDQpETyBOT1QgQ0xJQ0sgbGlua3Mgb3IgYXR0YWNobWVu dHMgdW5sZXNzIHlvdSB0cnVzdCB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNh ZmUuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQXBvbG9naWVzIGZvbGtzLCBJ J20gcmVzcG9uc2libGUgZm9yIHRoZSBydXNoZWQgYW5kIGF3a3dhcmQgcHJlc2VudGF0aW9uIGFi b3V0IHJldmVyc2UgcHJveGllcyBhbmQgVExTIGNsaWVudCBjZXJ0aWZpY2F0ZXMgYXQgdGhlIHZl cnkgZW5kIG9mIHRoZSBTRUNESVNQQVRDSCBzZXNzaW9uIGluIFNpbmdhcG9yZSwgd2hpY2ggaXMg bWVudGlvbmVkIGJlbG93IHdpdGggIm5vIGRyYWZ0IHlldC0tPiBuZWVkcyBkcmFmdCIuIEl0IHRv b2sgbWUgYSBsaXR0bGUgd2hpbGUgdG8gZ2V0IHRocm91Z2ggdGhlIHdvcmsgYnV0IEknbSBoYXBw eSB0byBzaGFyZSB0aGF0IHRoZXJlIGlzIG5vdyBhbiBhY3R1YWwgZHJhZnQgYXZhaWxhYmxlLiBI ZXJlIGl0IGlzIGluIHRoZSBmYW5jeSBuZXcgSFRNTCBmb3JtYXQ6IGh0dHBzOi8vd3d3LmlldGYu b3JnL2lkL2RyYWZ0LWJkYy1zb21ldGhpbmctc29tZXRoaW5nLWNlcnRpZmljYXRlLTAxLmh0bWwg YXMgd2VsbCBhcyB0aGUgZ29vZCBvbCBzdGF0dXMgcGFnZTogaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtYmRjLXNvbWV0aGluZy1zb21ldGhpbmctY2VydGlmaWNhdGUvDQoN Cg0KT24gVHVlLCBOb3YgMTksIDIwMTkgYXQgOTozNCBQTSBGcmFuY2VzY2EgUGFsb21iaW5pIDxm cmFuY2VzY2EucGFsb21iaW5pPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0 MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KVGhlIFNFQ0RJU1BBVENIIFdH IG1ldCBvbiBUdWVzZGF5IE5vdmVtYmVyIDE5LiAgVGhlIGFnZW5kYSBpdGVtcyB3ZXJlIGRpc3Bh dGNoZWQgYXMgZm9sbG93czoNCg0KKDEpIFByb2JsZW0gc3RhdGVtZW50IGZvciBwb3N0LXF1YW50 dW0gbXVsdGktYWxnb3JpdGhtIFBLSSAoTWF4IFBhbGEpDQpkcmFmdHM6ICBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wcS1wa2l4LXByb2JsZW0tc3RhdGVtZW50Lw0KICAg ICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1vdW5zd29ydGgtcHEt Y29tcG9zaXRlLXNpZ3MvDQotLT4gZGlzcGF0Y2ggdG8gTEFNUFMgV0cgKGNvbmZpcm0gb24gbWFp bGluZyBsaXN0KQ0KDQooMikgT0NTUHYyIC0gSW1wcm92aW5nIE9DU1AgUmVzcG9uc2VzIChNYXgg UGFsYSkNCkxBTVBTICYgUEtJWCBkaXNjdXNzaW9uczoNCkRyYWZ0OiAgaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXBhbGEtb2NzcHYyLTAwDQotLT4gY3JlYXRlIGEgQm9GIGZvciBz bWFsbCBmb2N1c2VkIFdHDQoNCigzKSBQcml2YWN5IFBhc3MgUHJvdG9jb2wgKE5pY2sgU3VsbGl2 YW4pDQpkcmFmdHM6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXByaXZh Y3ktcGFzcy8NCi0tPiB3b3JrIG9uIGNoYXJ0ZXIgdGV4dCB0aGVuIEJvRiBmb3Igc21hbGwgZm9j dXNlZCBXRw0KDQooNCkgSFRUUCBSZXF1ZXN0IHNpZ25pbmcgKEp1c3RpbiBSaWNoZXIpDQpkcmFm dDogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhdmFnZS1odHRwLXNpZ25hdHVy ZXMNCi0tPiBkaXNwYXRjaGVkIHRvIEhUVFBCSVMgV0cNCg0KKDUpIENvbW11bmljYXRpb24gTmV0 d29yayBQZXJzcGVjdGl2ZSBvbiBNYWx3YXJlIExpZmVjeWNsZSAoSm9hY2hpbSBGYWJpbmkpDQpk cmFmdDogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmFiaW5pLXNtYXJ0 LW1hbHdhcmUtbGlmZWN5Y2xlLw0KLS0+IGNoZWNrIHRoZSBJQUIgcHJvamVjdCAodGFsayB0byBU ZWQpDQoNCig2KSBTZWN1cmluZyBwcm90b2NvbHMgYmV0d2VlbiBwcm94aWVzIGFuZCBiYWNrZW5k IChIVFRQPykgc2VydmVycyAoQnJpYW4gQ2FtcGJlbGwpDQpkcmFmdDogTG9va2luZyBmb3Igc3Vw cG9ydC9jb250cmlidXRvcnMsIG5vIGRyYWZ0IHlldA0KLS0+IG5lZWRzIGRyYWZ0DQoNCkRldGFp bGVkIG1pbnV0ZXMgd2lsbCBiZSBjb21pbmcgaW4gdGhlIG5leHQgY291cGxlIG9mIHdlZWtzLg0K DQpUaGFua3MsDQpGcmFuY2VzY2ENCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFp bCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRo ZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2Us IGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJp dGVkLi4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRl IHRoZSBtZXNzYWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIu IFRoYW5rIHlvdS4NCg== --_000_DM6PR11MB3883B6A92EE8946978C6D7E69B0D0DM6PR11MB3883namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpEZW5nWGlhbjsNCglwYW5vc2UtMToy IDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJTZWdvZSBVSSI7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEg MSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGku bXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6IzcwMzBBMDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzdXBwb3J0IHRoaXMgZWZmb3J0ITxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUgbGFjayBvZiBzdWNoIGEgaGVhZGVyIGhhcyBiZWVuIGEgcGFpbiBwb2lu dCBmb3IgbWlncmF0aW5nIGFwcGxpY2F0aW9ucyB3aXRoIGNsaWVudC1jZXJ0IGRyaXZlbiBhdXRo IG1lY2hhbmlzbXMgaW50byB0aGUgY2xvdWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLTxi cj4NCk1pa2UgT3Vuc3dvcnRoPGJyPg0KU29mdHdhcmUgU2VjdXJpdHkgQXJjaGl0ZWN0LCBFbnRy dXN0IERhdGFjYXJkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzcwMzBBMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFNlY2Rpc3BhdGNoICZsdDtzZWNkaXNwYXRjaC1i b3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5CcmlhbiBDYW1wYmVsbDxi cj4NCjxiPlNlbnQ6PC9iPiBKYW51YXJ5IDE3LCAyMDIwIDI6NDMgUE08YnI+DQo8Yj5Ubzo8L2I+ IEZyYW5jZXNjYSBQYWxvbWJpbmkgJmx0O2ZyYW5jZXNjYS5wYWxvbWJpbmk9NDBlcmljc3Nvbi5j b21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBzZWNkaXNwYXRjaEBpZXRmLm9y Zzsgc2FhZ0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbRVhURVJOQUxdUmU6IFtTZWNk aXNwYXRjaF0gU0VDRElTUEFUQ0ggV0cgU3VtbWFyeSBmcm9tIElFVEYgMTA2PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpyZWQiPldBUk5JTkc6PC9zcGFuPjwvc3Ryb25nPiBU aGlzIGVtYWlsIG9yaWdpbmF0ZWQgb3V0c2lkZSBvZiBFbnRydXN0IERhdGFjYXJkLjxicj4NCjxz dHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpyZWQiPkRPIE5PVCBDTElDSzwvc3Bhbj48L3N0cm9uZz4gbGlua3Mgb3IgYXR0 YWNobWVudHMgdW5sZXNzIHlvdSB0cnVzdCB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50 IGlzIHNhZmUuPG86cD48L286cD48L3A+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJj ZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMyIgd2lkdGg9IjEw MCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFwb2xvZ2llcyBmb2xrcywgSSdtIHJlc3BvbnNpYmxlIGZvciB0aGUgcnVzaGVkIGFu ZCBhd2t3YXJkIHByZXNlbnRhdGlvbiBhYm91dCByZXZlcnNlIHByb3hpZXMgYW5kIFRMUyBjbGll bnQgY2VydGlmaWNhdGVzIGF0IHRoZSB2ZXJ5IGVuZCBvZiB0aGUgU0VDRElTUEFUQ0ggc2Vzc2lv biBpbiBTaW5nYXBvcmUsIHdoaWNoIGlzIG1lbnRpb25lZCBiZWxvdyB3aXRoICZxdW90O25vIGRy YWZ0IHlldC0tJmd0OyBuZWVkcyBkcmFmdCZxdW90Oy4NCiBJdCB0b29rIG1lIGEgbGl0dGxlIHdo aWxlIHRvIGdldCB0aHJvdWdoIHRoZSB3b3JrIGJ1dCBJJ20gaGFwcHkgdG8gc2hhcmUgdGhhdCB0 aGVyZSBpcyBub3cgYW4gYWN0dWFsIGRyYWZ0IGF2YWlsYWJsZS4gSGVyZSBpdCBpcyBpbiB0aGUg ZmFuY3kgbmV3IEhUTUwgZm9ybWF0Og0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQv ZHJhZnQtYmRjLXNvbWV0aGluZy1zb21ldGhpbmctY2VydGlmaWNhdGUtMDEuaHRtbCIgdGFyZ2V0 PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtYmRjLXNvbWV0aGluZy1z b21ldGhpbmctY2VydGlmaWNhdGUtMDEuaHRtbDwvYT4gYXMgd2VsbCBhcyB0aGUgZ29vZCBvbCBz dGF0dXMgcGFnZToNCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWJkYy1zb21ldGhpbmctc29tZXRoaW5nLWNlcnRpZmljYXRlLyIgdGFyZ2V0PSJfYmxhbmsi Pg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmRjLXNvbWV0aGluZy1z b21ldGhpbmctY2VydGlmaWNhdGUvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE5vdiAxOSwgMjAxOSBhdCA5 OjM0IFBNIEZyYW5jZXNjYSBQYWxvbWJpbmkgJmx0O2ZyYW5jZXNjYS5wYWxvbWJpbmk9PGEgaHJl Zj0ibWFpbHRvOjQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+VGhlIFNFQ0RJU1BBVENIIFdHIG1ldCBvbiBUdWVzZGF5 IE5vdmVtYmVyIDE5LiZuYnNwOyBUaGUgYWdlbmRhIGl0ZW1zIHdlcmUgZGlzcGF0Y2hlZCBhcyBm b2xsb3dzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPigxKSBQcm9ibGVtIHN0YXRlbWVudCBmb3Ig cG9zdC1xdWFudHVtIG11bHRpLWFsZ29yaXRobSBQS0kgKE1heCBQYWxhKQ0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+ZHJhZnRz OiZuYnNwOw0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt cHEtcGtpeC1wcm9ibGVtLXN0YXRlbWVudC8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBxLXBraXgtcHJvYmxlbS1zdGF0ZW1lbnQvPC9h Pjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1vdW5zd29ydGgtcHEtY29tcG9zaXRlLXNpZ3MvIiB0YXJnZXQ9Il9ibGFuayI+ DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1vdW5zd29ydGgtcHEtY29t cG9zaXRlLXNpZ3MvPC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+LS0mZ3Q7 IGRpc3BhdGNoIHRvIExBTVBTIFdHIChjb25maXJtIG9uIG1haWxpbmcgbGlzdCk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLUdCIj4oMikgT0NTUHYyIC0gSW1wcm92aW5nIE9DU1AgUmVzcG9uc2VzIChNYXgg UGFsYSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLUdCIj5MQU1QUyAmYW1wOyBQS0lYIGRpc2N1c3Npb25zOg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+RHJh ZnQ6Jm5ic3A7DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGFs YS1vY3NwdjItMDAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtcGFsYS1vY3NwdjItMDA8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+LS0mZ3Q7IGNyZWF0ZSBhIEJvRiBmb3Ig c21hbGwgZm9jdXNlZCBXRzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPigzKSBQcml2YWN5IFBhc3MgUHJv dG9jb2wgKE5pY2sgU3VsbGl2YW4pPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj5kcmFm dHM6DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wcml2 YWN5LXBhc3MvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtcHJpdmFjeS1wYXNzLzwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t R0IiPi0tJmd0OyB3b3JrIG9uIGNoYXJ0ZXIgdGV4dCB0aGVuIEJvRiBmb3Igc21hbGwgZm9jdXNl ZCBXRzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPig0KSBIVFRQIFJlcXVlc3Qgc2lnbmluZyAoSnVz dGluIFJpY2hlcik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IlNWIj5kcmFmdDoNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1jYXZhZ2UtaHR0cC1zaWduYXR1cmVzIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2F2YWdlLWh0dHAtc2lnbmF0dXJlczwvYT48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPi0tJmd0OyBkaXNwYXRjaGVkIHRvIEhU VFBCSVMgV0c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4oNSkgQ29tbXVuaWNhdGlvbiBOZXR3b3Jr IFBlcnNwZWN0aXZlIG9uIE1hbHdhcmUgTGlmZWN5Y2xlIChKb2FjaGltIEZhYmluaSk8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj5k cmFmdDoNCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZh YmluaS1zbWFydC1tYWx3YXJlLWxpZmVjeWNsZS8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZhYmluaS1zbWFydC1tYWx3YXJlLWxpZmVj eWNsZS88L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4tLSZndDsgY2hlY2sg dGhlIElBQiBwcm9qZWN0ICh0YWxrIHRvIFRlZCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4oNikg U2VjdXJpbmcgcHJvdG9jb2xzIGJldHdlZW4gcHJveGllcyBhbmQgYmFja2VuZCAoSFRUUD8pIHNl cnZlcnMgKEJyaWFuIENhbXBiZWxsKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPmRyYWZ0OiBMb29raW5nIGZvciBzdXBwb3J0 L2NvbnRyaWJ1dG9ycywgbm8gZHJhZnQgeWV0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+LS0mZ3Q7IG5lZWRzIGRyYWZ0PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1HQiI+RGV0YWlsZWQgbWludXRlcyB3aWxsIGJlIGNvbWluZyBpbiB0 aGUgbmV4dCBjb3VwbGUgb2Ygd2Vla3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+VGhhbmtzLDxi cj4NCkZyYW5jZXNjYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+ PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2Ug VUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTU1NTU1O2JvcmRlcjpub25lIHdpbmRvd3RleHQg MS4wcHQ7cGFkZGluZzowY20iPkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5 IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29s ZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKS4NCiBBbnkgcmV2aWV3LCB1c2UsIGRp c3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVk Li4mbmJzcDsgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9y LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxl dGUgdGhlIG1lc3NhZ2UgYW5kIGFueSBmaWxlIGF0dGFjaG1lbnRzIGZyb20geW91ciBjb21wdXRl ci4gVGhhbmsgeW91Ljwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_DM6PR11MB3883B6A92EE8946978C6D7E69B0D0DM6PR11MB3883namp_-- From nobody Fri Jan 24 07:20:13 2020 Return-Path: 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 4D4F912006E for ; Fri, 24 Jan 2020 07:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 Hv9R_OpKXGuL for ; Fri, 24 Jan 2020 07:20:08 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 4F33C120024 for ; Fri, 24 Jan 2020 07:20:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 12FC062162; Fri, 24 Jan 2020 10:20:07 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JrOPUEvCa8O8; Fri, 24 Jan 2020 10:20:00 -0500 (EST) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 8A1CE6211C; Fri, 24 Jan 2020 10:20:00 -0500 (EST) To: Russ Housley , IETF SAAG References: From: Robert Moskowitz Message-ID: Date: Fri, 24 Jan 2020 10:19:47 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [saag] SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 15:20:12 -0000 I got to be at the conference.  A lot of very good material.  And note the attack on OCB2.  Thank you Russ for CCM to dodge the patent fight and thus NOT do OCB for 802.11i!   Of course we were looking at OCB1 at the time, but who knows what may have been in the final standard.  The timing was right for it to have been OCB2... Anyway on to the SHA1 presentation and the Levchin award for it. Quite interesting.  Unfortunately the video for it is not being provided at https://totalwebcasting.com/view/?func=VOFF&id=columbia&date=2020-01-08&seq=1 But check out the Enterprise Cryptography talk from ABN AMRO and their moving away from SHA1 certs. The CRLite talk was also interesting (and talk available). As to the cost, we are in an exploded bubble right now due to the collapse of crypto coin mining. Too much available GPU farms idle looking for revenue.  But if this is the cost from public GPU farms looking for revenue (and 1 month leases), what is out there dark to our reseachers with a little bit of grant money to spend? The 15 years from theory to practice is something to take away. Don't just ignore a theoretical attack, but don't immediately panic and then become complacent when nothing seems to come from it (the theory) in a year or two. On 1/7/20 10:23 AM, Russ Housley wrote: > https://eprint.iacr.org/2020/014 > >> SHA-1 is a Shambles - First Chosen-Prefix Collision on SHA-1 and >> Application to the PGP Web of Trust >> >> Gaëtan Leurent and Thomas Peyrin >> >> Abstract: The SHA-1 hash function was designed in 1995 and has been >> widely used during two decades. A theoretical collision attack was first >> proposed in 2004 [WYY05], but due to its high complexity it was only >> implemented in practice in 2017, using a large GPU cluster [SBK+17]. >> More recently, an almost practical chosen-prefix collision attack >> against SHA-1 has been proposed [LP19]. This more powerful attack allows >> to build colliding messages with two arbitrary prefixes, which is much >> more threatening for real protocols. >> >> In this paper, we report the first practical implementation of this >> attack, and its impact on real-world security with a PGP/GnuPG >> impersonation attack. We managed to significantly reduce the complexity >> of collisions attack against SHA-1: on an Nvidia GTX 970, >> identical-prefix collisions can now be computed with a complexity of >> 2^61.2 rather than 2^64.7, and chosen-prefix collisions with a complexity >> of 2^63.4 rather than 2^67.1. When renting cheap GPUs, this translates to >> a cost of 11k US$ for a collision, and 45k US$ for a chosen-prefix >> collision, within the means of academic researchers. Our actual attack >> required two months of computations using 900 Nvidia GTX 1060 GPUs (we >> paid 75k US$ because GPU prices were higher, and we wasted some time >> preparing the attack). >> >> Therefore, the same attacks that have been practical on MD5 since 2009 >> are now practical on SHA-1. In particular, chosen-prefix collisions can >> break signature schemes and handshake security in secure channel >> protocols (TLS, SSH). We strongly advise to remove SHA-1 from those type >> of applications as soon as possible. We exemplify our cryptanalysis by >> creating a pair of PGP/GnuPG keys with different identities, but >> colliding SHA-1 certificates. A SHA-1 certification of the first key can >> therefore be transferred to the second key, leading to a forgery. This >> proves that SHA-1 signatures now offers virtually no security in >> practice. The legacy branch of GnuPG still uses SHA-1 by default for >> identity certifications, but after notifying the authors, the modern >> branch now rejects SHA-1 signatures (the issue is tracked as >> CVE-2019-14855). > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Fri Jan 31 02:28:36 2020 Return-Path: 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 680FC1200E9; Fri, 31 Jan 2020 02:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 l-FD-9snwyLn; Fri, 31 Jan 2020 02:28:32 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 922091200F3; Fri, 31 Jan 2020 02:28:32 -0800 (PST) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 488D2k376MzFqKH; Fri, 31 Jan 2020 11:28:30 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 488D2k2JqnzCqkM; Fri, 31 Jan 2020 11:28:30 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM42.corporate.adroot.infra.ftgroup ([fe80::1c8e:403e:fbea:5835%21]) with mapi id 14.03.0468.000; Fri, 31 Jan 2020 11:28:30 +0100 From: To: "saag@ietf.org" CC: "draft-rebo-sfc-nsh-integrity@ietf.org" Thread-Topic: Review request: SFC/NSH Integrity (draft-rebo-sfc-nsh-integrity) Thread-Index: AdXYISxQSBY+nDs2TNe10KMiQlmNjg== Date: Fri, 31 Jan 2020 10:28:29 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031414514@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [saag] Review request: SFC/NSH Integrity (draft-rebo-sfc-nsh-integrity) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 10:28:34 -0000 SGkgYWxsLCANCg0KRGFuaWVsIGtpbmRseSBzdWdnZXN0ZWQgd2Ugc2hhcmUgdGhpcyBkcmFmdCBv biBzYWFnIGZvciByZXZpZXcuIEhlbmNlLCB0aGlzIG5vdGUgdG8gdGhlIGxpc3QuIA0KDQpUaGUg ZHJhZnQgc3BlY2lmaWVzIGhvdyBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBjYW4gYmUgYWRkZWQgdG8g TlNIIChSRkM4MzAwKTsgdGhlIGRvY3VtZW50IGFsbG93cyBhbHNvIGZvciBlbmNyeXB0aW5nIHBy aXZhY3ktc2Vuc2l0aXZlIE5TSCBUTFZzLiBGV0lXLCBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5n IChTRkMpIHJlZmVyZW5jZSBhcmNoaXRlY3R1cmUgY2FuIGJlIGZvdW5kIGF0IFJGQzc1NjUuDQoN CkNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBhcmUgbW9yZSB0aGFuIHdlbGNvbWUuDQoNCkNoZWVy cywNCk1lZA0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpFbnZvecOp wqA6IHZlbmRyZWRpIDMxIGphbnZpZXIgMjAyMCAxMTowMw0Kw4DCoDogRGFuIFdpbmc7IFRpcnVt YWxlc3dhciBSZWRkeTsgVGlydW1hbGVzd2FyIFJlZGR5Lks7IEJPVUNBREFJUiBNb2hhbWVkIFRH SS9PTE4NCk9iamV0wqA6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcmViby1z ZmMtbnNoLWludGVncml0eS0wMy50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt cmViby1zZmMtbnNoLWludGVncml0eS0wMy50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt aXR0ZWQgYnkgTW9oYW1lZCBCb3VjYWRhaXIgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3Np dG9yeS4NCg0KTmFtZToJCWRyYWZ0LXJlYm8tc2ZjLW5zaC1pbnRlZ3JpdHkNClJldmlzaW9uOgkw Mw0KVGl0bGU6CQlJbnRlZ3JpdHkgUHJvdGVjdGlvbiBmb3IgTmV0d29yayBTZXJ2aWNlIEhlYWRl ciAoTlNIKSBhbmQgRW5jcnlwdGlvbiBvZiBTZW5zaXRpdmUgQ29udGV4dCBIZWFkZXJzDQpEb2N1 bWVudCBkYXRlOgkyMDIwLTAxLTMxDQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFn ZXM6CQkyOA0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1yZWJvLXNmYy1uc2gtaW50ZWdyaXR5LTAzLnR4dA0KU3RhdHVzOiAgICAgICAg IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJlYm8tc2ZjLW5zaC1pbnRl Z3JpdHkvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXJlYm8tc2ZjLW5zaC1pbnRlZ3JpdHktMDMNCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXJlYm8tc2ZjLW5zaC1pbnRlZ3JpdHkNCkRp ZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtcmVi by1zZmMtbnNoLWludGVncml0eS0wMw0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgc3BlY2lmaWNhdGlv biBhZGRzIGludGVncml0eSBwcm90ZWN0aW9uIGFuZCBvcHRpb25hbCBlbmNyeXB0aW9uDQogICBv ZiBzZW5zaXRpdmUgbWV0YWRhdGEgZGlyZWN0bHkgdG8gTmV0d29yayBTZXJ2aWNlIEhlYWRlcnMg KE5TSCkgdXNlZA0KICAgZm9yIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgKFNGQykuDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo=