Re: [TLS] Merkle Tree Certificates
On Mon, Jun 05, 2023 at 03:35:17PM -0400, David Benjamin wrote: > Thanks for such detailed feedback! Responses inline. > > On Wed, Mar 22, 2023 at 12:49 PM Ilari Liusvaara > wrote: > > > Some quick comments / ideas: > > > > - I think it would be easier for subscribers to get inclusion proofs > > from transparency service than certificate authority. > > > > This is because issuance is heavily asynchronous, whereas most > > servers assume ACME is essentially synchronous. > > > > If certificates are canonicalized (this is mostly matter of ensuring > > the names are always sorted), this could be endpoint to download known > > inclusion proofs by certificate hash. > > > > Or maybe even have both, and subscribers can use whichever is more > > convinient. > > > > We’re currently envisioning that the transparency services will potentially > vary by RP. They’re effectively the RP’s CT policy. The different TSs all > see the same trees, just later than the CA. It seems simpler then to get it > from the CA, which will be the least behind. This also means RPs can adjust > TS preferences without impacting subscribers or CAs at all. The equivalent > of a CT log migration and distrust is much less invasive. > > Also, subscribers already talk to CAs via, e.g., ACME, so it seemed natural > to rely on that existing relationship. Especially as subscribers will need > a fallback credential from a CA anyway. > > I suppose there’s no reason why the subscriber couldn’t fetch from the TS. > Though I’m not seeing how it would be more convenient. Could you elaborate? Well, maybe that was a bit X-Y. What I am really after is some mechanism of downloading certificates outside ACME, because the issuance wait is likely prohibitive for many ACME clients. > > I don't see rule for how claims are sorted within each type, > > only how different types are sorted. > > > > - If each claim was in its own Claim, then one could maybe even > > shorten it to 8 bits. Similarly, one could merge ipv4/ipv6 and > > dns/dns_wildcard. > > > > This could also simplify sorting: Sort by type, lexicographic > > sort by claim contents. > > > > Thanks! Yeah, the actual Claim bits were just a naive transcription of > X.509 SANs for now without much thought. I filed > https://github.com/davidben/merkle-tree-certs/issues/31 to track those. One use of strict canonical encoding would be to let the subscriber compute the certificate body itself. E.g., so it could look up the certificates by body hash. > > - I don't think anybody is going to use signatures with >64kB keys, > > so subject_info length could be shortened to 16 bits. > > > > Added to https://github.com/davidben/merkle-tree-certs/pull/29 As a note about signature sizes, TLS (1.2 and 1.3) have 64kB signature limit. IIRC, in NISTPQC outside the "interesting" stuff, only PICNIC had trouble with that. However, when it comes to PQC stuff, IIRC there is second call for proposals going on right now. > > > - I think it would be easier if lifetime was expressed in batch > > durations. Then one would not need window size, and especially not > > handle lifetime / batch_duration not being an integer! > > > > I think we’d still need to be able measure it in both units, but maybe I’m > missing something? > > We need something in units of batch duration (currently window size) to > size the signed windows, etc. > > But the RP can’t just use the window in lieu of expiry, because it can’t > simply assume all batches are valid, because the RP may be unable to fetch > new windows for a long period of time, such that the old (or all!) batches > have fallen off. > > We could do that calculation in batch durations, but then we need to > measure the current time in batch numbers, which seemed unintuitive to me. > And then once that was in seconds, it didn’t seem that aligning it on batch > duration did much. Well, actually doesn't look like things get too annoying if lifetime / batch_duration is not an integer: - window size can be just the ceiling of that. - RPs can calculate explicit expiry via t = t_0 + p * t_p + t_l. Neither of which needs floating-point (which one definitely does not want to use here). > > - The root hash being dependent on issuer and batch number iff there > > are multiple assertions looks very odd. > > > > Empty assertion list might be special. But this also happens for > > one assertion. > > > > Thanks! That’s indeed inconsistent, we’ll fix it. > https://github.com/davidben/merkle-tree-certs/issues/32 Hmm... Looking at that construct, why is the pad there? And why are index and level after pad instead of before? And there does not seem to be any way to salt the hash. WebPKI requires what effectively amounts to salting the hash via serial number (even for SHA-256). > > - Is there reason for type of trust_anchor_data to vary by proof_type? > > Why not always have MerkleTreeTrustAnchor there? > > > > The thinking was to be extensib
Re: [TLS] Merkle Tree Certificates
> > Thanks! That’s indeed inconsistent, we’ll fix it. > > https://github.com/davidben/merkle-tree-certs/issues/32 > > Hmm... Looking at that construct, why is the pad there? We pad to the hash block size. When computing the full Merkle tree, or verifying an authentication path, the values before the pad are the same, and thus we can precompute the hash state after digesting those fixed values. (With the current inputs and sha256, it will only make a difference for HashAssertion though.) > And there does not seem to be any way to salt the hash. WebPKI requires > what effectively amounts to salting the hash via serial number (even > for SHA-256). > Please elaborate. Best, Bas ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Merkle Tree Certificates
On Tue, Jun 06, 2023 at 01:28:17PM +0200, Bas Westerbaan wrote: > > > Thanks! That’s indeed inconsistent, we’ll fix it. > > > https://github.com/davidben/merkle-tree-certs/issues/32 > > > > Hmm... Looking at that construct, why is the pad there? > > > We pad to the hash block size. When computing the full Merkle tree, or > verifying an authentication path, the values before the pad are the same, > and thus we can precompute the hash state after digesting those fixed > values. > > (With the current inputs and sha256, it will only make a difference for > HashAssertion though.) I mean, is there a cryptographic reason for it? If one wanted to really micro-optimize performance, I think the optimal design for SHA-256 would be to have padding for assertions but not for empty nor nodes (since not padding empty and node saves one block). (However, absent cryptographic reasons, this all is way premature.) > > And there does not seem to be any way to salt the hash. WebPKI requires > > what effectively amounts to salting the hash via serial number (even > > for SHA-256). > > > > Please elaborate. >From CABForum Baseline Requirements version 1.8.7 (2.0.0 has the same requirement, but in several places), section 7.1.: "CAs SHALL generate non‐sequential Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG." In certificate structure, serial number comes very early (it is in fact the first non-length field that varies). What that in effect does is to make it much more difficult to exploit chosen-prefix collisions in hash function. However, that requirement holds irrespective of the hash function used, and it has in fact been held for SHA-256 (regardless of there not being any known even remotely feasible attacks) instead of just being a dead letter from the past with much worse hash functions. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Merkle Tree Certificates
On Mon, Jun 5, 2023 at 12:42 PM David Benjamin wrote: > > It’s true that this would require code changes in more components. But > TLS, ACME, etc., are deployed many more times than they are implemented. > ... [snip] ... > > To ACME specifically, we definitely don’t want it to be painful for ACME > clients to implement! It’s probably a bit hard to discuss that in the > abstract, with our ACME section being just a placeholder. Perhaps, when > we’ve gotten an initial draft of that, we can figure out which bits we got > wrong and iterate on that? > Fwiw, I don't think expertise in PKI is really a concern here. I know more than most people about this problem, but less than everyone else in this thread. I don't even maintain this stuff myself, I just happen to use Google for "Managed Certificates" and never think about it... thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] [Editorial Errata Reported] RFC5054 (7538)
The following errata report has been submitted for RFC5054, "Using the Secure Remote Password (SRP) Protocol for TLS Authentication". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7538 -- Type: Editorial Reported by: Mingye Wang Section: 2.1 Original Text - The version of SRP used here is sometimes referred to as "SRP-6" [SRP-6]. Corrected Text -- The version of SRP used here is sometimes referred to as "SRP-6a" [SRP-6a]. [SRP-6a]: Wu, T., "SRP Protocol Design", circa 2005, http://srp.stanford.edu/design.html Notes - The protocol described uses a non-constant k, which is an innovation of SRP-6a -- never published formally in a technical report (until this RFC) and dating to ~2005 if we go by the libsrp version history. Actual [SRP-6] of 2002 uses a constant k = 3. Reference to the [SRP-6] text is still valuable for rationale, but is not accurate. Confusion between these two versions is harmful and may impeded interoperability. Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC5054 (draft-ietf-tls-srp-14) -- Title : Using the Secure Remote Password (SRP) Protocol for TLS Authentication Publication Date: November 2007 Author(s) : D. Taylor, T. Wu, N. Mavrogiannopoulos, T. Perrin Category: INFORMATIONAL Source : Transport Layer Security Area: Security Stream : IETF Verifying Party : IESG ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
