Re: [stir] Rough of sketch of OCSP alternative
Russ Housley <housley@vigilsec.com> Fri, 28 July 2023 19:15 UTC
Return-Path: <housley@vigilsec.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4057EC14CE29 for <stir@ietfa.amsl.com>; Fri, 28 Jul 2023 12:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q56t2VofnFh4 for <stir@ietfa.amsl.com>; Fri, 28 Jul 2023 12:15:32 -0700 (PDT)
Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A73AC14CEFD for <stir@ietf.org>; Fri, 28 Jul 2023 12:15:32 -0700 (PDT)
Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id A505811CF3B; Fri, 28 Jul 2023 15:15:31 -0400 (EDT)
Received: from smtpclient.apple (pfs.iad.rg.net [198.180.150.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id 66A5A11CDA4; Fri, 28 Jul 2023 15:15:29 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <E2CDD174-8A95-40A3-AA38-C0BBC3916222@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BF5D2276-372B-43A1-9035-E7E6E65830FC"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
Date: Fri, 28 Jul 2023 15:15:18 -0400
In-Reply-To: <CABcZeBPy4ERQabAhKaMN2HuJ3jXf735aWzrL-jJmt0EbTD0jUQ@mail.gmail.com>
Cc: IETF STIR Mail List <stir@ietf.org>, Dennis Jackson <ietf@dennis-jackson.uk>
To: Eric Rescorla <ekr@rtfm.com>
References: <CABcZeBPy4ERQabAhKaMN2HuJ3jXf735aWzrL-jJmt0EbTD0jUQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3731.600.7)
X-Scanned-By: mailmunge 3.11 on 66.39.134.11
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/WxpYC4k8QKLrL1vm8Mco0I2D7yA>
Subject: Re: [stir] Rough of sketch of OCSP alternative
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Jul 2023 19:15:36 -0000
Eric: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-208.pdf This supports the truncation of SHA-256 to 192 bits. If this truncation is safe for a hash-based signature, it should be okay in your proposal too. Russ > On Jul 28, 2023, at 2:11 PM, Eric Rescorla <ekr@rtfm.com> wrote: > > In today's meeting I did a bunch of handwaving about alternatives > to OCSP. > > As I understand the situation, the calling provider has a certificate > that covers some TN number range with the usual semantics that the CA > believes that the provider is authorized for that range. However, > that's a dynamic situation and numbers might be ported out of the > provider (see more about numbers being ported in), so the verifier > wants to be able to verify "is this certificate still valid for > number X?" > > What I have in mind is something like the following, which is at > least slightly less handwavy, though may still be horribly broken. > It didn't do as good a job of reducing the size of the PASSport > as I was hoping. Naively it's around 600 bytes, though perhaps > we can make it smaller. > > > # Setup > > At the time of issuance the certificate is valid for N numbers E_1, > E_2, ... E_n. For each time window t (say one day), the CA creates a > set of N random numbers R_1_t, R_2_t, ... R_n_t, with the obvious > mapping: > > E_1 -> R_1_t > E_2 -> R_2_t > ... > E_n -> R_n_t > > When it issues the certificate, it then adds hashes of > the R values, conceptually in a big table like so: > > [ > [ Hash(R_1_1), Hash(R_2_1), ... Hash(R_n_1) ], // Time window 1 > [ Hash(R_1_2), Hash(R_2_2), ... Hash(R_n_2) ], // Time window 2 > ... > [ Hash(R_1_T), Hash(R_2_T), ... Hash(R_n_T) ], // Time window T > ] > > This is obviously huge, but I'll talk about how to compress > it later. > > This requires around N*T operations, so if you had 10^6 numbers and > a two week period with one day time windows, it's about 10^7 operations, > but they're just fast symmetric key operations like hashes so this > is practical. The CA does *not* need to store all this data because > it can compute R_i_t as PRF(Secret, i, t). > > > # Calling > > When a provider wants to make a call from number E_i it contacts the > CA, which provides the value R_i_t for that number and for the current > time window t (this value was previously secret. The provider then > includes R_i_t in the PASSporT in a new field. > > When the verifier receives the call, it does the following: > > 1. Verifies the certificate as accurate, proving that the provider > is legitimate and that the CA attests to the binding of the > public key to the provider. > > 2. Checks that R_i_t hashes to the corresponding hash value in the > certificate, verifying that the provider was still authorized for > number E_i at time. This replaces the OSCP check for authorization > for the number, though not the OSCP check for the certificate > itself. > > > # Compression > > As I mentioned, the certificate is super huge in this design, but > it's possible to compress it because certificate just needs > to *commit* to the hashes, but not contain them. We can improve > the situation using a Merkle Hash Tree. Specifically, for time > window t, the CA lays out a Merkle tree with the leaves: > > Hash(R_1_t) Hash(R_2_t) Hash(R_3_t) ... Hash(R_n_t) > > Each time window then hashes up into a tree of depth approximately > log_2(N) values. > > The calling provider then provides the path from the leaf node > to the root in the PASSPporT, so that means they provide: > > log_2(N) hashes > the R value > > If N is a million certificates then we're looking at a tree of depth > 20 or so. If we use 32 byte hashes, then this is order 640 bytes, > which isn't great. I don't understand the security bounds of Merkle > trees to know well enough if you could get away with shorter hashes, > though obviously that would help. One thing that might help here > is that the CA controls R, so the attack space is narrower > than it might ordinarily be. > > In terms of what goes in the certificate, you can either put the root > of each time window tree in the certificate or take the time window > trees and hash them up into a single root, and put that in the > certificate. Given that we are trying to minimize cost in inline > PASSporTs, it's probably better to have more data in the certificate > than we otherwise would. > > > # Shrinking the PASSporT (partial stapling) > > Note that it's not *necessary* that the PASSporT contain the full > Merkle tree path, as that information isn't secret; it's just a matter > of whether it's self-contained. So, for instance, you could do > the following: > > - There is an online mechanism to retrieve parts of the tree (this is > just cacheable stuff). > > - The calling provider can only send the most M leafward nodes in the > PASSport and hope that the verifier has already cached the parent > nodes. > > The calling provider might also keep track of what it sent to > each verifier and start out sending the whole path but then > do less in subsequent calls. > > -Ekr > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > stir mailing list > stir@ietf.org > https://www.ietf.org/mailman/listinfo/stir
- [stir] Rough of sketch of OCSP alternative Eric Rescorla
- Re: [stir] Rough of sketch of OCSP alternative Russ Housley
- Re: [stir] Rough of sketch of OCSP alternative Eric Rescorla