Subject: [Gen-art] Gen-ART review of draft-freed-sieve-notary-07

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 5 Apr 2010 17:49:55 -0500

Document: draft-freed-sieve-notary-07
Reviewer: Spencer Dawkins
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.

---

From: Ned Freed <[email-masked]>
Date: Mon, 05 Apr 2010 16:18:11 -0700 (PDT)

> am needs to look at the "See The" here.

It's a simple typo - the "See" should just be removed. It will be fixed in the
next revision.

				Ned

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 14 Apr 2010 08:10:46 -0500

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

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 14 Apr 2010 10:01:52 -0700

SD> Summary: This specification is almost ready for publication as a
SD> Proposed Standard. I do have some (late Last Call) questions, almost
SD> all of which are around either 2119 language or clarity.

Thanks for the review Spencer!  I'll look at addressing your comments
today.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 14 Apr 2010 13:24:05 -0700

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
        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).

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 14 Apr 2010 15:57:56 -0500

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

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)

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:

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

Works perfectly for me.

> 9 WONTDO 9.3.  MIB Module Security

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 14 Apr 2010 17:41:47 -0500

Hi, Wes,

All of these work for me - and thanks for the explanations.

Thanks especially for the change to 6 - I was thinking "gotta get my eyes 
checked!" ...

Spencer

> SD> Oh, I agree that you shouldn't delete it, especially since you
> SD> confirmed that it's normative. I was hoping for something a little
> SD> more precise (like, naming a mandatory-to-implement non-NULL
> SD> encryption cipher suite :-) and I'm now wondering why it's not a
> SD> MUST/MUST unless X. But do the right thing ;-).
>
> The idea was to leave algorithm requirements up to the base-protocols.
> SNMP has a long history of not mandating encryption (for reasons that
> are historic and probably no longer valid), and we didn't want to change
> that.  Hence the SHOULD.
>
> Anyway, I'll leave it as is and consider this "closed".  Thanks!
>
> [similarly for the 2119 issue]
>
>> 6 DONE 2) continued:
>> ~~~~~~~~~~~~~~~~~~~~~
> SD> I'm easily confused, but isn't this sentence word-for-word what the
> SD> original text said? :D
>
> Um, whoops.  Wrong copy/paste apparently.  I should have quoted this:
>
>       If the connection is being established from configuration based
>       on SNMP-TARGET-MIB configuration, then the snmpTlstmAddrTable
>       DESCRIPTION clause describes how the verification is done (using
>       either a certificate fingerprint, or an identity authenticated
>       via certification path validation).
>
> Which spells out more clearly "configuration based on" instead of
> "reasons".
>
> SD> If this is clear to those skilled in the art, no problem. I'm just
> SD> telling you I can't parse it!
>
> No, I'm sure it's confusing to anyone without a strong background in how
> the SNMP-TARGET-MIB works in SNMP.  We've tried to make it clean but I'm
> more than certain to someone without knowledge of how the
> SNMP-TARGET-MIB works you'd get quickly lost.
>
> -- 
> Wes Hardaker

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 14 Apr 2010 15:36:52 -0700

>>>>> On Wed, 14 Apr 2010 15:57:56 -0500, "Spencer Dawkins" <[email-masked]> said: