Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-dice-profile-14

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 Sep 2015 11:30:15 +1200

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-dice-profile-14.txt
Reviewer: Brian Carpenter
Review Date: 2015-09-02
IETF LC End Date: 2015-09-04
IESG Telechat date:

Summary:  Ready with issues
--------

Comment:
--------

This is complicated and I'm not an expert. I went through the whole document but have to
take most of the details on trust.

Major Issues:
-------------

One thing puzzles me. Unless I have missed it, the profile is neutral on the choice
described in Section 6 (Credential Types): pre-shared secrets, raw public keys, or
certificates. How does this work to help interoperability in multivendor environments?
Wouldn't it be better to RECOMMEND one?

((The answer to this interests me in the Anima context too.))

Would it be possible to add a summary table of the MUST, SHOULD, MAY and MUST NOT
items in the profile? At the moment there is a lot of prose and nothing that
can be used as an implementer's check list.

Minor Issues:
-------------

"  Figure 7 shows an example interaction... The IPv6
   multicast address used for site-local discovery is FF02::FD."

Where does ff02::fd come from? Is it just used as an example? That isn't clear
in the text. (IANA lists it as "variable scope allocation".)

((Incidentally, this is a side track, but note that a command such as
GET coap://[FF02::FD]/.well-known/core is problematic in a device with more
than one interface, unless you support RFC6874.))

"6.4.2.  Certificates used by Clients

   For client certificates the identifier used in the SubjectAltName or
   in the leftmost CN component of subject name MUST be an EUI-64, as
   mandated in Section 9.1.3.3 of [RFC7252]."

Actually it is not mandated there, it is only suggested:
"  The subject in the certificate would be built out of a long-term
   unique identifier for the device such as the EUI-64 [EUI64]."
You can certainly choose to mandate it here, but s/mandated/described/
in the text.

However, I am confused by this MUST in 6.4.2, and other normative keywords in Section 6.
Are we now in the specification of the DICE profile, or are we still in the descriptive text?
I would expect a very clear break in the text when we move from description to specification.
Looking at the table of contents, I can't figure out where that point is.

OK, now I found a sentence at the beginning: "If you are familiar with (D)TLS, then
skip ahead to Section 6." But please reflect this in the arrangement of the sections.
I would suggest nesting sections 3,4, and 5 within a single "Overview" section, and put
something at start of section 6 to make it clear that is where the profile starts.
Or nest sections 6 etc. inside a single "Profile" section.

Nits:
-----

The RFC2119 boilerplate is messed up.

== Outdated reference: draft-ietf-tls-sslv3-diediedie has been published as
   RFC 7568

