Subject: Re: [Isms] IsmsAD review comments for draft-ietf-isms-dtls-tm-08

From: Wes Hardaker <[email-masked]>
Date: Tue, 02 Mar 2010 17:13:42 -0800

PE> AD review comments for draft-ietf-isms-dtls-tm-08

Pasi,

I've acted on most of your comments and have questions/discussion items
about a few.  I haven't tackled your rewording suggestions for 5.1.1 yet
and will get to those tomorrow.  Please see the notes below about each
item and let me know what you think in particular about the ones marked
"DISCUSS".

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

Table of Contents
=================
1 Somewhat substantial first: 
2 Semi-editorial/editorial: 

1 TODO Somewhat substantial first: 
-----------------------------------

* DONE Unless we have a normative dependency to 
  draft-ietf-tsvwg-dtls-for-sctp (which would delay this document for
  unpredictable time), we need to specify which of the possible ways of
  running DTLS over SCTP we're using in this document. Since this might
  take some time, I would suggest just leaving out DTLS-over-SCTP from
  this document.
  
  + WH: Done.  Originally it looked like that document would
    long beat us, but it apparently hasn't.  (It just entered WG
    last call I see).
  
* DISCUSS Currently, the document specifies how the TLS client authenticates/ 
  authorizes the TLS server only when SNMP-TARGET-MIB is used.  But
  clearly authenticating the TLS server is also important for
  e.g. command generators. These may not have a MIB, but shouldn't we at
  least recommend an implementation-specific management/configuration
  interface that supports configuring the same details as
  tlstmAddrTable?
  
  (E.g. Syslog-over-TLS specifies that the management interface must be
  able to configure this stuff, but that "management interface" could
  be a configuration file, GUI, or even a proprietary MIB.)
  
  + WH: The current draft says (5.3.1 bullet 4):
  
      "The (D)TLS client MUST then verify that the (D)TLS server's
       presented certificate is the expected certificate. [...]
  
       If the connection is being established from configuration
       based on SNMP-TARGET-MIB configuration then the procedures
       in the tlstmAddrTable DESCRIPTION clause should be followed
       to determine if the presented identity matches the
       expectations of the configuration.  Validation procedures
       (like the path validation procedures defined in [RFC5280]
       or through the use of fingerprints as defined by the
       tlstmAddrServerIdentity column) MUST be followed.  If a
       server identity name has been configured in the
       tlstmAddrServerIdentity column then this reference identity
       must be compared against the presented identity (for
       example using procedures described in
       [I-D.saintandre-tls-server-id-check]).
  
       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."
  
    Would adding something like the following to the end of that
    last paragraph meet your goals:
  
       Configuration mechanisms SHOULD be similar in nature to
       those defined in the tlstmAddrTable to ensure consistency
       across management configuration systems.
  
* DONE Overall: The details of exactly how (D)TLS needs to be used are 
  scattered over the document, and in some cases, not very clearly
  written. Probably we should include a "(D)TLS usage" section that
  explains what TLS features/etc. we're using and so on. Here's a first
  sketch, replacing current 4.2:
  
  4.2.  (D)TLS Usage
  
      (D)TLS MUST negotiate a cipher suite that uses X.509 certificates
      for authentication, and MUST authenticate both the client and the
      server. The mandatory-to-implement cipher suite is specified in the
      TLS specification [RFC5246].
  
      TLSTM verifies the certificates when the connection is opened (see
      Section 5.3). For this reason, TLS renegotiation with different
      certificates MUST NOT be done.  That is, implementations MUST
      either disable renegotiation completely (RECOMMENDED), or MUST
      present the same certificate during renegotiation (and MUST verify
      that the other end presented the same certificate).
  
      For DTLS over UDP, each SNMP message MUST be placed in a single UDP
      datagram; it MAY be split to multiple DTLS records. In other words,
      if a single datagram contains multiple DTLS application_data
      records, they are concatenated when received. The TLSTM
      implementation SHOULD return an error if the SNMP message does not
      fit in the UDP datagram, and thus cannot be sent.
  
      For DTLS over UDP, the DTLS server implementation MUST support DTLS
      cookies ([RFC4347] already requires that clients support DTLS
      cookies).  Implementations are not required to perform the cookie
      exchange for every DTLS handshake; however, enabling it by default
      is RECOMMENDED.
  
      For DTLS, replay protection MUST be used.
  
  + WH: I'm fine with that wording, with one minor change.  The
    working group has waffled back and forth generally on how much
    "(D)TLS" specific protocol information should be referenced
    and thus I could see people objecting to the wording like
    "... multiple DTLS application_data records ..." because we
    expressly removed wording like that before that talked about
    DTLS internals.  I'll leave it up to others to complain if
    your next text strikes a nerve with them.
  
* DISCUSS Section 3.1.3. "As an implementation hint: although the 
  tlstmSessionID may be the same as the (D)TLS internal SessionID
  caution must be exercised since the (D)TLS internal SessionID may
  change over the life of the connection as seen by the TLSTM (for
  example during renegotiation).  The tlstmSessionID identifier MUST NOT
  change during the entire duration of the session from the TLSTM's
  perspective even if the TLS internal session identifier does change."
  
  This is not correct; it's possible to have several (D)TLS connections
  (over different TCP connections, or different UDP five-tuples) that
  have the same (D)TLS internal Session ID, so it does not uniquely
  identify a TLSTM session. I would suggest just deleting this
  paragraph.
  
  + WH: I think you're missing the point of the paragraph.  It's
    stating that the SNMP-specific tlstmSessionID MUST NOT and
    MUST be consistent.  No where does the paragraph state that
    the TLS session IDs uniquely identify a session.  It only
    states that if you use it you need to be careful and I think
    this is an important point.  I'd be happy to add an additional
    sentence describing that a single TLS sessionID may be shared
    among connections, but using a shared sessionID within TLSTM
    is prohibited.
  
* TODO Largely for the same reason, Section 5.1.1 is not quite 
  correct; here's an attempt to rephrase it:
  
  + WH: I need to think/work more heavily on this one; I'll get
    back to you about it in another day or so.  There is a
    balance to be struck between the agonizing detail that SNMP
    EOPs go into sometimes vs what should be described for DTLS
    processing.
  
  5.1.1.  DTLS over UDP Processing for Incoming Messages
  
     For connection-oriented transport protocols, such as TCP, the
     transport protocol takes care of demultiplexing incoming packets to
     the right connection. Depending on the DTLS implementation, for
     DTLS over UDP, this demultiplexing may need to be done by the TLSTM
     implementation.
  
     Like TCP, DTLS over UDP uses the four-tuple <source IP, destination
     IP, source port, destination port> for identifying the connection
     (and relevant DTLS connection state). This means that when
     establishing a new session, implementations MUST use a different
     UDP source port number for each active connection to a remote
     destination IP-address/port-number combination to ensure the remote
     entity can disambiguate between multiple connections.
  
     If demultiplexing received UDP datagrams to DTLS connection state
     is done by the TLSTM implementation (instead of the DTLS
     implementation), the steps below describe one possible method to
     accomplish this.
  
     1)  The TLS Transport Model examines the UDP datagram, in an
         implementation-dependent manner.
  
     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.
  
         If a matching entry in the LCD does not exist, create a new
         entry containing the transport parameters; a new DTLS
         connection handle (an implementation-dependent detail), and a
         new tlsTmSessionId.
  
     3)  Pass the UDP packet and DTLS connection handle to DTLS (in
         implementation-dependent manner). If processing does not return
         an incomingMessage and an incomingMessageLength then processing
         stops (this is the case when the UDP datagram contained DTLS
         handshake messages, for example).
  
     4)  Retrieve the incomingMessage and an incomingMessageLength from
         DTLS.  These results and the tlstmSessionID are used below in
         Section 5.1.2 to complete the processing of the incoming message.
  
* DONE Section 7, tlstmCertSANDNSName: I thought we agreed in IETF76 that 
  this should be lowercased?
  
  + WH: Good catch; thanks.  I think when the text split into OIDs
    the revision specifying the lower-casing got lost.  Re-added
    as follows:
  
    DESCRIPTION  "Maps a subjectAltName's dNSName to a 
                  tmSecurityName after first converting it to all
                  lower case."
  
* DONE Section 7, tlstmCertSANIpAddress: I thought we agreed in IETF76 that 
  IPv6 addresses need to be in lowercase?
  
  + WH: Good catch; thanks.  I think when the text split into OIDs
    the revision specifying the lower-casing got lost.  Re-added
    as follows:
  
              2) for IPv6 addresses the value is converted into a
                 32-character all lowercase hexadecimal string
                 without any colon separators.
  
* DONE Section 7, tlstmCertCommonName: "[..] by directly passing the value 
  without any transformations" -> "[..]. The value is converted to UTF-8
  encoding, but no other transformation are done."
  
  + WH: new text:
  
    DESCRIPTION  "Maps a certificate's CommonName to a tmSecurityName
                  after converting it to a UTF-8 encoding."

