Subject: [Isms] revew of snmp/dtls, part II

From: "David Harrington" <[email-masked]>
Date: Thu, 17 Dec 2009 17:37:44 -0500

Hi,

Picking up at 5.3

paragraph 1 references 5.3

"This MAY be done automatically" - you explicitly exampt Report and
Response messages. rfc5590 deliberately did not sayt these OK, these
not, but used "applications that initiate, such as" because SNMPv3 is
designed to allow new applications to be developed in the future.

I am conmcerned to see the selection of cyphersuites discussed  in the
Elements of Procedure. This is something that I think should be out of
scope for an ISMS document. We are supposed to be using the existing
underlying secure transport, without the TM having any knowldege of
the details of the security. Which cyphersuites get used should be
configured for the TLS layer, and the TM EOP should be blissfully
unaware of this TLS-layer configuration. If the TM needs to be
pre-configured with a list of the acceptable certificates and
ciphersuites, then this TM misses the point of ISMS.

I think trying to support multiple security levels is a mistake. If
you don't want security, don't use a secure transport. Duh! We have
multiple security level support in USM. I am unaware that anybody
actually uses multiple securitylevels in the real world, except for
very specific things like auto-discovery. You don't need that
supported in every TM. We don't support it in SSHTM, and we don't need
it here. Let's not add complexity for the sake of adding complexity.
Nobody NEEDS this.

Implementations can choose to supplement the standard with as much
complxiety as their customers demand, but we don't need that
complexity turned into a MUST-implement requirement of the standard.
The standard should be simple enough to encourage implementers to
implement a standard baseline to achieve interoperability. Stop adding
unnecessary complexity.

- "       tlstmSessionOpenErrors is incremented, an error indication
is
       returned, and processing stops.  If the session failed to open
       because the presented server certificate was unknown or invalid
       then the tlstmSessionUnknownServerCertificate or
       tlstmSessionInvalidServerCertificates MUST be incremented and a
       tlstmServerCertificateUnknown or tlstmServerInvalidCertificate
       notification SHOULD be sent as appropriate.  Reasons for server
       certificate invalidation includes, but is not limited to,
       cryptographic validation failures and an unexpected presented
       certificate identity."
"includes but is not limoted to"? So different implementations are
allowed to choose which conditions they want to count in their
counter? So how do you compare these across implementations? Where is
the interoperability? How can an operator use this information
effectively if the implementation can choose what gets counted? A
standard should be CLEAR and UNAMBIGUOUS.

Again, I think you are getting way too detailed in the knowledge of
the TLS implementation. 

step a) requires preconfiguration. Did I miss something? Is this no
longer the ISMS WG, which was trying to minimize or eliminate
preconfiguration for SNMP-specific credentials and parameters, and
just use what was already available from the lower layer secure
transport? Complexity, complexity, complexity.

"       b)  The (D)TLS client side of the connection MUST verify that
           authenticated identity of the (D)TLS server's certificate
is
           the certificate."
I'm not sure I understand what this says. "is the certificate"? what
certificate? The one we're checking? 

s/           determine the if the presented identity matches the/???/

"   4)  The (D)TLS-specific session identifier is passed to the TLS
       Transport Model and associated with the tmStateReference cache
       entry to indicate that the session has been established
       successfully and to point to a specific (D)TLS session for
future
       use."
does this mean "set the sessionID in the tmStateReference cache to the
session identifier passed to tlstm from TLS?

"   Servers that wish to support multiple principals at a particular
port"
Does this really have to be part of TLSTM? We are defining a standard
baseline for interoperability. Why we do we even need to know if the
implementers choose to support some additional complexity in the TLS
layer?

In SSHTM, we have a sessionscloses counter; is ti deliberate that we
don't bother to increment one for closed tls sessions?

In SSHTM, closing a session only requires the sessionID from the
tmStateReference; In TLSTM, you pass in a whole tmStateReference. Is
this really necessary?

dbh

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 18 Dec 2009 10:38:06 +0100

> standard should be CLEAR and UNAMBIGUOUS.

I don't find the text ambiguous. It says that counters MUST be
incremented when a presented server certificate is unknown or invalid.
The text then provides some example reasons why a server certificate
can be considered unknown or invalid. This is advice to implementors.
Are you suggesting to remove helpful implementation hints?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 18 Dec 2009 09:36:14 -0800

>>>>> On Thu, 17 Dec 2009 17:37:44 -0500, "David Harrington" <[email-masked]> said:

DH> Picking up at 5.3

David,

Thanks for the notes; I'll be examining them in detail in the coming
week-ish.
-- 
Wes Hardaker
Cobham Analytic Solutions