Hi, Could we recap a bit on this? I have commented on the use of the rfc822Name myself, and was a bit concerned about misuse and misinterpretation prior to rfcSELF being present.
Now that it is it represents a new convention. The question at hand is whether the information found on the LHS could be subject to misinterpretation by non-participants. I wonder if we could add an EKU as a SHOULD to break the logjam. Eliot > On 1 Nov 2019, at 21:14, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > Signed PGP part > > Benjamin Kaduk <ka...@mit.edu> wrote: > 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. > > To be clear: any registrar which has ever formed a valid voucher-request MAY > retrieve the audit-log at regular intervals to verify the status of the > device. The words, "now already validated" means that the MASA agreed with > the voucher-request. Most implementations are going to log the > voucher-request as part of the internal audit log, so a memcmp() on that is > enough. > > This would reveal new owners. Whether the new owner is legitimate or not is > not something we can answer: it might be that the device has been stolen, or > maybe it's legitimately lent, rented, sold, etc. > >>>> 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. > > I've added this to the security considerations as 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? > > I take your point, and I guess we were splitting hairs. > I'll just rephrase it to remove the Although statement. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT architect [ > ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails > [ > > > > -- > Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
