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: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
