Spencer,
I've reviewed your comments about the draft-ietf-isms-dtls-tm-09
document and am responding to them below. Thanks again for the review
and please let me know if you want to discuss any of the items further!
My responses are prefixed below with "WH:" if you want to search for
them. The status of each item is as follows:
DONE: Suggestion was acted on
WONTDO: Nothing was done; refer to the WH: response for reasons why
DISCUSS: There is an outstanding question back to you
ANSWERED: A question was answered but had no action resulting from it
Comments and responses:
1 DONE 3. How the TLSTM fits into the Transport Subsystem
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"The diagram below depicts where the TLS Transport Model
fits into the architecture described in RFC3411 and the
Transport Subsystem:"
+ Spencer (clarity): the words "TLS Transport Model" appears
nowhere in the following figure that I could see. I'm pretty
sure I know what you're talking about (the box labeled
"(D)TLS TM"), but I'm guessing. My suggestion is to rephrase
so that the reader can match the previous sentence and the
figure - perhaps "... the TLS Transport Model, shown as
(D)TLS TM, fits ..."
+ WH: Good point; I've not only changed the reference to
that diagram but also to the diagram in a previous section
which suffered from a similar problem.
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.
(note that another comment received during last call
indicated that the word "the" shouldn't appear in "the
message encryption" and has since been removed).
3 DONE 5.1.1. DTLS over UDP Processing for Incoming Messages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"2) The TLS Transport Model queries the LCD using the transport
parameters (source and destination IP addresses and ports) to
determine if a session already exists.
2a) f a matching entry in the LCD does not exist, then the UDP"
+ Spencer (nit): s/f a/If a/
+ WH: yep, thanks! (other reviewers caught this too).
4 DONE 5.3.1. Establishing a Session as a Client
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"The following describes the procedure to follow when establishing a
SNMP over (D)TLS connection between SNMP engines for exchanging SNMP
messages. This process is followed by any SNMP client's engine when
establishing a session for subsequent use.
This MAY be done automatically for an SNMP application that initiates"
+ Spencer (clarity): I was having pronoun problems here - perhaps "This
primative MAY be invoked automatically for an SNMP application..."?
+ WH: changed to "This procedure"
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.
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
7 DONE 8.4. Transport Considerations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"This document defines how SNMP messages can be transmitted
over the TLS and DTLS based protocols. Each of these
protocols are additionally based on other transports (TCP and
UDP). These three protocols also have operational
considerations that must be taken into consideration when
selecting a (D)TLS based protocol to use such as its
performance in degraded or limited networks. It is beyond the"
+ Spencer (clarity): I'm counting SNMP, TLS, DTLS, TCP, and
UDP, so I'm not sure which three protocols you're talking
about here. I'm guessing you meant SNMP, TLS/TCP, and
DTLS/UDP, but I'm guessing. Not sure you even need a number,
but "three" wasn't helpful to me.
+ WH: Good catch! The three was a left-over from when the
document discussed both DTLS/UDP and DTLS/SCTP. The "three"
should now be "two" and I've changed it to additional
include the word "base" for further clarity:
"These two base protocols also have operational..."
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"
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 ;-)
10 DONE 10. IANA Considerations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ Spencer (minor): Is this a note to remind the editor (not the
RFC-Editor) to replace text during AUTH48? Not sure I've ever seen one
like it before :D
+ WH: Ha! Good point; thanks (and fixed).
--
Wes Hardaker
Cobham Analytic Solutions
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf