Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)

From: Eliot Lear <[email-masked]>
Date: Wed, 17 Jun 2020 07:31:16 +0200

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 <[email-masked]> wrote:
> 
> Signed PGP part
> 
> Benjamin Kaduk <[email-masked]> 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   [
> ]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 17 Jun 2020 12:10:05 -0400

Eliot Lear <[email-masked]> wrote:
    > 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.

The rational for rfc822Name (which I fought against 4 years ago), is that:
  a) it gets through existing CA infrastructure without changes
  b) the human presentation format is *the* format

If ACP needs to wait for upgrades to the Enterprise CA that nobody wants to
touch, because it's voodoo, then ACP is dead.  This is hard enough to get
deployed as it is.

    > 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.

Because EKUs are so much easier to get into CAs than otherName is?
Seriously, how does that help at all?

---

From: Eliot Lear <[email-masked]>
Date: Wed, 17 Jun 2020 18:48:56 +0200

> On 17 Jun 2020, at 18:10, Michael Richardson <[email-masked]> wrote:
> 
>> 

I have definitely seen at least some CAs allow EKUs, such as XMPP, for instance, and was thinking of SHOULD rather than MUST.  But I do have to say that XMPP didn’t have a great experience with them, to be fair.

Eliot