* DISCUSS Section 7, tlstmParamsClientFingerprint: we should probably allow an 
  empty value to accommodate the common case where the client has just
  one certificate/private key?
  
  + WH: I think it would be better to allow a non-existing row to
    indicate use the default client certificate.  This probably
    isn't clearly spelled out in 5.3.1 step 2, which reads:
  
       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.
  
    How's this  for a suggested addition as a last sentence:
  
       If no row in the tlstmParamsTable exists then
       implementations MAY choose to establish the connection
       using a default client certificate available to the
       application.
  
* DONE Section 7, tlstmAddrTable DESCRIPTION is a bit vague on some of the 
  details, and in its present form, would need a normative reference to
  draft-saintandre-tls-server-id-check (which we might want to avoid so
  this document is not delayed). Suggested rephrasing:
  
     "This table is used by a (D)TLS client when a (D)TLS connection is
     being set up using an entry in the SNMP-TARGET-MIB.  It extends the
     SNMP-TARGET-MIB's snmpTargetAddrTable so that the client can verify
     that the correct server has been reached.
  
     This verification can use either a certificate fingerprint, or an
     identity authenticated via certification path validation.
  
     If there is a row in this table corresponding to the entry in the
     SNMP-TARGET-MIB that was used to establish the session (and that
     row is active), and the row's tlstmAddrServerFingerprint column has
     non-empty value, the server's presented certificate is compared
     with the fingerprint (and the tlstmAddrServerIdentity column is
     ignored). If the fingerprint matches, the verification has
     succeeded.
  
     If the server's presented certificate has passed certification path
     validation [RFC5280] to a configured trust anchor, and a row exists
     with a zero-length tlstmAddrServerFingerprint value, then the
     tlstmAddrServerIdentity column contains the expected host name.
     This expected host name is then compared against the server's
     certicate as follows:
  
     - Implementations MUST support matching the expected host name
     against a dNSName in the subjectAltName extension field and SHOULD
     support checking the name against the common name portion of the
     subject distinguished name.
  
     - The '*' (ASCII 42) wildcard character is allowed in the dNSName
     of the subjectAltName extension (and in common name, if used to
     store the host name), but only as the left-most (least significant)
     DNS label in that value.  This wildcard matches any left-most DNS
     label in the server name.  That is, the subject *.example.com
     matches the server names a.example.com and b.example.com, but does
     not match example.com or a.b.example.com.  Implementations MUST
     support wildcards in certificates as specified above, but MAY
     provide a configuration option to disable them.
  
     - If the locally configured name is an internationalized domain
     name, conforming implementations MUST convert it to the ASCII
     Compatible Encoding (ACE) format for performing comparisons, as
     specified in Section 7 of [RFC5280].
  
     If none of the rows in this table match, then the connection MUST
     be closed (except if the server can be authorized by other,
     implementation-dependent means)."

  + WH:
    - I like the copying of the text from the other draft.
    - The proposed text has been adopted with some rewording and
      now reads as follows:
  
        DESCRIPTION
    "This table is used by a (D)TLS client when a (D)TLS
      connection is being set up using an entry in the
      SNMP-TARGET-MIB.  It extends the SNMP-TARGET-MIB's
      snmpTargetAddrTable so that the client can verify that the
      correct server has been reached. This verification can use
      either a certificate fingerprint, or an identity
      authenticated via certification path validation.
  
      If there is an active row in this table corresponding to the
      entry in the SNMP-TARGET-MIB that was used to establish the
      connection, and the row's tlstmAddrServerFingerprint column
      has non-empty value, then the server's presented certificate
      is compared with the tlstmAddrServerFingerprint value (and
      the tlstmAddrServerIdentity column is ignored). If the
      fingerprint matches, the verification has succeeded. If the
      fingerprint does not match then the connection MUST be
      closed.
  
      If the server's presented certificate has passed
      certification path validation [RFC5280] to a configured
      trust anchor, and an active row exists with a zero-length
      tlstmAddrServerFingerprint value, then the
      tlstmAddrServerIdentity column contains the expected host
      name.  This expected host name is then compared against the
      server's certificate as follows:
  
        - Implementations MUST support matching the expected host
        name against a dNSName in the subjectAltName extension field
        and SHOULD support checking the name against the common name
        portion of the subject distinguished name.
  
        - The '*' (ASCII 0x2a) wildcard character is allowed in the
        dNSName of the subjectAltName extension (and in common name,
        if used to store the host name), but only as the left-most
        (least significant) DNS label in that value.  This wildcard
        matches any left-most DNS label in the server name.  That
        is, the subject *.example.com matches the server names
        a.example.com and b.example.com, but does not match
        example.com or a.b.example.com.  Implementations MUST
        support wildcards in certificates as specified above, but
        MAY provide a configuration option to disable them.
        
        - If the locally configured name is an internationalized
        domain name, conforming implementations MUST convert it to
        the ASCII Compatible Encoding (ACE) format for performing
        comparisons, as specified in Section 7 of [RFC5280].
        
      If the expected host name fails these conditions then the
      connection MUST be closed.
  
      A row MUST NOT contain both a blank
      tlstmAddrServerFingerprint column and a '*' in the
      tlstmAddrServerIdentity column since this would insecurely
      accept any presented certificate.
        
      If there is no row in this table corresponding to the entry
      in the SNMP-TARGET-MIB and the server can be authorized by
      another, implementation dependent means, then the connection
      MAY still proceed."
  
* DONE Section 7, "tlstmAddrServerIdentity", remove the last sentence 
  (about wildcards) and REFERENCE, and change DEFVAL to "" (the wildcard
  cannot be used by the procedure as currently described, since the
  identity column is looke at only if fingerprint is zero-length, and if
  the fingerprint is zero-length, wildcard is not allowed...)
  
* DONE Section 5.3.1, step 4, rephrase 2nd paragraph as: 
  
  If the connection is being established from configuration based on
  SNMP-TARGET-MIB configuration, then the tlstmAddrTable DESCRIPTION
  clause describes how the verification is done (using either a
  certificate fingerprint, or an identity authenticated via
  certification path validation).
  
* DONE Section 10, rephrase items 1..6 as: 
  
  1. Two TCP/UDP/SCTP port numbers from the "Registered Ports" range
  of the Port Numbers registry, with keywords "snmptls" and
  "snmptls-trap".  These are the default ports for receipt of SNMP
  command messages (snmptls) and SNMP notification messages
  (snmptls-trap) over a TLS Transport Model as defined in this
  document.
  
  And delete both paragraphs starting with "If possible, ..." later
  in this section (if we ask for the same port, we will get it).
  
  + WH: Ok, done.  But you removed the guidance about the port
    number being > 1023 which was a WG decision to accept
    something higher than 1023 as acceptable.  Shouldn't we
    include such a note as part of the guidance?
  
