Last Call Review of draft-ietf-radext-dtls-10
review-ietf-radext-dtls-10-genart-lc-campbell-2014-08-08-00

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-radext-dtls-11
Reviewer: Ben Campbell
Review Date: 2014-04-30
IETF LC End Date: 2014-04-30

Summary: This draft is almost ready for publication as an experimental RFC.
There are a few minor issues that should be considered prior to publication.

Note: I as assigned version 10, but 11 came out as I was working on the review.
This review is for version 11.

Note: This review is incremental to an early (pre-submission) review I did for
versions 7 and 8. Any comments from that review not repeated here have been
addressed either in the text or in correspondence.

Major Issues:

None.

Minor Issues:

-- 3.2, last paragraph:

I'm still confused about how this is a bid down attack.

[The author replied that, when secure and insecure packets are allowed from the
same client, a malicious or broken client can choose the insecure one.  That's
bad, when the intent is to use DTLS.]

While I agree that's bad, I don't see how it qualifies as a bid-down attack.
One assumes a malicious client already has access to the cleartext messages.
Are we talking about an MiTM "client"? Are there attacks where a third party
can induce the client or server to send unprotected packets, even with no
signaled negotiation? I can imagine one for the specific case where a node
falls back to clear text if DTLS packets fail; an attacker could induce
failures for DTLS packets, but that is covered elsewhere. Comment not addressed.

-- 6, 2nd and 3rd paragraph:

The RECOMMENDation to allow administrative entry of keys and to derive keys
from a PRNG seem contradictory.

[The author responded that it's a requirement that implementors allow
administrators to enter strong keys. but I don't get that from the text, which
both RECOMMENDS that the interface allow people to enter human readable hex
strings, and that keys should be derived from a PRNG instead of letting
administrators make up keys. How can it be both?

I don't see how an interface could prevent administrators from entering better
keys. Perhaps the intent is to offer or interface with tools for random
generation, or to scan entered keys for things with insufficient entropy?]

-- 10.3, 2nd paragraph:

This is redundant and inconsistent with previous normative requirements in
5.1.1.

[Author replied that it's worth reiterating security issues, and that the
sections were now consistent. But there's still conflicting normative
statements here. 5.1.1 says implementations SHOULD monitor number of sessions.
This section says MUST.

And I still assert that, even if the security issue is worth reiterating, it
should not be reiterated _normatively_.  Doing so creates confusion about which
text is authoritative, especially when they conflict. Even if they don't
conflict now, it's easy for future updates to accidentally create conflicts.]

-- 10.4 5th and 6th paragraphs:

Paragraph 5 says credentials should be manually configured, and strongly tied
to a host name. It is not clear to me from the text whether using a certificate
(perhaps issued by a trusted CA) to bind the credentials to the hostname is
permissible. The use of "manual" would seem to disallow that. But paragraph 6
talks about configuring trusted CAs.

[The author commented that dynamic discovery was out of scope--but I don't
think anything about this implies dynamic discovery. (e.g. configuring a client
to talk to foo.example.com, then using using a CA to validate that a server
certificate to ensure that that server really is foo.example.com is not the
same as dynamic discovery.]

-- 10.5, last paragraph:

This seems to be making normative statements about RADIUS/UDP. It's not
appropriate to make those statements here unless this draft normatively updates
RADIUS/UDP. (Which and experimental rfc shouldn't do.)

Nits and Editorial Comments:

-- idnits reports: The document seems to use 'NOT RECOMMENDED' as an RFC 2119
keyword, but
     does not include the phrase in its RFC 2119 key words list.

-- 6.1, first paragraph: "subsystem does not need to multiple
   multiple sessions on one socket"

I think one instance of "multiple" was intended as a different word?