The downref to RFC7251 was not mentioned in the last call and that RFC isn't
in the downref registry. ((Yes, I've been in the IESG and I know how
annoying this can be, but it's a process glitch.))

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 8 Sep 2015 21:24:42 +0200

Hi Brian,

thanks for your review. Please find my responses below.

> take most of the details on trust.

I hope you still found the document readable since we envision that many
readers are not security experts.

> Major Issues:

In an IoT environment it is quite likely that not every device will
interact with every other device. At least today, the interoperability
is accomplished at the level of backend interworking. (For more details
about the different architectural choices please take a look at the IAB
publication on Smart Object Architectures.)

If you want to have devices to randomly interwork then many conditions
must hold and
today we are unfortunately still far away from this ideal state.

Even if I would like to recommend something I will rule out certain
deployments. Preshared secrets are more efficient and better suited for
the low-end devices but have limitations in terms of security. Public
key cryptography is certainly much better but is not a good choice for
all deployments.

> ((The answer to this interests me in the Anima context too.))

Btw, ANIMA will also increase the lack of interoperability overall since
there is yet another solution that some devices will not support.

(The same is true for OIC, Alljoyn, OMA, etc.)

> can be used as an implementer's check list.

The challenge is that there a lot of "depends on" qualifications.

> Minor Issues:
I let Thomas respond to this issue.

> You can certainly choose to mandate it here, but s/mandated/described/

Good catch. Thanks.

> Or nest sections 6 etc. inside a single "Profile" section.

I took a look at your proposed restructuring and I like the result.

Btw, the suggestion to put a forward reference to Section 6 into the
introduction was a recommendation from Stephen.

> The RFC2119 boilerplate is messed up.
Hmmm. I am using regular XML2RFC.

> == Outdated reference: draft-ietf-tls-sslv3-diediedie has been published as
Fixed.

> annoying this can be, but it's a process glitch.))
Thanks for pointing this out.

Ciao
Hannes

---

From: "FOSSATI, Thomas (Thomas)" <[email-masked]>
Date: Wed, 9 Sep 2015 08:07:49 +0000

Hi Brian,

On 02/09/2015 00:30, "Brian E Carpenter" <[email-masked]<mailto:[email-masked]>> wrote:
Minor Issues:
-------------

FF02::FD is the link-local "all CoAP Nodes" (see https://tools.ietf.org/html/rfc7252#section-12.8 and http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml).

Cheers, t

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Sep 2015 08:14:05 +1200

> On 02/09/2015 00:30, "Brian E Carpenter" <[email-masked]<mailto:[email-masked]>> wrote:

Oh. I find the registry very confusing. It would help ignorant people like
me if the sentence read

"The IPv6 multicast address used for CoAP site-local discovery is FF02::FD."

except that there *is* a bug in that sentence: ff02:: is the link-local range,
site-local would be ff05::fd. So it should be

"The IPv6 multicast address used for CoAP link-local discovery is FF02::FD."

Thanks
    Brian

---

From: "FOSSATI, Thomas (Thomas)" <[email-masked]>
Date: Thu, 10 Sep 2015 06:22:56 +0000

On 09/09/2015 21:14, "Brian E Carpenter" <[email-masked]>
wrote:
>> On 02/09/2015 00:30, "Brian E Carpenter"
>><[email-masked]<mailto:[email-masked]>> wrote:
>> Minor Issues:
>> -------------
>> 
>> FF02::FD is the link-local "all CoAP Nodes" (see
>>https://tools.ietf.org/html/rfc7252#section-12.8 and
>>http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-a
>>ddresses.xhtml).
>

Fixed, thanks.

Cheers, t

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 14 Sep 2015 14:27:51 +0100

Hi Brian, Hannes,

> Thanks for pointing this out.

Yep, mea culpa for not spotting that. However, RFC 7252 (CoAP, a PS)
also has a normative reference to 7251, on which basis I think we can
safely claim that this is no longer a downref. Actually, it looks
like the downref also wasn't called out in the CoAP IETF LC, but I
guess the sky didn't fall, so that's ok:-) And recall that the
definition of an ok downref is one that's "accepted by the community"
(says [1]) and I think CoAP is as is AES-CCM.

I plan to add 7251 to the downref registry [2] shortly, and to put the
DICE profile on the Oct 1 IESG telechat. If however, that's too much
of a process sin, there's still time to do another IETF LC on the
DICE profile without affecting the timing. So while I figure we're ok
without that, I'll do the 2nd IETF LC if anyone yells now.

Cheers,
S.

[1] https://tools.ietf.org/html/rfc3967#section-3
[2] https://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Sep 2015 08:10:25 +1200

> without that, I'll do the 2nd IETF LC if anyone yells now.

I promise not to appeal. The downref rules are quite creaky and annoying,
so I'd support them being overhauled anyway, as long as egregious downrefs
can still be prevented or appealed.

While I'm typing - I'm quite happy with the -16 draft and if that comes
up for a further review I will call it "Ready".

Regards,

   Brian

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 14 Sep 2015 22:31:42 +0100

> can still be prevented or appealed.

Yep. Anything can always be appealed of course, and ID nits does call
it out, but we (all of us) miss these over and over again.

FWIW, my own impression is that the current IESG are more ok with the
"accepted by the community" criterion being asserted (e.g. by the
responsible AD) as obviously being the case. And I think that's a
good thing, so we can avoid more of the process-only IETF last calls.

Cheers,
S.

PS: I've added 7251 to the downref registry and called out the
potential blooper in my ballot writeup. [1]

   [1] https://datatracker.ietf.org/doc/draft-ietf-dice-profile/writeup/