* DONE C.1. I think we need an example here. Here's a first attempt 
  (based on RFC 5591, Appendix A):
  
  For notification originators performing authorization checks, the
  server's certificate must be verified against the expected
  certificate before proceeding to send the notification.  This is
  done by configuring the tlstmAddrTable accordingly. For example,
  if the verification is done via certification path validation
  (to a trust anchor configured in implementation dependent manner),
  the entries could look like:
  
         snmpTargetAddrTable row:
            snmpTargetAddrName              toCRAddr
        *   snmpTargetAddrTDomain           snmpTLSTCPDomain
        *   snmpTargetAddrTAddress          192.0.2.1:5162
            snmpTargetAddrTimeout           1500
            snmpTargetAddrRetryCount        3
            snmpTargetAddrTagList           toCRTag
            snmpTargetAddrParams            toCR   (MUST match below)
            snmpTargetAddrStorageType       nonVolatile
            snmpTargetAddrColumnStatus      createAndGo
  
        snmpTargetParamsTable row:
            snmpTargetParamsName            toCR
            snmpTargetParamsMPModel         SNMPv3
        *   snmpTargetParamsSecurityModel   TransportSecurityModel
            snmpTargetParamsSecurityName    "blueberry"
            snmpTargetParamsSecurityLevel   authPriv
            snmpTargetParamsStorageType     nonVolatile
            snmpTargetParamsRowStatus       createAndGo
  
         snmpTargetAddrTable row:
            snmpTargetAddrName              toCRAddr
        *   snmpTargetAddrTDomain           snmpTLSTCPDomain
        *   snmpTargetAddrTAddress          192.0.2.1:5162
            snmpTargetAddrTimeout           1500
            snmpTargetAddrRetryCount        3
            snmpTargetAddrTagList           toCRTag
            snmpTargetAddrParams            toCR   (MUST match above)
            snmpTargetAddrStorageType       nonVolatile
            snmpTargetAddrColumnStatus      createAndGo
  
         tlstmAddrTable row:
            snmpTargetAddrName              toCRAddr
            tlstmAddrServerFingerprint      ""
            tlstmAddrServerIdentity         "server.example.org"
            tlstmAddrStorageType            nonVolatile
            tlstmAddrRowStatus              createAndGo
  
          + WH: I've added similar text to the above.  The above has some
            issues with it so I've adapted it to the following:
  
  To configure a notification originator to open a TLS over TCP
  connection to a notification receiver it must be configured
  so the server's presented certificate can be verified against
  the expected certificate before proceeding to send the
  notification.  This is done by configuring the tlstmAddrTable
  accordingly.  For example, if the verification is done via
  certification path validation (to a trust anchor configured
  in implementation dependent manner), then the table entries
  could look like:
  
            snmpTargetAddrTable row:
   snmpTargetAddrName            = "toNRAddr"
   snmpTargetAddrTDomain         = snmpTLSTCPDomain
   snmpTargetAddrTAddress        = "192.0.2.1:XXXTLSTCPTRAPPORT"
   snmpTargetAddrTimeout         = 1500
   snmpTargetAddrRetryCount      = 3
   snmpTargetAddrTagList         = "toNRTag"
   snmpTargetAddrParams          = "toNR"     (MUST match below)
   snmpTargetAddrStorageType     = 3          (nonVolatile)
   snmpTargetAddrColumnStatus    = 4          (createAndGo)
                                    
            snmpTargetParamsTable row:         
   snmpTargetParamsName          = toNR
   snmpTargetParamsMPModel       = SNMPv3
   snmpTargetParamsSecurityModel = 4          (TransportSecurityModel)
   snmpTargetParamsSecurityName  = "blueberry"
   snmpTargetParamsSecurityLevel = 3          (authPriv)
   snmpTargetParamsStorageType   = 3          (nonVolatile)
   snmpTargetParamsRowStatus     = 4          (createAndGo0
  
            tlstmAddrTable row:
    snmpTargetAddrName           =  "toNRAddr"
    tlstmAddrServerFingerprint   =  ""
    tlstmAddrServerIdentity      =  "server.example.org"
    tlstmAddrStorageType         =  3         (nonVolatile)
    tlstmAddrRowStatus           =  4         (createAndGo)
  
   Editor's note: replace the string "XXXTLSTCPTRAPPORT" above with the
   appropriately assigned "snmptls-trap" port.
  
   Editor's note: replace the string "TSMNUM" above with the
   appropriately assigned "snmptls-trap" port.

2 TODO Semi-editorial/editorial: 
---------------------------------

* DONE Section 1, "While (D)TLS supports multiple authentication 
  mechanisms, this document only discusses X.509 certificate based
  authentication.  Although other forms of authentication are possible
  they are outside the scope of this specification." sounds a bit
  cumbersomet. Perhaps "While [..], this document [..]; other forms of
  authentication are outside the scope of this specification" would
  be more fluent?
  
* DONE Section 1: "connectionless (e.g.  UDP or SCTP) transport": 
  SCTP is connection-oriented, not connectionless.
  
* DONE Section 1: We shouldn't have a figure longer than one page. 
  Here's an attempt to clean the figure slightly so it fits on
  one page:
  
  [...]
  
  + WH: I've replaced the diagram with yours.  Thanks for the
    work; I've never been happy with that diagram.
  
* DONE Section 1.1 says 'The terms "manager" and "agent" are not used in 
  this document'; however, the rest of the document occasionally uses
  the word 'manager' to refer to the person who's configuring
  stuff. Should these be changed to 'administrator'?
  
  + Good catch: changed;
  
* DONE Section 1.1: "this document (unless otherwise specified) 
  is referring to TLSTM's specific session and not directly to
  the (D)TLS protocol's session".  Actually, even when this
  document *does* specify otherwise and explicitly says "(D)TLS
  session", it's still usually talking about D(TLS) connections,
  not sessions. Proposed rephrasing here:
  
     "The (D)TLS protocols also have an internal notion of a session and
     although these two concepts of a session are related, this document
     is referring to the TLSTM's specific session and not directly to
     the (D)TLS protocol's session."
  
  + WH: put in place with slight changes:
  
     The (D)TLS protocols also have an internal notion of a
     session and although these two concepts of a session are
     related, when the term "session" is used this document is
     referring to the TLSTM's specific session and not directly
     to the (D)TLS protocol's session.
  
* DONE Section 3: "to close a (D)TLS session" -> "to close the session" 
  (this is *not* about (D)TLS sessions, but TLSTM sessions)
  
  + WH: good point;
  
* DONE Section 3.1.1, item 2: "The TLS Transport Model MUST support 
  authentication of both the server and the client." This sentence is
  very confusing; it seems to be targeted at the writer of this
  specification, not implementor. I would just suggest deleting this
  sentence.
  
  + WH: Changed to:
  
    A TLS Transport Model implementation MUST support
    authentication of both the server and the client.
  
* DONE Section 3.1.1, item 4: "The TLS Transport Model SHOULD support the 
  message encryption to protect sensitive data from eavesdropping
  attacks." This sentence is very confusing; it seems to be targeted at
  the writer of this specification, not implementor. Or if it's targeted
  at the implementor, is it trying to say that "implementations SHOULD
  support at least one cipher suite that does encryption?" (that's not
  needed; the mandatory-to-implement cipher suite in TLS RFCs is quite
  enough) I would just suggest deleting this sentence.
  
  + WH: I think keeping the notion that supporting encryption is
    important is, um, important.  Changed to:
  
    A TLS Transport Model implementation SHOULD support the
    message encryption to protect sensitive data from
    eavesdropping attacks.
  
    It at least indicates that the implementation should support
    "configuration" of encryption enabled cipher suites.  (there
    is sort of an odd case where an implementation could
    implement the cipher suite, but refuse to actually use it ;-)
  
* DONE Section 3.1.1, item 5: replace all three paragraphs with 
  
  5.  Denial of Service - the RFC 3411 architecture [RFC3411] states
  that denial of service (DoS) attacks need not be addressed by an
  SNMP security protocol.  However, connectionless transports (like
  DTLS over UDP are susceptible to a variety of denial of service
  attacks because they are more vulnerable to spoofed IP
  addresses. See Section 4.2 for details how the cookie mechanism is
  used. This mechanism, though, does not provide any defense against
  denial of service attacks mounted from valid IP addresses.
  
          + WH: Applied after fixing the closing ) problem in the above
            text and rewording the last sentence just a touch.
  
* DONE Section 3.1.2: "(D)TLS session provides" -> "(D)TLS connection 
  provides"
  
* DONE Section 3.1.3: "D(TLS) Sessions" -> "D(TLS) Connections" 
  
  + WH: applied with the proper () grouping.
  
* DONE Section 3.3, "(D)TLS sessions may be initiated" -> "(D)TLS 
  connections may be initiated
  
* DONE Section 3.3, "locally held certificate" -> "locally held certificate 
  (and the corresponding private key)"
  
* DONE Section 4.1.1, OLD 
  Authentication using (D)TLS will require that SNMP entities are
  provisioned with certificates, which are signed by trusted
  certificate authorities (possibly the certificate itself).
            NEW:
  Authentication using (D)TLS will require that SNMP entities have
  certificates, either signed by trusted certification authorities,
  or self-signed.
  
* DONE Section 4.1.1, "tmpSecurityName" -> "tmSecurityName" 
  
  + WH: yikes!  Thanks!
  
* DONE Section 4.3.1 and 4.3.2: SnmpTLSDomain -> SnmpTLSTCPDomain 
  
  + WH: changed; thanks (lower case s though)
  
* WONTDO Section 4.4.1.1, "Transport Models SHOULD generate a predictable 
  tmSecurityName so operators will know what to use when configuring MIB
  modules that use securityNames derived from tmSecurityNames."
  Setting requirements for all transport models (not just DTLSTM)
  doesn't seem to belong to this document...
  
  + that's boilerplate-ish text directly from 5592 which we're
    copying verbatim.
  
* DONE Section 4.4.1.1, "through an existing (D)TLS session" -> "through an 
  existing (D)TLS connection"
  
* DONE Section 4.4.1.2, "D(TLS) session" -> "D(TLS) connection" (both 
  instances)
  
  + WH: with proper ()s
  
* DONE Section 5.1, "for all (D)TLS-based sessions" -> " for 
  all(D)TLS-based connections"
  
* DONE Section 5.1: "TLS and DTLS/SCP" -> "TLS/TCP and DTLS/SCTP" 
  
* DONE Section 5.1: "5.1.2describes" -> "5.1.2 describes" 
  
* DONE Section 5.1.2, "lifetime of the (D)TLS session" -> "lifetime of session" 
  
* DONE Section 5.3 and 5.3.1 and 5.3.2, "(D)TLS session" -> "(D)TLS connection" 
  (all instances)
  
