Subject: Re: [Gen-art] Gen-ART LC Review of draft-ietf-radext-dtls-11

From: Jouni <[email-masked]>
Date: Thu, 1 May 2014 14:55:23 +0300

On Apr 30, 2014, at 11:39 PM, Ben Campbell wrote:

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

NOT RECOMMENDED is a RFC2119 keyword. The issue is that xml2rfc template does not include it.

- Jouni

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

---

From: Alan DeKok <[email-masked]>
Date: Thu, 01 May 2014 08:07:50 -0400

Ben Campbell wrote:
> I think it's reasonable to say that good administration practices involve random key generation, and that the interface should not prevent the entry of arbitrary hex strings. But the text says things like 
> 
> "When creating keys, it is RECOMMENDED that keys be derived from a cryptographically secure pseudo-random number generator (CSPRNG) instead of allowing administrators to invent "secure" keys on theur  [sic--add that as an editorial comment] own."  
> 
> That part seems to say explicitly that the implementation shouldn't let admins enter their own keys.

  It says nothing of the kind.  It says that administrators *inventing*
their own keys is bad practice.  They are still allowed to *enter* the
keys into the administration interface.

  People are bad at creating secure passwords.  That's all it's trying
to say.  I don't understand why this is controversial.

> I accept that, and my real concern is not about allowing the admin to enter arbitrary hex strings. My concern is that it also says the admin should not be able to enter their own keys (see above.) How do you expect the interface to prevent the use of "invented on their own" keys, while allowing arbitrary hex strings?

  I'm not a  jackass, and you shouldn't insinuate that I am one.

  The text says keys should be DERIVED from a secure source.  Do you
understand the DERIVING keys is about CREATING them?  And that is a
completely different process from ENTERING keys into an administration
interface?

> Are you explicitly recommending against doing client authentication in the DTLS handshake?

  Now you're being deliberately rude.

> That seems inconsistent with the 3rd paragraph, that says "Any authentication credentials for that client are then determined solely from the client identity, and not from an IP address."

  The authentication credentials it's talking about are the ones that
the server has.  i.e. when the client connects to the server, the server
must have some pre-configured credentials for that client.  It uses
those credentials to authenticate the client.

  Is that clear enough?  Or can you suggest alternative phrasing which
prevents people from deliberately misunderstanding the text?

> But, my concern was not just about servers authenticating clients. Paragraph 5 says: 
> 
> "authentication credentials for that relationship should also be statically configured.  That is, a client connecting to a DTLS server SHOULD be pre-configured with the servers credentials (e.g. PSK or certificate)."
> 
> That seems to exclude the possibility of the client being pre-configured with a host name for the server,

  No, it doesn't.  And it's ridiculous to claim that.  Especially when
it's in response to MY statement saying that such information is
statically pre-configured.

> then the server presents a certificate issued from a trusted CA that includes that host name. This is a common TLS/DTLS use case.  Now, maybe you consider that to still be static configuration of credentials, since the host name and the trust anchor need to be statically configured. But your statement that there is no (as in never?) binding of a certificate to a host name makes me think otherwise. (Or at least confused me.) 

  It's not hard, apparently.  I talked about servers checking client
certs.  You turned that into something clients checking server certs.

> I assume you expect to do something with trusted CAs, since paragraph 6 talks about their configuration.

  I have no idea what you assume or why.

  This review is done.  You've stepped past the bounds of social
propriety into insinuating I'm an idiot who engages in magical thinking,
among other deliberate misunderstandings.

  I'll try to weasel-word the document some more.  But it's hard to make
the document idiot-proof.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 May 2014 07:57:18 +1200

> NOT RECOMMENDED is a RFC2119 keyword. The issue is that xml2rfc template does not include it.

Actually, the bug is in RFC 2119 itself, which prescribes the text to be
used in RFCs but forgot "NOT RECOMMENDED". This is just something we live with.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 May 2014 08:13:03 +1200

On 02/05/2014 00:07, Alan DeKok wrote:
...
> the document idiot-proof.

If I can chip in, one thing that tends to happen in Gen-ART reviews
is that people who have essentially zero knowledge of the topic make
a serious effort to understand a draft. So they (we) do tend to
trip over things that are common knowledge to people active in the
field, and fail to make assumptions that seem obvious to specialists.

If you imagine the spec being implemented by a beginning programmer
who has never attended an IETF meeting and is reading the RFC
in a remote corner of the world, he or she is very likely to trip
over the same things and miss the same assumptions.

Personally I think that's one of the main benefits of non-specialist
reviews: finding the things that might confuse naive implementors.

(As an author, I've always tried to apply the principle that if even
one reviewer finds somthing unclear, then it *is* unclear and
I need to fix it.)

    Brian

---

From: Alan DeKok <[email-masked]>
Date: Thu, 01 May 2014 16:28:26 -0400

> field, and fail to make assumptions that seem obvious to specialists.

  I'm an advocate of given detailed recommendations in documents.

  My issue here was that the review did not state "the text is unclear".
 Instead, the review said that the *intent* of the text was something
patently ridiculous.

  Alan DeKok.