Trimming heavily, with great thanks for the numerous updates... On Mon, Oct 28, 2019 at 05:50:10PM -0400, Michael Richardson wrote: > > Benjamin Kaduk <[email protected]> wrote: > > I also have some more comments that didn't make it into my ballot > position; > > please consider them as well. I will put them in the datatracker for > > posterity, but will have it not generate an additional mail since the > > mostly-duplicate contents would be confusing. > [...] > > doc> o The registrar forwards the voucher to the pledge when requested. > > > I suggest "validates and forwards" to cover the case where the registrar > > applies policy. > > the whole text is: > <t>The registrar requests and validates the voucher from the > MASA.</t> > > <t>The registrar forwards the voucher to the pledge when > requested.</t> > > so validates is already in the previous point, I think.
Indeed. Apparently the page break caused me to forget; sorry for the noise :( > > Section 5.8 > > doc> although it results in additional network traffic. The relying MASA > doc> implementation MAY leverage internal state to associate this request > doc> with the original, and by now already validated, voucher-request so > doc> as to avoid an extra crypto validation. > > > It seems that doing so would turn the voucher-request into a bearer > > token for retrieving audit-log information (if the MASA accepts > > unauthenticated clients). > > That's what's intended. I can see why that functionality is needed, but it seems likely to introduce some privacy and/or security considerations to document. It's a bit too late in the day for me to reason through them, though. > > Section 11 > > > I am somewhat embarassed that I did not previously note that the > > mechanism used to generate the domainID needs to be > > second-preimage-resistant or an attacker can claim to be a registrar for > > a domain that already exists. > > Right now, that's in: > > 5.8.2. Calculation of domainID > > The domainID is a binary value (a BIT STRING) that uniquely > identifies a Registrar by the "pinned-domain-cert" > > If the "pinned-domain-cert" certificate includes the > SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be > used as the domainID. If not, the SPKI Fingerprint as described in > [RFC7469] section 2.4 is to be used. This value needs to be > calculated by both MASA (to populate the audit-log), and by the > Registrar (to recognize itself). > > We tried hard and found a way not to say SHA-1 directly, allowing SHA256 to > replace it appropriately. That's all good and admirable; I'm suggesting that we add a note in the security considerations of this document noting that we rely on the domainID (however determined) to be second-preimage-resistant. > > Section 11.2 > > doc> Although the nonce used by the Pledge in the voucher-request does not > doc> require a strong cryptographic randomness, the use of TLS in all of > doc> the protocols in this document does. > > > We discuss the need for strong randomness in the nonce in Section 11.3, > > so it's not clear this is actually true. > > We don't think that the voucher nonce has to be of the same quality as > something that > goes into a KDF. It is at the level of TCP Sequeunce number, not seed for > generating a private key... I mean, we literally say "Reducing the possibility of this is why the pledge is mandated to generate a strong random or pseudo-random number nonce." So to also say "the nonce [...] does not require a strong cryptographic randomness" seems to be in conflict with the former statement. Are you saying that "strong random" and "strong cryptographic random" mean different things, or am I misreading the document in some other way? Thanks, Ben _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
