Subject: [Isms] review of dtls transport model

From: "David Harrington" <[email-masked]>
Date: Mon, 4 May 2009 15:26:30 -0400

Hi Wes,

I started reviewing your dtls-03 draft. I got ten pages in before
being distracted by other priorities.
But I might as well comment on that much ;-)

1) RFC3411 is NOT  The SNMPv3 architecture. It is "An" architecture.
If we want to be able to ever get rid of this architecture and its ASI
shackles, please do not refer to it as THE SNMPv3 architecture. It is
the RFC3411 architecture.

2) page 5 Introduction. I recommend moving the 4th paragraph "this
document also specifies" before the third paragraph "Managed objects
are accessed". 

3) you have quite a lot of duplicate cxut-and-paste "boilerplate"
discussion. section 1.1 is duplicated in section 1.2 paragraph 6 and
paragraph 10. Many of the paragraphs on page 7 are also on page 8. 

4) The discussion of client/server terminology refers to SSH.

5) section 2.1 discusses threats. I think the bullets go into way too
much detail about how DTLS mitigates the threats. All we need here is
a list of the threats DTLS mitigates; readers can go read the DTLS
spec to see details of the encryption protocols supported and the
integrity checking protocols supported.

6) section 2.2 also goes into details about the cryptographic
protocols supported by DTLS. We don't need that detail here.

7) section 2.2 discusses that autheintication can be made optional. I
recommend moving this discussion to Security Considerations.

8) section 2.3 talks about securityName and the fact it is used for
access control. I don't think this is needed. This is covered in the
RFC3411 architecture extensively. If you want to make sure people
understand how it is used, cite RFC3411 or the Transport Subsystem
architectural extension document.

9) section 2.3 says mutual authentication SHOULD always be used with
DTLS. Is this actually a requirement of SNMP, or of this model? SNMP
permits noAuthNoPriv as a securitylevel, so authentication of any type
appears to not be an SNMP requirement. I don't recall whether mutual
auth is required for sshtm.

10) section 3 uses a capitaized Dispatcher and a lower case
dispatcher. be consistent. I prefer lower case.

11) For the threat analysis in 3.1.1, I recommend you use pointers to
the TSMS or SSHTM documents, and just supplement the pointers as
needed for DTLS security features.

12) Pasi had the syslog/DTLS draft use pointers to the syslog/TLS RFC
to discuss certificate handling, etc. Unless your handling needs to be
significantly different for SNMP, I expect Pasi will want you use
pointers to the syslog/TLS RFC as well, for consistency of TLS/DTLS
configuration requirements and processing behaviors. 

I'll try to get more to you later.

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 04 May 2009 13:39:01 -0700

>>>>> On Mon, 4 May 2009 15:26:30 -0400, "David Harrington" <[email-masked]> said:

DH> I started reviewing your dtls-03 draft. I got ten pages in before
DH> being distracted by other priorities.  But I might as well comment
DH> on that much ;-)

I appreciate all comments, even if they're only on part of the document.

I'll incorporate them into a future version of the draft.

DH> 1) RFC3411 is NOT  The SNMPv3 architecture. It is "An" architecture.
DH> If we want to be able to ever get rid of this architecture and its ASI
DH> shackles, please do not refer to it as THE SNMPv3 architecture. It is
DH> the RFC3411 architecture.

Good catch.  I can't believe I didn't notice that myself ;-)

DH> 3) you have quite a lot of duplicate cxut-and-paste "boilerplate"
DH> discussion.

A bunch of the boilerplates were copied from one of the recent SSH
documents, and since that time a bunch of the text was removed from the
SSH document but not from the last published DTLS document (though it's
changed on my disk).

I'll make sure I check the text you're referring to.  I'm sure there is
more that could be removed.

DH> 4) The discussion of client/server terminology refers to SSH.

That's already been fixed, but thanks.

DH> 5) section 2.1 discusses threats. I think the bullets go into way too
DH> much detail about how DTLS mitigates the threats. All we need here is
DH> a list of the threats DTLS mitigates; readers can go read the DTLS
DH> spec to see details of the encryption protocols supported and the
DH> integrity checking protocols supported.

I'm not sure if you're referring to the right section here.  3.1.1
discusses threats (though some of it is also discussed in 2.1).

The SSH document has a fairly lengthy threats section too...

See [*] below for further discussion on text removal.

DH> 6) section 2.2 also goes into details about the cryptographic
DH> protocols supported by DTLS. We don't need that detail here.

[*] Some of the document was written by others and they had included a
lot of background reading material.  More so than in most IETF
documents.  I left most of it in deliberately in order to see where
people think the line should be drawn.  You're actually the first to
comment on the quantity and relevance of it, but then again it's only
fairly recently in the headlights of the WG.  Feel free to continue
commenting on which sections you think should be shortened and I'll take
your opinion and others into consideration as I consider slimming it
down.

DH> 7) section 2.2 discusses that autheintication can be made optional. I
DH> recommend moving this discussion to Security Considerations.

If the section stays, I think it's important to note that it can be
optional in order to understand the protocol itself.  I don't think
moving that one sentence to later in the document helps the reader
understand the aspects of the protocol.

DH> 9) section 2.3 says mutual authentication SHOULD always be used with
DH> DTLS. Is this actually a requirement of SNMP, or of this model?
DH> SNMP permits noAuthNoPriv as a securitylevel, so authentication of
DH> any type appears to not be an SNMP requirement. I don't recall
DH> whether mutual auth is required for sshtm.

The wording in sshtm is a bit more fuzzy.  IMHO, we're defining a secure
transport so specifying that you MUST authenticate the client and you
SHOULD authenticate the agent are requirements that stem from how you'd
use the transport.

But I actually think you're right.  Because that is already covered
later in the document when discussing security levels, so I don't
necessarily think it needs to go here too.  And the text later properly
handles noAuthNoPriv I think as well.

DH> 11) For the threat analysis in 3.1.1, I recommend you use pointers to
DH> the TSMS or SSHTM documents, and just supplement the pointers as
DH> needed for DTLS security features.

I think if you compare 3.1.1 from the SSHTM document and this one you'll
find they're pretty similar in structure and content.  The SSHTM one is
shorter though and the wording is a bit more concise.

DH> 12) Pasi had the syslog/DTLS draft use pointers to the syslog/TLS RFC
DH> to discuss certificate handling, etc. Unless your handling needs to be
DH> significantly different for SNMP, I expect Pasi will want you use
DH> pointers to the syslog/TLS RFC as well, for consistency of TLS/DTLS
DH> configuration requirements and processing behaviors. 

I'll take a look at the other document to see what they did.  I'm sure
Pasi will comment on the document on multiple viewpoints.  Again, I'll
refer to [*] above.

DH> I'll try to get more to you later.

Thanks, I look forward to them!
-- 
Wes Hardaker
Cobham Analytic Solutions