* DONE Section 5.4, "Have (D)TLS close the specified session" -> 
  "Have (D)TLS close the specified connection"
  
* DONE Section 6.3, "(D)TLS session usage" -> "session usage" 
  
* DONE Section 7, snmpTlstmSessionAccepts DESCRIPTION: TODO 
  
  + WH: It looks like you wanted to reword this and forgot to
    get back to it.  Given your other comments I've predicted
    your issues and have changed the wording to this:
  
    "The number of times a (D)TLS server has accepted a new
    connection from a client and has received at least one SNMP
    message through it."

* DONE Section 7, tlstmParamsTable and tlstmAddrTable: "(D)TLS session" -> 
  "(D)TLS connection"
  
* DONE Section 7, tlstmParamsClientFingerprint: "locally held X.509 
  certificate" -> "locally held X.509 certificate (and the corresponding
  private key)".
  
* DONE Section 8.1, " A session is discussed throughout this document as 
  meaning a security association between the (D)TLS client and the
  (D)TLS server."  -> "A session is discussed throughout this document
  as meaning a security association between two TLSTM instances."
  
* DONE Section 9: OLD 
  DTLS adds to the security considerations of TLS only because it
  is more vulnerable to denial of service attacks.  A random cookie
  exchange was added to the handshake to prevent anonymous denial
  of service attacks.  RFC 4347 recommends that the cookie exchange
  is utilized for all handshakes.  It is also RECOMMENDED by this
  specification that users enable this cookie exchange.
            NEW:
  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.
  
