Wes,
Awesome turnaround. I can still remember what I was thinking...
Deleting stuff that's done. Please see inline.
Thanks,
Spencer
2 WONTDO 3.1.1. Threats
~~~~~~~~~~~~~~~~~~~~~~~~~
"(D)TLS provides protection against the disclosure of information
to unauthorized recipients or eavesdroppers by allowing for
encryption of all traffic between SNMP engines. A TLS Transport
Model implementation SHOULD support the message encryption to
protect sensitive data from eavesdropping attacks."
+ Spencer (minor): OK, I'm completely out of my depth here,
but I'm confused by the SHOULD. Is this saying that an
implementation SHOULD support at least one non-NULL
encryption TLS cipher suite? Or something else? If not,
color me clueless, of course. But if so ... I don't think
this is a 2119 SHOULD, because IIUC, you're basically
saying, "if you don't support message encryption, then any
eavesdropper can read the messages", right?
+ WH: Your guess is correct. The SHOULD is saying you
SHOULD support a non-NULL encryption algorithm. But I'm
not sure why you're saying the SHOULD is out of place or
being used incorrectly. The first half of the paragraph
is really there to justify the SHOULD in the first place:
you SHOULD implement encryption so that bad things can't
happen.
Feel free to clarify your comment further as to why you
think the sentence should be deleted, but I don't (yet?) see
a reason to delete it.
Oh, I agree that you shouldn't delete it, especially since you confirmed
that it's normative. I was hoping for something a little more precise (like,
naming a mandatory-to-implement non-NULL encryption cipher suite :-) and I'm
now wondering why it's not a MUST/MUST unless X. But do the right thing ;-).
5 WONTDO 2)
~~~~~~~~~~~~
"The client selects the appropriate certificate and cipher_suites
for the key agreement based on the tmSecurityName and the
tmRequestedSecurityLevel for the session. For sessions being
established as a result of a SNMP-TARGET-MIB based operation, the
certificate will potentially have been identified via the
tlstmParamsTable mapping and the cipher_suites will have to be
taken from system-wide or implementation-specific configuration.
If no row in the tlstmParamsTable exists then implementations MAY
choose to establish the connection using a default client
certificate available to the application. Otherwise, the
certificate and appropriate cipher_suites will need to be passed
to the openSession() ASI as supplemental information or
configured through an implementation-dependent mechanism. It is
also implementation-dependent and possibly policy-dependent how
tmRequestedSecurityLevel will be used to influence the security
capabilities provided by the (D)TLS connection. However this is
done, the security capabilities provided by (D)TLS MUST be at
least as high as the level of security indicated by the
tmRequestedSecurityLevel parameter. The actual security level of
the session is reported in the tmStateReference cache as
tmSecurityLevel. For (D)TLS to provide strong authentication,
each principal acting as a command generator SHOULD have its own
certificate."
+ Spencer (minor): again, this doesn't sound like 2119
language to me - it sounds like a statement of fact. Are you
saying something like "If multiple principals acting as
command generators share a certificate, (D)TLS cannot
provide strong authentication"?
+ Functionally, yes. We're saying you SHOULD use separate
certificates for each command generator principal to achieve
stronger security. It's important that implementations
support this so that the protocol can be used securely.
This is kind of the same comment as the previous one - what I think you're
saying, in 2119-ese, is something like "Each principal acting as a command
generator MUST have its own certificate, unless the principal is not relying
on (D)TLS to provide strong authentication". But again, do the right thing.
6 DONE 2) continued:
~~~~~~~~~~~~~~~~~~~~~
"If the connection is being established for reasons other than
configuration found in the SNMP-TARGET-MIB then configuration and
procedures outside the scope of this document should be followed."
+ Spencer (clarity): I couldn't parse "reasons other than
connection
found in the SNMP-TARGET-MIB" at all - not enough to make a
suggestion. Is "connection found in the SNMP-TARGET-MIB" a
"reason"?
If so, I'd suggest putting it in quotes.
+ WH: this was recently changed to the following in order to
clairfy the text. Does this new text work for you as well?
If the connection is being established for reasons
other than configuration found in the SNMP-TARGET-MIB
then configuration and procedures outside the scope of
this document should be followed. Configuration
I'm easily confused, but isn't this sentence word-for-word what the original
text said? :D
But anyway. What I can't parse is whether I'm looking at
If the connection is (being established for reasons other than configuration
found in the SNMP-TARGET-MIB) then
or If the connection is being established for reasons other than
(configuration found in the SNMP-TARGET-MIB) then
or If the connection is being established for reasons other than
(configuration found) in the SNMP-TARGET-MIB then
or something else.
If this is clear to those skilled in the art, no problem. I'm just telling
you I can't parse it!
8 DONE 9. Security Considerations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"This document describes a transport model that permits SNMP
to utilize (D)TLS security services. The security threats and
how the (D)TLS transport model mitigates these threats are
covered in detail throughout this document. Security
considerations for DTLS are covered in [RFC4347] and security
considerations for TLS are described in Section 11 and
Appendices D, E, and F of TLS 1.2 [RFC5246]. When run over
UDP, DTLS is more vulnerable to denial of service attacks from
spoofed IP addresses; see Section 4.2 for details how the
cookie exchange is used to address this issue."
+ Spencer (minor): I'm confused by "When run over UDP"
here. My (hurried) read of
[http://www.rfc-editor.org/rfc/rfc4347.txt] seemed to point to
DTLS only making sense for datagram transport protocols. Is
this "Because it runs over a datagram transport, which does
not rely on return routability to set up a session, DTLS is
more vulnerable ..."? I'd strongly agree with that, if it's
what you are saying.
+ WH: That's functionally what I'm saying. (FYI, note that
DTLS also runs over both SCTP and DCCP). How does the
following wording sound as a replacement:
"When run over a connectionless transport such as UDP, DTLS
is more vulnerable to denial of service attacks from spoofed
IP addresses"
Works perfectly for me.
9 WONTDO 9.3. MIB Module Security
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPsec),
even then, there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the
objects
in this MIB module."
+ Spencer (nit): I don't think you need "even then, " in this
sentence, which already has one "Even" at the beginning.
+ WH: I agree, but this is functionally template text that is
required from the mib boiler plate. In fact it's so common
place that the exact phrasing above exists in 145 other
published RFCs ;-)
When I was typing this part of my review, I heard a former OPS AD's voice in
the back of my mind. Now I know why! :D
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf