Re: [Dtls-iot] Gen-ART Last Call review of draft-ietf-dice-profile-14

Hannes Tschofenig <hannes.tschofenig@gmx.net> Tue, 08 September 2015 19:24 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAB91B5354; Tue, 8 Sep 2015 12:24:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nrno0krO9S2n; Tue, 8 Sep 2015 12:24:51 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD791B534F; Tue, 8 Sep 2015 12:24:51 -0700 (PDT)
Received: from [192.168.10.169] ([213.235.249.182]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MOwY7-1ZbqYZ1Syd-006Or0; Tue, 08 Sep 2015 21:24:49 +0200
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, draft-ietf-dice-profile.all@ietf.org, General Area Review Team <gen-art@ietf.org>
References: <55E63507.40404@gmail.com>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
X-Enigmail-Draft-Status: N1110
Message-ID: <55EF35FA.5020709@gmx.net>
Date: Tue, 08 Sep 2015 21:24:42 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <55E63507.40404@gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="Op0Pi7aphdIlBLfROt79EvnJc9uAFKveC"
X-Provags-ID: V03:K0:NTdULf+CFGIvuenRDHwZ0Xfw7fkk3u8feGPxcczndnmeYV1SsrV BjV8ydQbKi+MbqVyUe/sTIXwG4soeaKNbXxQY4oM12+ji1ysJ5gIQcIY8oyU/Cj61+u1xBW +dn5GGRljb7ueG5m7dVDYoBddBIJz51rOXRCSUQEDP+l8sYypFK9dJgk3poJpn4N3b0hmMO RVdLdM+07R0KMvVWzZ8uA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:D98XhYMNQiE=:rPy0Se5XdHAtNEbnjvjgfd SaRw1Dg1AdrRThlXWNmoHo+HC1Hbp0vZ7uYkihk7XlhTQqQj3A/E8BQa61gDntkNETAyuHuwJ ASyl2uLLdryye3xKSKSZAW9sWCLBRYrdaIA42LHyO2YyYddf2ZAdjlmYn/CkiU3xbVHi81SWC HTGl2+PiLh0eeauovUQfs2Cs8gMJerf8O3Z9aMn3hQxkKAVLSpZexYQkycsTuRYKTpqqC2yYK knaOFFqc8HQLGBRIkfYSmS8uRZaVoNB/bOC2+9gc3CYAcNV9fkkLfmCsBxZZCuIQBep6Ty2KI wDcJU7UNbP2ORj+M2YWIKNjue0ohP6NYkjkYN6s5gMWpJ66oD8Uq0KApYcKMyWWhbM29XgVYl ZRTh0+AEjU27xxRHeqm8eDFN8qHWgTEeEYS3m5M7sNh5ztCDVjIYFvJFEuYt77Q1gr4KJQlqa BXQ4HsFwFKPPHSziBekiIvTwvPX3YqILaJug6VAm/iXZ9+gUwSlL1Ujc+eUL3ImsRGciiQ+8o PMMNF+XOywsAwxRYvA26wPza7b/ci9rP5tA+UoGwRdygsNBSLJsbe3k6dEjwfLv5KcOLBdUtC ZOBQG1YrR7/kHkxaKJi53eVworjM/UL2hPXHBaIid3c7P70JbUHYaeudKMtfbMh0AUJm5OP/D mgQp8Hm7JIjvGjXebXY2CNozvZRLE0n5+Yz1nayLc9A9cnHqT0MMTeJ+RPYV8JSNgldV+tHPh uGNJhh2wiQugLkKb
Archived-At: <http://mailarchive.ietf.org/arch/msg/dtls-iot/wQqrRZJVJkPfQq7kWwM3EJExfrs>
Cc: "dtls-iot@ietf.org" <dtls-iot@ietf.org>
Subject: Re: [Dtls-iot] Gen-ART Last Call review of draft-ietf-dice-profile-14
X-BeenThere: dtls-iot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DTLS for IoT discussion list <dtls-iot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtls-iot/>
List-Post: <mailto:dtls-iot@ietf.org>
List-Help: <mailto:dtls-iot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Sep 2015 19:24:53 -0000

Hi Brian,

thanks for your review. Please find my responses below.

On 09/02/2015 01:30 AM, Brian E Carpenter wrote:
> 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.

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

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

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

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

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

> 
> 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.))
> 
I let Thomas respond to this issue.


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

Good catch. Thanks.


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

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.

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

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

> 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.))
> 
Thanks for pointing this out.

Ciao
Hannes