* DISCUSS Appendix A and B: Please just delete these -- the details aren't 
  quite right (e.g. DTLS sessions...), and fixing them is not worth the
  effort needed.
  
  + WH: The WG discussed these sections in Stockholm (I think)
    and the consensus was to leave them as they were useful to
    "newbies" and it would be better to move them to an appendix
    than to delete them.  I've never been really happy with the
    text (and in fact didn't even write it), but I want to make
    sure you're explicitly trumping WG consensus with your AD
    badge before I delete them.
  
* DONE C.1, would suggest adding "In case the notification originator has 
  multiple certificates, ..." to the beginning of the 2nd para.
  
  + WH: I don't think that's quite the right text either.  I'm
    now adding this to the end:
  
    (Or else a default certificate may be used if available.)
  
* DONE C.2, "(D)TLS session" -> "D(TLS) connection" 
  
* WONTDO C.2: suggest replacing "HASH" with an example hash. If I understand 
  the Fingerprint DISPLAY-HINT correctly, that might be something like
  "02:68b9389e49a815aa4a79f40fcfce7eb8cd10669c"
  
  + WH: Though I understand the desire to do that, I don't think
    it's worth making one up nor is it worth trying to make it
    fit within the page width (it'd need to be wrapped multiple
    times).
  
* DONE C.2: OLD 
  tlstmCertToTSNMapType      = 1      (specified)
  tlstmCertToTSNSecurityName = "blueberry"
            NEW:
  tlstmCertToTSNMapType      = tlstmCertSpecified
  tlstmCertToTSNData         = "blueberry"
  
          + WH: Good catch.
  
* DONE C.2: OLD 
  tlstmCertToTSNMapType     = 2       (bySubjectAltName)
  tlstmCertToTSNSANType     = 1       (any)
            NEW:
  tlstmCertToTSNMapType     = tlstmCertSANAny
  tlstmCertToTSNData        = ""      (not used)
  
          + WH: good catch.
  
* DONE Overall: "certificate authority" -> "certification authority" 

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "tom.petch" <[email-masked]>
Date: Thu, 4 Mar 2010 15:49:49 +0100

Pasi

Two thoughts on your proposal to discourage renegotiation.

SNMP may have long running sessions - I know, there is no concept of session in
SNMP but allow me a little licence - so that it may trip over limitations on the
usage of the security credentials in a way that other applications do not.

A certificate could expire and so need to be replaced with a current one, which
is one use of renegotiation.  And so much data could flow, or time pass, that
the keys need refreshing, which again renegotiation allows.

Do you intend that these be NOT RECOMMENDED ie if and when such are needed, tear
down the TLSTM session and start again?

Second, you change all the TLS session to TLS connection, which is a substantial
change.  I had assumed that the author had intended session resumption to be
permitted which your new text would discourage.  Again, is this your intention?

Tom Petch

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Sent: Thursday, February 25, 2010 2:23 PM
Subject: [Isms] AD review comments for draft-ietf-isms-dtls-tm-08

> AD review comments for draft-ietf-isms-dtls-tm-08
>
> I've now done my AD review for draft-ietf-isms-dtls-tm-08, and bunch
> of comments. Most of them are quite small, and I've tried to suggest
> possible text in most cases (but this is just to clarify what I'm
> looking for; I'm not hung up on the exact wording):
>
> Somewhat substantial first:
>
> - Unless we have a normative dependency to
> - Currently, the document specifies how the TLS client authenticates/
> - Overall: The details of exactly how (D)TLS needs to be used are
> - Section 3.1.3. "As an implementation hint: although the
> Largely for the same reason, Section 5.1.1 is not quite correct;
> here's an attempt to rephrase it:
>
> - Section 7, tlstmCertSANDNSName: I thought we agreed in IETF76 that
> - Section 7, tlstmCertSANIpAddress: I thought we agreed in IETF76 that
> - Section 7, tlstmCertCommonName: "[..] by directly passing the value
> - Section 7, tlstmParamsClientFingerprint: we should probably allow an
> - Section 7, tlstmAddrTable DESCRIPTION is a bit vague on some of the
> - Section 7, "tlstmAddrServerIdentity", remove the last sentence
> - Section 5.3.1, step 4, rephrase 2nd paragraph as:
>
> - Section 10, rephrase items 1..6 as:
>
> - C.1. I think we need an example here. Here's a first attempt
> Semi-editorial/editorial:
>
> - Section 1, "While (D)TLS supports multiple authentication
> - Section 1: "connectionless (e.g.  UDP or SCTP) transport":
> - Section 1: We shouldn't have a figure longer than one page.
>  +---------------------------------------------------------------------+
>  |                              Network                                |
>  +---------------------------------------------------------------------+
>      ^                     |            ^               |
>      |Notifications        |Commands    |Commands       |Notifications
>  +---|---------------------|-------+ +--|---------------|--------------+
>  |   |                     V       | |  |               V              |
>  | +------------+  +------------+  | | +-----------+   +----------+    |
>  | |  (D)TLS    |  |  (D)TLS    |  | | | (D)TLS    |   | (D)TLS   |    |
>  | |  (Client)  |  |  (Server)  |  | | | (Client)  |   | (Server) |    |
>  | +------------+  +------------+  | | +-----------+   +----------+    |
>  |       ^             ^           | |       ^              ^          |
>  |       |             |           | |       |              |          |
>  |       +-------------+           | |       +--------------+          |
>  | +-----|------------+            | | +-----|------------+            |
>  | |     V            |            | | |     V            |            |
>  | | +--------+       |   +-----+  | | | +--------+       |   +-----+  |
>  | | | TLS TM |<--------->|Cache|  | | | | TLS TM |<--------->|Cache|  |
>  | | +--------+       |   +-----+  | | | +--------+       |   +-----+  |
>  | |Transport Subsys. |      ^     | | |Transport Subsys. |      ^     |
>  | +------------------+      |     | | +------------------+      |     |
>  |    ^                      |     | |    ^                      |     |
>  |    |                      +--+  | |    |                      +--+  |
>  |    v                         |  | |    V                         |  |
>  | +-----+ +--------+ +-------+ |  | | +-----+ +--------+ +-------+ |  |
>  | |     | |Message | |Securi.| |  | | |     | |Message | |Securi.| |  |
>  | |Disp.| |Proc.   | |Subsys.| |  | | |Disp.| |Proc.   | |Subsys.| |  |
>  | |     | |Subsys. | |       | |  | | |     | |Subsys. | |       | |  |
>  | |     | |        | |       | |  | | |     | |        | |       | |  |
>  | |     | | +----+ | | +---+ | |  | | |     | | +----+ | | +---+ | |  |
>  | |    <--->|v3MP|<--> |TSM|<--+  | | |    <--->|v3MP|<--->|TSM|<--+  |
>  | |     | | +----+ | | +---+ |    | | |     | | +----+ | | +---+ |    |
>  | |     | |        | |       |    | | |     | |        | |       |    |
>  | +-----+ +--------+ +-------+    | | +-----+ +--------+ +-------+    |
>  |    ^                            | |    ^                            |
>  |    |                            | |    |                            |
>  |    +-+------------+             | |    +-+----------+               |
>  |      |            |             | |      |          |               |
>  |      v            v             | |      v          V               |
>  | +-------------+ +-------------+ | | +-------------+ +-------------+ |
>  | |   COMMAND   | | NOTIFICAT.  | | | |  COMMAND    | | NOTIFICAT.  | |
>  | |  RESPONDER  | | ORIGINATOR  | | | | GENERATOR   | | RECEIVER    | |
>  | | application | | application | | | | application | | application | |
>  | +-------------+ +-------------+ | | +-------------+ +-------------+ |
>  |                     SNMP entity | |                     SNMP entity |
>  +---------------------------------+ +---------------------------------+
>
> - Section 1.1 says 'The terms "manager" and "agent" are not used in
> - Section 1.1: "this document (unless otherwise specified) is referring
> to TLSTM's specific session and not directly to the (D)TLS protocol's
> session".  Actually, even when this document *does* specify otherwise
> and explicitly says "(D)TLS session", it's still usually talking
> about D(TLS) connections, not sessions. Proposed rephrasing here:
>
> - Section 3: "to close a (D)TLS session" -> "to close the session"
> - Section 3.1.1, item 2: "The TLS Transport Model MUST support
> - Section 3.1.1, item 4: "The TLS Transport Model SHOULD support the
> - Section 3.1.1, item 5: replace all three paragraphs with
>
> - Section 3.1.2: "(D)TLS session provides" -> "(D)TLS connection
> provides"
>
> - Section 3.1.3: "D(TLS) Sessions" -> "D(TLS) Connections"
>
> - Section 3.3, "(D)TLS sessions may be initiated" -> "(D)TLS
> - Section 3.3, "locally held certificate" -> "locally held certificate
> - Section 4.1.1, OLD
> - Section 4.1.1, "tmpSecurityName" -> "tmSecurityName"
>
> - Section 4.3.1 and 4.3.2: SnmpTLSDomain -> SnmpTLSTCPDomain
>
> - Section 4.4.1.1, "Transport Models SHOULD generate a predictable
> - Section 4.4.1.1, "through an existing (D)TLS session" -> "through an
> - Section 4.4.1.2, "D(TLS) session" -> "D(TLS) connection" (both
> instances)
>
> - Section 5.1, "for all (D)TLS-based sessions" -> " for
> - Section 5.1: "TLS and DTLS/SCP" -> "TLS/TCP and DTLS/SCTP"
>
> - Section 5.1: "5.1.2describes" -> "5.1.2 describes"
>
> - Section 5.1.2, "lifetime of the (D)TLS session" -> "lifetime of session"
>
> - Section 5.3 and 5.3.1 and 5.3.2, "(D)TLS session" -> "(D)TLS connection"
> (all instances)
>
> - Section 5.4, "Have (D)TLS close the specified session" ->
> - Section 6.3, "(D)TLS session usage" -> "session usage"
>
> - Section 7, snmpTlstmSessionAccepts DESCRIPTION: TODO
>
> - Section 7, tlstmParamsTable and tlstmAddrTable: "(D)TLS session" ->
> "(D)TLS connection"
>
> - Section 7, tlstmParamsClientFingerprint: "locally held X.509
> - Section 8.1, " A session is discussed throughout this document as
> - Section 9: OLD
> - Appendix A and B: Please just delete these -- the details aren't
> - C.1, would suggest adding "In case the notification originator has
> - C.2, "(D)TLS session" -> "D(TLS) connection"
>
> - C.2: suggest replacing "HASH" with an example hash. If I understand
> - C.2: OLD
> - C.2: OLD
> - Overall: "certificate authority" -> "certification authority"
>
> Best regards,
> Pasi
> _______________________________________________
> Isms mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isms

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Mar 2010 09:16:12 +0100

> item and let me know what you think in particular about the ones marked

Wes,

thanks for your followup on Pasi's extensive review - and of course
thanks to Pasi for his detailed review in the first place. Pasi, do
you think we will be able to work through the DISCUSS items so that we
can have an updated ID in place before the cutoff??

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 5 Mar 2010 09:24:56 +0100

> permitted which your new text would discourage.  Again, is this your intention?

Speaking as technical contributor: I don't think it is the idea is to
make session resumption impossible or to disable rekeying. In fact, I
consider session resumption essential. There are many management tools
out there that do not maintain long sessions (in particular large
collections of scripts) and such scripts will be hit really badly if
every call to way snmpwalk kicked off via cron causes an expensive
session key calculation.

The lack of a session resumption mechanism in SSH makes in my view the
SSHTM much less attractive compared to the TLSTM and led us to invent
a session resumption mechanism for SSH [1].

/js

[1] <http://dx.doi.org/10.1109/INM.2009.5188805>

---

From: <[email-masked]>
Date: Fri, 5 Mar 2010 11:56:30 +0100

Hi Wes,

>        across management configuration systems.

Yep, this is roughly what I was thinking about. Perhaps we could also
add a sentence giving an example what the "reasons other than
configuration found in the SNMP-TARGET-MIB" and "configuration
mechanisms" might be?

   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.

>       server. The mandatory-to-implement cipher suite is specified in
>       the TLS specification [RFC5246].
>
>       TLSTM verifies the certificates when the connection is opened
>       (see Section 5.3). For this reason, TLS renegotiation with
>       different certificates MUST NOT be done.  That is,
>       implementations MUST either disable renegotiation completely
>       (RECOMMENDED), or MUST present the same certificate during
>       renegotiation (and MUST verify that the other end presented
>       the same certificate).
>
>       For DTLS over UDP, each SNMP message MUST be placed in a
>       single UDP datagram; it MAY be split to multiple DTLS
>       records. In other words, if a single datagram contains
>       multiple DTLS application_data records, they are concatenated
>       when received. The TLSTM implementation SHOULD return an error
>       if the SNMP message does not fit in the UDP datagram, and thus
>       cannot be sent.
>
>       For DTLS over UDP, the DTLS server implementation MUST support
>       DTLS cookies ([RFC4347] already requires that clients support
>       DTLS cookies).  Implementations are not required to perform
>       the cookie exchange for every DTLS handshake; however,
>       enabling it by default is RECOMMENDED.
>

I think the "multiple DTLS application_data records..." is a detail we
need to specify one way or another (the DTLS spec isn't very clear
about this, but at least in theory it would be possible to use DTLS so
that multiple application_data records are *not* concatenated, and
instead treated as separate SNMP messages...)

>     among connections, but using a shared sessionID within TLSTM

Well, I think the "although the tlstmSessionID may be the same.."  part
is very misleading; this is NOT an approach an implementation can use.
Perhaps something like this?

   The tlstmSessionID identifier MUST NOT change during the entire
   duration of the session from the TLSTM's perspective, and MUST
   uniquely identify a single session.  As an implementation hint:
   note that the (D)TLS internal SessionID does not meet these
   requirements, since it can change over the life of the connection
   as seen by the TLSTM (for example, during renegotiation), and does
   not necessarily uniquely idenfify a TLSTM session (there can be
   multiple TLSTM sessions sharing the same D(TLS) internal
   SessionID).

<snip>
> * DISCUSS Section 7, tlstmParamsClientFingerprint: we should
> probably allow an empty value to accommodate the common case where
> the client has just one certificate/private key?
>

Works for me.

> * DONE Section 7, tlstmAddrTable DESCRIPTION is a bit vague on some
> of the details, and in its present form, would need a normative
> reference to draft-saintandre-tls-server-id-check (which we might
> want to avoid so this document is not delayed). Suggested
> rephrasing:

>      "This table is used by a (D)TLS client when a (D)TLS connection is
       <snip>
>       accept any presented certificate.

The text earlier allows wildcards in the certificate, but not in
tlstmAddrServerIdentity, so this paragraph doesn't make sense.

If we wish to allow wildcards also in tlstmAddrServerIdentity, more
complex text is needed. RFC 5425, Section 5.2 does have such text,
but it leaves the syntax for those wildcards open (they might
be regexps or something).

>       another, implementation dependent means, then the connection

<snip>
>     include such a note as part of the guidance?

The "Registered Ports" range means 1024...49151.

>   (based on RFC 5591, Appendix A):
<snip>
>           + WH: I've added similar text to the above.  The above has
>             some issues with it so I've adapted it to the following:
>

Looks good, except the last editor's note looks strange (TSMNUM is not
used, and it's not the trap port :).

> * WONTDO Section 4.4.1.1, "Transport Models SHOULD generate a
> predictable tmSecurityName so operators will know what to use when
> configuring MIB modules that use securityNames derived from
> tmSecurityNames."  Setting requirements for all transport models
> (not just DTLSTM) doesn't seem to belong to this document...
>

IMHO we would have removed this sentence from 5592 if we had noticed
it...  but as its currently written, it leaves open the question,
well, does TLSTM generate predictable tmSecurityNames, or does it
behave unpredictably?

So if you feel it provides some valuable information (I don't
think it does), it needs to be rephrased anyway...

>     connection from a client and has received at least one SNMP

Yes, this was my intent :)

> * DISCUSS Appendix A and B: Please just delete these -- the details
> aren't quite right (e.g. DTLS sessions...), and fixing them is not
> worth the effort needed.
>

Well, as AD I do require that if the text is included, it needs to be
correct. Fixing the text will require some effort and will take time.
I'm OK if we have WG members who're willing to do that effort and the
WG consensus is that it's worth delaying the document.

Here's a partial lists of things that are either wrong or
misleading:

- A.1: encryption keys are not per session, but per connection
  state (if multiple TLS connections are resumed from the same
  TLS session, they get different encryption keys)
- A.1: "such as the (D)TLS handshake protocol" is very misleading,
since it suggests there are other protocols that could be used.
But there are none.
- A.1: Message integrity doesn't necessarily use hash functions;
  MACs can also be based on block ciphers, and TLS supports
  combined mode (authenticated encryption), too.
- A.1: "is generally only used" suggests there are other cases;
there are none.
- A.1: replay protection is optional in DTLS
- A.2: the references [AES], [DES], [DSS], [RSA], [X509] are missing
  most of the details.
- A.2: (D)TLS support other ways of authenticating the peers
  than public-key crypto
- A.2: I-D.saintandre-tls-server-id-check applies only to
  some application protocols; others may use other approaches.
- A.2.: "anonymous denial of service attacks" cookies have nothing
  to do with anonymity; they're about spoofed source IP addresses.
- A.2: retransmissions apply only to handshake messages, not whole DTLS
- B: the two-step process of verifying signature first, checking
  digest second doesn't work that way with e.g. DSA or ECDSA.
- B describes only certificates directly issued by locally configured
  trust anchors; but important part of X.509 is path validation.
- "root certificate" is not a term used in PKIX
- B, "signatureValue": these details of ASN.1 encoding don't seem very
  useful to a reader who doesn't know what certificates are.

> * DONE C.1, would suggest adding "In case the notification originator
> has multiple certificates, ..." to the beginning of the 2nd para.
>

OK.

>     times)

Yes, it would mess up the formatting, so perhaps it's ok to
leave this as-is...

Best regards,
Pasi

---

From: <[email-masked]>
Date: Fri, 5 Mar 2010 12:02:00 +0100

Tom Petch wrote:

> SNMP may have long running sessions - I know, there is no concept of
> session in SNMP but allow me a little licence - so that it may trip
> over limitations on the usage of the security credentials in a way
> that other applications do not.
> 
> A certificate could expire and so need to be replaced with a current
> one, which is one use of renegotiation.  And so much data could
> flow, or time pass, that the keys need refreshing, which again
> renegotiation allows.
> 
> Do you intend that these be NOT RECOMMENDED ie if and when such are
> needed, tear down the TLSTM session and start again?

Well, TCP connections are cheap (since the situations you're
describing would occur rarely, not several times a second), so in case
of TLSTM, it seems it's much simpler just to start a new connection
instead of doing renegotiation.

(BTW, tearing down the old one can happen after the new one is up,
so this doesn't mean a break in connectivity.)

> Second, you change all the TLS session to TLS connection, which is a
> substantial change.  I had assumed that the author had intended
> session resumption to be permitted which your new text would
> discourage.  Again, is this your intention?

No, this is more a terminology fix. When TLSTM needs to establish a
connection, it asks TLS to do so; TLS might or might not use
previously cached information when doing so (=session resumption), 
but that's not visible to TLSTM.

Best regards,
Pasi

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 05 Mar 2010 08:59:38 -0800

>>>>> On Fri, 5 Mar 2010 12:02:00 +0100, <[email-masked]> said:

PE> No, this is more a terminology fix. When TLSTM needs to establish a
PE> connection, it asks TLS to do so; TLS might or might not use
PE> previously cached information when doing so (=session resumption),
PE> but that's not visible to TLSTM.

I agree; I thought Pasi's terminology change was definitely correct.  In
summary: you do start a second TLS connection within TLSTM.  Think of it
in terms of an underlying TCP "connection" and it's easier to think about
(and then just extend that to the DTLS case).
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 05 Mar 2010 10:40:04 -0800

Responses in-line.  Quick summary though: these outstanding issues are
all closed now.

>        across management configuration systems.

PE> Yep, this is roughly what I was thinking about. Perhaps we could also
PE> add a sentence giving an example what the "reasons other than
PE> configuration found in the SNMP-TARGET-MIB" and "configuration
PE> mechanisms" might be?

PE> For example, a command-line tool for generating SNMP GETs might
PE> support specifying either the server's certificate fingerprint or
PE> the expected host name as a command line argument.

I think that's good text and have added it.  Thanks.

Issue-status-change: DONE

>     among connections, but using a shared sessionID within TLSTM

PE> Well, I think the "although the tlstmSessionID may be the same.."  part
PE> is very misleading; this is NOT an approach an implementation can use.
PE> Perhaps something like this?

PE> The tlstmSessionID identifier MUST NOT change during the entire
PE> duration of the session from the TLSTM's perspective, and MUST
PE> uniquely identify a single session.  As an implementation hint:
PE> note that the (D)TLS internal SessionID does not meet these
PE> requirements, since it can change over the life of the connection
PE> as seen by the TLSTM (for example, during renegotiation), and does
PE> not necessarily uniquely idenfify a TLSTM session (there can be
PE> multiple TLSTM sessions sharing the same D(TLS) internal
PE> SessionID).

I think this new wording is the most clear yet, so I've put it in place.

Issue-status-change: DONE

>        using a default client certificate available to the

PE> Works for me.

Issue-status-change: DONE

[...]
>       accept any presented certificate.

PE> The text earlier allows wildcards in the certificate, but not in
PE> tlstmAddrServerIdentity, so this paragraph doesn't make sense.

Oh, whoops.  I put that in the email but had deleted it from the actual
draft.  Sorry about that.

>     include such a note as part of the guidance?

PE> The "Registered Ports" range means 1024...49151.

Ah, duh.  Thanks.

<snip>
[...]
>    appropriately assigned "snmptls-trap" port.

PE> Looks good, except the last editor's note looks strange (TSMNUM is not
PE> used, and it's not the trap port :).

Ah, good catch.  It shouldn't have been there and I removed it.

>   + that's boilerplate-ish text directly from 5592 which we're

PE> IMHO we would have removed this sentence from 5592 if we had noticed
PE> it...  but as its currently written, it leaves open the question,
PE> well, does TLSTM generate predictable tmSecurityNames, or does it
PE> behave unpredictably?

PE> So if you feel it provides some valuable information (I don't
PE> think it does), it needs to be rephrased anyway...

Actually, I think adding this text at the end of the above paragraph
makes everything fit nicely together and discuss some of the
implications of the TLSTM:

        The TLSTM generates predictable tmSecurityNames
        based on the configuration found in the TLSTM-MIB's
        tlstmCertToTSNTable and relies on the network operators to have
        configured this table appropriately.

Sound good?

Issue-status-change: DONE  (though I'll reopen if you think this doesn't
solve the problem).

> aren't quite right (e.g. DTLS sessions...), and fixing them is not

PE> Well, as AD I do require that if the text is included, it needs to
PE> be correct. Fixing the text will require some effort and will take
PE> time.  I'm OK if we have WG members who're willing to do that effort
PE> and the WG consensus is that it's worth delaying the document.

Since no one else has spoken up on the subject, I'll delete it.  We can
still wait for the screams.  I have recorded locally you list of issues
so that I can make sure they're fixed if people feel strongly that
removing it was a mistake.

Issue-status-change: DONE

Best regards,
Pasi

---

From: "tom.petch" <[email-masked]>
Date: Fri, 5 Mar 2010 20:07:13 +0100

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, March 05, 2010 12:02 PM

<tp>
Yes and no; we are now binding the TLSTM session to the (D)TLS connection
so starting a new TLS connection will force a new TLSTM session with a break
in connectivity (SNMP is not HTTP:-).  Worst case scenario would be for this to
happen between Get and Response causing the Response to be discarded, making
TLS/TCP an unreliable transport (compared to UDP:-)  Which is ok with me.

</tp>

<tp>
If TLS reuses the connection state with a new transport 5-tuple, then
I expect that that will upset TLSTM.  If TLS reuses connection state
with an old 5-tuple (a rare event with TCP), then again, I expect
that that will upset TLSTM. So I think there cannot be session
resumption.  Again, not a problem for me.

Underlying this is the lack of the concept of a session in SNMP so it
uses the transport parameters as a proxy for it to get Responses back
to the right place; a change of transport parameters ripples up to the
application.  No abstraction layer here.

Tom Petch
</tp>

Best regards,
Pasi

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 05 Mar 2010 18:15:34 -0800

Pasi,

The last remaining issue was section 5.1.1, which I mentioned in the
previous note was a bit more complex and would take more time.  I've now
completed the review of the old vs the new and tried to accommodate
everything.  Let me know if the following doesn't meet your needs.

* DONE

  Your comment:
  -------------

  Largely for the same reason, Section 5.1.1 is not quite
  correct; here's an attempt to rephrase it:

  My Response
  -----------

  + WH: Issues with your text:
    + Some important elements were dropped.
    + You end up creating LCD entries *before* DTLS has the
      opportunity to throw out bad packets which could lead to a
      resource consumption attack (messages to dead or unknown
      connections on the server's side will result in creating
      state).

    Based on this, I took your text and changed it a bit to
    produce this.  Let me know if this looks ok to you.  I
    believe it addresses your concerns with the original text
    and my concerns with yours ;-)

       For connection-oriented transport protocols, such as TCP, the
       transport protocol takes care of demultiplexing incoming packets to
       the right connection.  Depending on the DTLS implementation, for DTLS
       over UDP, this demultiplexing may need to be done by the TLSTM
       implementation.

       Like TCP, DTLS over UDP uses the four-tuple <source IP, destination
       IP, source port, destination port> for identifying the connection
       (and relevant DTLS connection state).  This means that when
       establishing a new session, implementations MUST use a different UDP
       source port number for each active connection to a remote destination
       IP-address/port-number combination to ensure the remote entity can
       disambiguate between multiple connections.

       If demultiplexing received UDP datagrams to DTLS connection state is
       done by the TLSTM implementation (instead of the DTLS
       implementation), the steps below describe one possible method to
       accomplish this.

       The important output results from the steps in this process are the
       remote transport address, incomingMessage, incomingMessageLength, and
       the tlstmSessionID.

       1)  The TLS Transport Model examines the raw UDP message, in an
           implementation-dependent manner.

           2a)  If a matching entry in the LCD does not exist then the UDP
                packet is passed to the DTLS implementation for processing.
                If the DTLS implementation returns both success and a new
                connection handle then this and a newly assigned
                tlstmSessionId is cached as a new entry in the LCD.  If the
                DTLS implementation returns an error then processing stops.

           2b)  If a session does exist in the LCD then its DTLS connection
                handle (an implementation dependent detail) and its
                tlstmSessionId is extracted from the LCD.  The UDP packet
                and the connection handle is passed to the DTLS
                implementation.  If the DTLS implementation returns success
                but does not return an incomingMessage and an
                incomingMessageLength then processing stops (this is the
                case when the UDP datagram contained DTLS handshake
                messages, for example).  If the DTLS implementation returns
                an error then processing stops.

       3)  Retrieve the incomingMessage and an incomingMessageLength from
           DTLS.  These results and the tlstmSessionID are used below in
           Section 5.1.2 to complete the processing of the incoming message.

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 05 Mar 2010 18:32:24 -0800

>>>>> On Fri, 5 Mar 2010 20:07:13 +0100, "tom.petch" <[email-masked]> said:

tp> Yes and no; we are now binding the TLSTM session to the (D)TLS
tp> connection so starting a new TLS connection will force a new TLSTM
tp> session with a break in connectivity (SNMP is not HTTP:-).  Worst
tp> case scenario would be for this to happen between Get and Response
tp> causing the Response to be discarded, making TLS/TCP an unreliable
tp> transport (compared to UDP:-) Which is ok with me.

Anything we do could result in something going down between the point
where the command responder starts processing a request and the point it
wants to send the reply back out.  Pasi's text changes haven't affected
this at all.

But renegotiation with a new session would require a potential change in
a securityName which is a bigger issue.  I don't think we have any
scenarios that really require renegotiation so I don't see the harm in
dropping support for it, but I do see benefits.

tp> If TLS reuses the connection state with a new transport 5-tuple, then
tp> I expect that that will upset TLSTM.

TLSTM will operate just fine.  There may be a new tlstmSessionId even
though a previously existing session within TLS was reused.  But again,
the only time I see that being a problem is in the middle of command or
notification responder processing (or proxy).  But again, the connection
has already gone down in this case so the responder is already stuck.
Session resumption merely buys us the ability to spin up faster the next
time around.  Pasi's rewording of session -> connection doesn't change
any of this.

tp> If TLS reuses connection state with an old 5-tuple (a rare event
tp> with TCP), then again, I expect that that will upset TLSTM.

With proper processing then TLSTM should have dropped it's knowledge on
a TCP close.  On a dead DTLS case, DTLS will be just as confused as
TLSTM would be and again, nothing new is introduced.

tp> So I think there cannot be session resumption.  Again, not a problem
tp> for me.

I think you're wrong about that.  But we don't spell out the details of
when and how you'd do that within our draft (and we didn't before
either).  Implementations could very easily implement session resumption
by matching remote targets with sessions that could be reused.  Can you
find text in our document that would prohibit that from working?  Note
that session resumption would need to happen in the same way that
algorithm selection needs to happen: via configuration beyond the scope
of this document, as is already stated.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: <[email-masked]>
Date: Sat, 6 Mar 2010 12:59:12 +0100

Wes Hardaker wrote:

