[Isms] Comments on draft-schoenw-snmp-tlsm-02.txt

[Eric Rescorla <ekr at rtfm.com>]

S 5.1:
It's important to distinguish channel properties from handshake
properties. All TLS channels, even those set up with anonymous
DH keys, provide message integrity for the channel. I'm not
sure whether to call this auth or not, but...

S 5.1.1:
Why expose the master secret? Is there any need for it?


S 5.2:
I would move the discussion of requiring certs to the TLS section,
since the issues are basically the same.

I note you list SRP, which isn't really proceeding in TLS.
However, there is a PSK mechanism that has been approved by
the IESG.

S 5.3:
You should note here that with SASL you would need to 
use the channel security mode. Also, you should be citing
RFC 2831 as welll here...

S A.2:
      For SBSM, and for many TMSM models, securityName is specified
      during session setup, and associated with the session identifier.
      Is it possible for the request (and notification) originator to
      specify per message auth and encryption services, or are they are
      "fixed" by the transport/session model?

In major channel security protocol I know of, these properties
are fixed on a per-session basis.

      If a session is created as 'authPriv', then keys for encryption
      would still be negotiated once at the beginning of the session.
      But if a message is presented to the session with a security level
      of authNoPriv, then that message could simply be authenticated and
      not encrypted.  Wouldn't that also have some security benefit, in
      that it reduces the encrypted data available to an attacker
      gathering packets to try and discover the encryption keys?

Not really. In general, modern algorithms are not susceptible to
this kind of attack. 

      Some SNMP entities are resource-constrained.  Adding sessions
      increases the need for resources, we shouldn't require two
      sessions when one can suffice. 2 bytes per session structure and a
      compare or two is much less of a resource burden than two separate
      sessions.
      It's not just about CPU power of the device but the percentage of
      CPU cycles that are spent on network management.  There isn't much
      value in using encryption for a performance management system
      polling PEs for performance data on thousands of interfaces every
      ten minutes,it  just adds significant overhead to processing of
      the packet.  Using an encrypted TLS channel for everything may not
      work for use cases in performance management wherein we collect
      massive amounts of non sensitive data at periodic intervals.  Each
      SNMP "session" would have to negotiate two separate protection
      channels (authPriv and authNoPriv) and for every packet the SNMP
      engine will use the appropriate channel based on the desired
      securityLevel.
      If the underlying transport layer security was configurable on a
      per-message basis, a TMSM could have a MIB module with
      configurable maxSecurityLevel and a minSecurityLevel objects to
      identify the range of possible levels, and not all messages sent
      via that session are of the same level.  A session's
      maxSecurityLevel would identify the maximum security it could
      provide, and a session created with a minSecurityLevel of authPriv
      would reject an attempt to send an authNoPriv message.

This performance issue is raised a lot, but I'm not something I'm much
concerned with. Modern encryption algorithms are incredibly fast,
even on cheap processors. Unless you have measurements indicating
that this is a real problem, I don't think it's worth undertaking
the very substantial effort of re-working one of these protocols.


_______________________________________________
Isms mailing list
Isms at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms