Subject: [Gen-art] Gen-ART review of draft-ietf-isms-dtls-tm-10

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 3 May 2010 15:00:55 -0500

I had reviewed -09 at IETF Last Call time, all my questions have been 
answered in -10, and I didn't see any issues resulting from new text. Ready 
for publication as a Proposed Standard.

Spencer

----- Original Message ----- 
From: "Spencer Dawkins" <[email-masked]>
To: <[email-masked]>
Cc: "General Area Review Team" <[email-masked]>; 
<[email-masked]>
Sent: Wednesday, April 14, 2010 8:10 AM
Subject: [Gen-art] Gen-ART review of draft-ietf-isms-dtls-tm-09

> Document: draft-ietf-isms-dtls-tm-09
> Reviewer: Spencer Dawkins
> Review Date: 2010-04-14 (epic fail on getting review done - sorry!)
> Last Call ends: 2010-04-02
> IESG Telechat date: 2010-05-06
>
> Summary: This specification is almost ready for publication as a Proposed 
> Standard. I do have some (late Last Call) questions, almost all of which 
> are around either 2119 language or clarity.
>
> Thanks,
>
> Spencer
>
>
> 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 ..."
>
>
>   +------------------------------+
>   |    Network                   |
>   +------------------------------+
>      ^       ^              ^
>      |       |              |
>      v       v              v
>   +-------------------------------------------------------------------+
>   | +--------------------------------------------------+              |
>   | |  Transport Subsystem                             |  +--------+  |
>   | | +-----+ +-----+ +-------+             +-------+  |  |        |  |
>   | | | UDP | | SSH | |(D)TLS |    . . .    | other |<--->| Cache  |  |
>   | | |     | | TM  | | TM    |             |       |  |  |        |  |
>   | | +-----+ +-----+ +-------+             +-------+  |  +--------+  |
>   | +--------------------------------------------------+         ^    |
>   |              ^                                               |    |
>   |              |                                               |    |
>   | Dispatcher   v                                               |    |
>   | +--------------+ +---------------------+  +----------------+ |    |
>   | | Transport    | | Message Processing  |  | Security       | |    |
>   | | Dispatch     | | Subsystem           |  | Subsystem      | |    |
>   | |              | |     +------------+  |  | +------------+ | |    |
>   | |              | |  +->| v1MP       |<--->| | USM        | | |    |
>   | |              | |  |  +------------+  |  | +------------+ | |    |
>   | |              | |  |  +------------+  |  | +------------+ | |    |
>   | |              | |  +->| v2cMP      |<--->| | Transport  | | |    |
>   | | Message      | |  |  +------------+  |  | | Security   |<--+    |
>   | | Dispatch    <---->|  +------------+  |  | | Model      | |      |
>   | |              | |  +->| v3MP       |<--->| +------------+ |      |
>   | |              | |  |  +------------+  |  | +------------+ |      |
>   | | PDU Dispatch | |  |  +------------+  |  | | Other      | |      |
>   | +--------------+ |  +->| otherMP    |<--->| | Model(s)   | |      |
>   |              ^   |     +------------+  |  | +------------+ |      |
>   |              |   +---------------------+  +----------------+      |
>   |              v                                                    |
>   |      +-------+-------------------------+---------------+          |
>   |      ^                                 ^               ^          |
>   |      |                                 |               |          |
>   |      v                                 v               v          |
>   | +-------------+   +---------+   +--------------+  +-------------+ |
>   | |   COMMAND   |   | ACCESS  |   | NOTIFICATION |  |    PROXY    | |
>   | |  RESPONDER  |<->| CONTROL |<->|  ORIGINATOR  |  |  FORWARDER  | |
>   | | application |   |         |   | applications |  | application | |
>   | +-------------+   +---------+   +--------------+  +-------------+ |
>   |      ^                                 ^                          |
>   |      |                                 |                          |
>   |      v                                 v                          |
>   | +----------------------------------------------+                  |
>   | |             MIB instrumentation              |      SNMP entity |
>   +-------------------------------------------------------------------+
>
> 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?
>
> 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/
>
>            packet is passed to the DTLS implementation for processing.
>            If the DTLS implementation decides to continue with the
>            connection and allocate state for it, it returns a new DTLS
>            connection handle (an implementation dependent detail).  In
>            this case, TLSTM selects a new tlstmSessionId, and caches
>            this and the DTLS connection handle as a new entry in the
>            LCD (indexed by the transport parameters).  If the DTLS
>            implementation returns an error or does not allocate
>            connection state (which can happen with the stateless cookie
>            exchange), processing stops.
>
> 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..."?
>
>   a transaction, such as a command generator, a notification
>   originator, or a proxy forwarder.
>
>   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"?
>
>       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.
>
>       Configuration mechanisms SHOULD be similar in nature to those
>       defined in the tlstmAddrTable to ensure consistency across
>       management configuration systems.  For example, a command-line
>       tool for generating SNMP GETs might support specifying either the
>       server's certificate fingerprint or the expected host name as a
>       command line argument.
>
> 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.
>
>   scope of this document to summarize the characteristics of these
>   transport mechanisms.  Please refer to the base protocol documents
>   for details on messaging considerations with respect to MTU size,
>   fragmentation, performance in lossy-networks, etc.
>
>
> 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.
>
> 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.
>
> 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
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 17 May 2010 18:04:52 -0500

The text I commented on from -07 no longer exists in -08, so my only 
previous comment no longer applies.

There is a fair amount of new text in -08, but I didn't see anything that 
required attention, so I'm going with "ready for publication as a proposed 
standard".

Thanks,

Spencer

> Document: draft-freed-sieve-notary-07
> Review Date: 2010-04-05
> IESG Telechat date: 2010-04-08
>
> Summary: This draft is roughly ready for publication as a Proposed 
> Standard. I found one minor problem which MIGHT just be a cut-and-paste 
> error, but someone needs to look at it...
>
> Thanks,
>
> Spencer
>
> 7.  redirect-deliverby extension
>
>   :bytime specifies the number of seconds within which the message
>   should be delivered. :bymode specifies whether a notification should
>   be sent or the message simply returned if the time limit is exceeded.
>   The default is "return" if :bymode is not specified.  See The
>   semantics of delivery time limits are specified and discussed at
>   length in [RFC2852].
>
> Spencer (minor): I'm not sure if this is a cut-and-paste error or if you 
> really meant to say something that got left out, but someone smarter than 
> I am needs to look at the "See The" here.