> PE> IMHO we would have removed this sentence from 5592 if we had
> PE> noticed
> PE>
> Issue-status-change: DONE (though I'll reopen if you think this
> doesn't solve the problem).

Sounds good!

Best regards,
Pasi

---

From: <[email-masked]>
Date: Sat, 6 Mar 2010 13:12:00 +0100

Tom Petch wrote:

> Yes and no; we are now binding the TLSTM session to the (D)TLS
> connection so starting a new TLS connection will force a new TLSTM
> session with a break in connectivity (SNMP is not HTTP:-).  Worst
> case scenario would be for this to happen between Get and Response
> causing the Response to be discarded, making TLS/TCP an unreliable
> transport (compared to UDP:-) Which is ok with me.
> </tp>

Well, nothing prevents having more than one TLS connection between the
SNMP entities, so tearing down the old one could happen some time
after the new one has been established...

> If TLS reuses the connection state with a new transport 5-tuple,
> then I expect that that will upset TLSTM.  If TLS reuses connection
> state with an old 5-tuple (a rare event with TCP), then again, I
> expect that that will upset TLSTM. So I think there cannot be
> session resumption.  Again, not a problem for me.

(BTW, in TLS "connection state" and "session state" are different
things; TLS will never reuse the connection state for another
connection.)

This will not upset TLSTM, because to applications, new and resumed
TLS connections look exactly the same (TLSTM does not know whether
session resumption is happening or not, and does not need to 
know -- it's a purely TLS internal detail).

Best regards,
Pasi

---

From: <[email-masked]>
Date: Sat, 6 Mar 2010 13:27:27 +0100

>   connections on the server's side will result in creating

Good point! Creating the LCD entry is needed only if DTLS has
decided to allocate state (which doesn't happen if it responds to
ClientHello with HelloVerifyRequest, or if the incoming packet is
junk).

<snip>

> packet is passed to the DTLS implementation for processing.  If the
> DTLS implementation returns both success and a new connection handle
> then this and a newly assigned tlstmSessionId is cached as a new
> entry in the LCD.  If the DTLS implementation returns an error then
> processing stops.

It's not quite clear what "returns success" means here. Perhaps
something like this:

2a) If a matching entry in the LCD does not exist, then the UDP 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.

Best regards,
Pasi

---

From: Wes Hardaker <[email-masked]>
Date: Sat, 06 Mar 2010 07:18:38 -0800

>>>>> On Sat, 6 Mar 2010 13:27:27 +0100, <[email-masked]> said:

PE> It's not quite clear what "returns success" means here. Perhaps
PE> something like this:

Ok, I've changed the text to that.  Which closes out the new outstanding
issues entirely and I'll go publish a new copy of the draft momentarily
which should meet all of your outstanding "revision needed" requirements.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: <[email-masked]>
Date: Mon, 8 Mar 2010 08:06:59 +0100

Thanks! Version -09 looks good, and I've asked the secretariat 
to start the IETF last call.

Best regards,
Pasi

> -----Original Message-----
> From: ext Wes Hardaker [mailto:[email-masked]]
> Sent: 06 March, 2010 17:19
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: IsmsAD review comments for draft-ietf-isms-dtls-tm-08
>

---

From: "tom.petch" <[email-masked]>
Date: Mon, 8 Mar 2010 15:35:30 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: <[email-masked]>; "isms" <[email-masked]>
Sent: Friday, March 05, 2010 9:24 AM

> > Second, you change all the TLS session to TLS connection, which is a
substantial
> consider session resumption essential.

Juergen

I am unclear.  Are youre requirements met by the new wording, of
"That is, implementations MUST
   either disable renegotiation completely (RECOMMENDED), or MUST
   present the same certificate during renegotiation (and MUST verify
   that the other end presented the same certificate).
"
which I have previously paraphrased as 'NOT RECOMMENDED'?

Tom Petch

>                                 There are many management tools

---

From: "tom.petch" <[email-masked]>
Date: Mon, 8 Mar 2010 15:41:18 +0100

----- Original Message -----
From: "Wes Hardaker" <[email-masked]>
Sent: Saturday, March 06, 2010 3:32 AM

> of this document, as is already stated.

Wes

You may recall that during the production of the first three RFC, there were a
number of occasions when I found that what we had specified would lead to
commands never getting responses.  I found that by spending considerable time
going through the EoPs to confirm my suspicions (and then even longer convincing
the editors that what we had really would not work:-(.

I suspect that the something comparable will emerge here, although not as
serious, but it will take me a while to confirm or deny this, so I will go away
and do the work and come back to you when I have the answer; but it will take
some time, perhaps weeks not days.

Tom Petch

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 08 Mar 2010 09:23:02 -0800

>>>>> On Mon, 8 Mar 2010 15:41:18 +0100, "tom.petch" <[email-masked]> said:

tp> You may recall that during the production of the first three RFC,
tp> there were a number of occasions when I found that what we had
tp> specified would lead to commands never getting responses.  I found
tp> that by spending considerable time going through the EoPs to confirm
tp> my suspicions (and then even longer convincing the editors that what
tp> we had really would not work:-(.

I think it is highly likely that as we develop more and more connection
oriented approaches to things (or at least finish the ones we've
started) that one of the downsides of a connection oriented approach
(even when sent over a connectionless base transport layer) is that if
the connection goes down the responder will get confused and not be able
to cope.

There are really only two scenarios:

A) connection lost in the middle

   1. CG opens a connection
   2. CG sends a request
   3. CR receives the request and starts to process it
   4. Connection drops (the reason doesn't really matter)
   5. CR wants to send the response and either:
      a. The most likely: it simply can't and drops it
      b. Somehow manages to open a reverse connection, which has long
         been discussed and never solved in the IETF
      c. Queues it and Waits for the manager to open a connection

   I'd argue that although we'd like b., no one today is doing it nor
   will they soon.  c. is even less likely to ever happen and many would
   argue shouldn't happen.  Thus, a. is the only real world choice at
   the moment.

B) connection lost in the middle and re-established very very quickly

   1. CG opens a connection
   2. CG sends a request
   3. CR receives the request and starts to process it
   4. Connection drops (the reason doesn't really matter)
   5. Connection is re-opened by the manager with as a new "connection"
      which may or may not be a re-established old session.
   6. CR wants to send the response and either:
      a. Can figure out that the existing request can be sent over the
         new connection
      b. Can't and drops it.

   I believe that the current real world code and the way state is
   handled internally makes a. nearly impossible without a lot of work.
   Now, if this was a common case (IE connections come and go
   frequently) then maybe it'd be worth solving, but in the end I think
   the likelyhood of this being a real world problem worth solving is
   very very low.  If a connection is going up and down so frequently
   that you're dropping huge numbers of request/response pairs due to
   the flapping then you have some pretty serious issues.  Certainly you
   shouldn't be using a transport that is flapping so much (and many
   would argue that's one of the prime reasons for using a UDP based
   transport, be it raw UDP/USM or the now possible UDP/DTLS).

   And this doesn't even get into manager code, where modern code is
   also likely tied to state that will not accept responses from a
   different source stream.

Don't get me wrong: I agree that it's likely that if a connection drops
and gets restarted the likelyhood of an agent being able to successfully
transmit the response back to the manager is very very slim.  But I
remain unconvinced that even if we solved this in the SNMPv3
architecture and transport models that the real world code could easily
implement it or would find it worthwhile to do so.  But, fortunately,
SNMP was designed at the application layer to expect transport issues a
lot of the time which is why they all have "timeouts" and "retries" and
even make use of those parameters when a TCP-based session is in place.
I do think that most manager code today is smart enough to open a new
connection if it needs to retry and finds its previous connection closed.

---

From: "David Harrington" <[email-masked]>
Date: Mon, 8 Mar 2010 14:45:31 -0500

Hi,

> interface that supports configuring the same details as

Note that even notification originators aren't required to have a MIB.
>From RFC3413:
Notification originator applications require a mechanism for
   identifying the management targets to which notifications should be
   sent.  The particular mechanism used is implementation dependent.
   However, if an implementation makes the configuration of management
   targets SNMP manageable, it MUST use the SNMP-TARGET-MIB module
   described in this document.

> identify a TLSTM session. I would suggest just deleting this

I think the paragraph should be reworded to ensure that tlstmSessionID
uniquely identifies a TLSTM session. (or in the more generic case, a
TM session).

> doesn't seem to belong to this document...

Didn't we leave determining the tmSecurityName to implementers?
If so, then the paragraph should read 
"Transport Model implementations SHOULD generate a predictable
tmSecurityName so operators will know what to use when configuring MIB
modules that use securityNames derived from tmSecurityNames."

and for that matter, shouldn't this be a MUST? If operators cannot
predict the format of the tmSecurityname generated by the
implementation, they cannot configure the MIB. 

dbh

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Mar 2010 08:23:53 +0100

> which I have previously paraphrased as 'NOT RECOMMENDED'?

I am not an expert on (D)TLS regenotiation issues but I personally
believe we went over board with this. I consider the renegotiation bug
of TLS a temporary problem that can and likely will be cured (see RFC
5746). Hence, we are making a bad decision to outlaw renegotiation in
general just because many deployed libraries today are somewhat
vulnerable.

I would prefer if the second paragraph in section 4.2 would be removed
and we would add discussion to the Security Considerations pointing
out the issue with "old" TLS code and the ways to work around things,
including the option to disable renegotiation if the (D)TLS library
used has not fixed the problem, e.g. via RFC 5746, or to verify the
same certificate has been used during renegotiation.

Comments?

/js

---

From: <[email-masked]>
Date: Tue, 9 Mar 2010 12:50:01 +0100

Juergen Schoenwaelder wrote:

> believe we went over board with this. I consider the renegotiation
> bug of TLS a temporary problem that can and likely will be cured
> (see RFC 5746). Hence, we are making a bad decision to outlaw
> renegotiation in general just because many deployed libraries today
> are somewhat vulnerable.
> 

Even if you implement RFC 5746, the current EoP (sections 5.3.1 and
5.3.2) won't work as-is if you allow renegotiation with different
certificates.  The changes needed look rather cumbersome, and in TLSTM, 
if changing certificates is needed (e.g. certificate is renewed), opening
a new TCP connection is cheap. So even if both ends implement RFC 5746,
we still need the text about verifying that the same certificate
has been used.

Best regards,
Pasi

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Mar 2010 09:51:37 +0100

> we still need the text about verifying that the same certificate

Sure if the certificate gets renewed, opening a new connection is
indeed cheap and appropriate. I can live with the "same certificate
needs to be used" rule and the text that is in the ID. I note,
however, that the SYSLOG over DTLS ID deals with renegotiation only in
the security considerations and it says:

   [...] If, for some reason, renegotiation is
   allowed then the specification in RFC 5746 MUST be followed and the
   implementation MUST make sure that the connection security parameters
   do not change during renegotiation.

This text only requires that "security parameters do not change", so
it seems a bit more flexible than what we have in the ISMS document,
which requires that the certificate must be the same. But then there
is no access control model for SYSLOG and for ISMS we likely needed to
consider everything that may map to a securityName a "security
parameter" not to change and instead doing detailed comparison of
certs it might indeed be simpler to require that the certs are the
same.

/js

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 11 Mar 2010 07:54:30 -0800

>>>>> On Thu, 11 Mar 2010 09:51:37 +0100, Juergen Schoenwaelder <[email-masked]> said:

JS> But then there is no access control model for SYSLOG and for ISMS we
JS> likely needed to consider everything that may map to a securityName
JS> a "security parameter" not to change and instead doing detailed
JS> comparison of certs it might indeed be simpler to require that the
JS> certs are the same.

Renegotiation with different certificates would require significant
changes, as it would likely invalidate the existing securityName
attached to the session.  Even if we just required the securityName to
be the same we'd still need to write a new 5.3.x section or two that
described EoP for handling renegotiation I think describing that after a
renegotiation the securityName must be re-extracted and compared.

But what's the gain?  I don't really see that we're trying to develop a
protocol that needs frequent renegotiations.  If we needed it, I think
there are solutions we could pick from and work toward documenting and
delay everything even longer.  But I've yet to see a use case that will
happen on a regular enough basis to make it worthwhile to document the
procedure.  SNMP applications just don't have a need to change
identities frequently.

---

From: "tom.petch" <[email-masked]>
Date: Fri, 12 Mar 2010 18:15:14 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, March 11, 2010 9:51 AM

Juergen

The text you quote is a new addition to the syslog I-D which I have asked to be
amended to be explicit that change of certificate should not happen so I do not
think that the current text should be used as an examplar.

Tom Petch