Last Call Review of draft-ietf-radext-dtls-10

Request Review of draft-ietf-radext-dtls
Requested rev. no specific revision (document currently at 13)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-05-13
Requested 2014-04-16
Authors Alan DeKok
Draft last updated 2014-08-08
Completed reviews Genart Early review of -07 by Ben Campbell (diff)
Genart Last Call review of -10 by Ben Campbell (diff)
Secdir Early review of -06 by Brian Weis (diff)
Secdir Last Call review of -10 by Brian Weis (diff)
Assignment Reviewer Ben Campbell
State Completed
Review review-ietf-radext-dtls-10-genart-lc-campbell-2014-08-08
Reviewed rev. 10 (document currently at 13)
Review result Almost Ready
Review completed: 2014-08-08


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


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:


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, then using using a CA to validate that a server certificate to ensure that that server really is 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?