Subject: Re: [Isms] wg last call on the (d)tls transport model

From: "David Harrington" <[email-masked]>
Date: Wed, 9 Dec 2009 21:18:29 -0500

Hi,

I reviewed draft-ietf-isms-dtls-tm-02.txt and have comments.

section 1
s/defines supports/supports/

paragraph 4 repeats the last sentence of paragrah 1.
I recommend eliminating paragraph 4.

section 1 says
The Transport Model in this
   document is referred to as the Transport Layer Security Transport
   Model (TLSTM). 
But the diagram shows DTLS TM

TSM is used in the diagram before being mentioned in the text.

Diagram 
s/Notification Responder/Notification Receiver/
s/NOTIFICATION ORIGINATOR applications/NOTIFICATION ORIGINATOR
application/

section 1.1
Some changes have been made to the wording and/or capitalizations in
the conventions section, compared to RFC5592. Some of those wordings
were done at the request of the rfc editor. I recommend not making
changes between the SSH-TM and TLS-TM documents unless there is a
valid technical reason to do so. Consistency in the conventions is a
good thing.

Many of the conventions relate to SNMP in general, and some relate to
the specifics of this transport model. I recommend the tlstm-specific
conventions be positioned after the general conventions. I would move
the paragraph starting "Large portions" after the discussions of
agent/manager and principal. This would be consistent with the
arrangement in the SSH-TM document. Because you use the (D)TLS term in
the client/server discussion, the paragraph starting "Large portions"
should precede the client/server discussion.

section 2.1 first paragraph is a bit hard to parse. It could use
wordsmithing.

Section 2 mentions authentication, data message integrity, and
privacy. Section 2.1 discusses mutual authentication and encryption.
Section 3.1 discusses a broader range of threats addressed by the
model. I think it would be good to put the discussion of what threats
TLSTM addresses, and how it addresses them, in one place, and couples
that with the MUST support features from section 2.1 (which is part of
how it addresses them).

The "primary goal paragraph in section 2 says a goal is source
authentication, but section 1 explicitly says
   Authentication in this document typically refers to the English
   meaning of "serving to prove the authenticity of" the message, not
   data source authentication or peer identity authentication.
There is a mismatch between how many in the security community define
"source authentication" and the authentication done in a transport
model. That's why SSHTM and TSM do not use the term "source
authentication".

section 2 doesn't actuallly describe TLS or DTLS at all. I think it
should provide a quick architectural overview for SNMP readers (you
know, TLS for Dummies ;-).

section 3
In paragraph 2, unencrypted/encrypted was changed to
unprotected/protected. RFC5592 used unencrypted because any
unencryption (decryption) is expected to be done before the message is
passed to the MPM. This is important for the elements of procedure to
work, and it is important to understand how the transport model fits
into the architecture - the purpose of this section. I don't know what
unprotected means in this context. Remember we are NOT trying to be
consistent with other security terminology; we are supposed to remain
consistent with other SNMP terminology (as described under
conventions). We had a serious debate about whether to be consistent
with SNMP or with a Security Glossary that was being published.
Consensus was to remain consistent with other SNMP documents. We don't
use "protected" and "unprotected" in other SNMP documents.

I don't know why you added the "authenticated and intergity-checked"
text here, because that has nothing to do with how the transport model
fits into the architecture.

The RFC Editor questioned the inconsistency of capitalization for
terms like Dispatcher and the applications between RFC5592 and other
SNMP document, so we aligned them (probably imperfectly). You
obviously prefer the opposite of the way our other ISMS documents have
been handled. 

In the section about establishing channels/sessions, RFC5592 says
multiple message sMAY be passed in the same channel. I think the same
is accurate for (D)TLS. But you expanded this to add a SHOULD here. I
would be very careful about this. We had significant debate about
requests/responses having to go through the same channel/session. This
SHOULD that you added could be misinterpreted in that context. I think
the wording in RFC5592 fit the consensus, and your changes might
conflict with that consensus.

I would be really careful about all these minor unnecessary editorial
changes to text that had WG consensus. Some of the original text was
written as it is for very specific reasons.

section 3.1.1 was written to describe how SSH addressed the threat.
IIRC, the WG decided it was not necessary to describe the threat,
since that was already done in RFC3411. Did the WG change its mind on
this point?

The application names are incorrect in the masquerade bullet.
I think think it is incorrect to say that TLSTM authenticates the
applications. TLSTM authenticates the TLS server and TLS client.

The text does not describe the connection between X.509 certificates
and the Access Control models that prevent masquerade.

I would be careful using the word Privacy in the Disclosure paragraph.
Privacy in SNMP means encryption; it has a very different meaning in
the security community, usually related to a person's control of data
pertaining to them. I would just use the term encryption:
       The TLS and DTLS protocols provide support for encryption tp
prevent unauthorized disclosure of data.

or to be consistent with RFC5592:
   4.  Disclosure - (D)TLS provides protection against the disclosure
of
       information to unauthorized recipients or eavesdroppers by
       allowing for encryption of all traffic between SNMP engines.

Denial of Service:
       Implementations are not required to perform the stateless
cookie
       exchange for every DTLS handshake, but in environments where an
       overload on server side resources is detectable it is
RECOMMENDED
       that the cookie exchange is utilized.
/detectable/detectable by the implementation/
/utilized/utilized by the implementation/
This is purely an implementation decision, not a deployment decision,
correct?

section 3.1.2
/Message Protection/Message Authentication/

   The TLS Transport Model determines from (D)TLS the identity of the
   authenticated principal, and the type and address associated with
an
   incoming message.  The TLS Transport Model provides this
information
   to (D)TLS for an outgoing message.
not really; the identity provided to (D)TLS for Requests is not yet
authenticated. The identity provided to (D)TLS for Notifications is
authorized, but not yet authenticated, except implicitly.

   If a suitable interface between the TLS Transport Model and the
   (D)TLS Handshake Protocol is implemented to allow the selection of
   security level dependent algorithms (for example a security level
to
   cipher_suites mapping table) then different security levels may be
   utilized by the application.
Will this be interoperable with engines that do not support selection
of security dependent algorithms?

/trust of particular algorithms and implementations should offer/
   trust of particular algorithms. Implementations should offer/
(the current wording made it look like "algorithms and
implementations" rather than the start of a new point.

   time.  Implementers are encouraged to plan for changes in operator
   trust of particular algorithms and implementations should offer
   configuration settings for mapping algorithms to SNMPv3 security
   levels.
The SNMP community has historically deliberately avoided any attempts
to classify algorithms or crypto suites by strength. If different
engines use different mappings, then the assumptions of the sender may
not match those of the receiver, and security vulnerabilities could
result. I am not sure that would be true of a TLS environment, but we
have traditionally steered clear of this approach in SNMP standards.

s/tlsSnmpSessionID/tlstmSessionID/

   DTLS sessions, when used over UDP, are uniquely identified within
the
The UDP portion of the paragraph doesn't talk about the need for a
unique address/port pairing; this is only mentioned when TCP/SCTP are
said to NOT need it. I think the UDP section should talk about this
requirement, or the TCP/SCTP should not discuss it. I am not certain
it needs to be discussed here.

   The tlsSnmpSessionID MAY be the same as the (D)TLS internal
SessionID
   but 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 tlsSnmpSessionID identifier
MUST
   NOT change during the entire duration of the connection from the
   TLSTM's perspective.
This paragraph seems to encourage the match between tlstmSessionID and
the TLS session ID, which we know has potential problems. Wouldn't it
be better to say implementers SHOULD NOT do this because ...

   are translated by the TLS Transport Model into security parameters
   for the TLS Transport Model and security model (i.e.,
securityLevel,
RFC5592 says
   translated by the Transport Model into security parameters
   independent of the Transport and Security Models.  The Transport
This was very deliberate because securityLevel, securityName, and
transport address are suposed to be independent of the models to
maintain modularity.

   provided by the dispatcher in the sendMessage() Abstract Service
   Interface (ASI) and input from the tmStateReference cache.  The
The ASI includes the tmStateReference, so this is redundant.
s/Interface (ASI) and input from the tmStateReference cache./Interface
(ASI)./

   (D)TLS sessions may be initiated by (D)TLS clients on behalf of
   command generators, notification originators or proxy forwarders.
The applications that can do this should not be constrained by a list
like this. New applications could be developed. I notice RFC5592 uses
an even shorter list - whoops!
s/originators or proxy forwarders/originators, proxy forwarders, and
possibly other applications/

   notification originators and proxy forwarders are usually unmanned
   automated processes.  The targets to whom notifications should be
   sent is typically determined and configured by a network
   administrator.
You added proxy forwarders to unmanned processes, but then only talk
about configuring notifications. Admins also need to configure the
proxy relationships.

   object and an appropriate snmpTLSAddress value.  The
   snmpTargetParamsMPModel column of the snmpTargetParamsTable should
be
   set to a value of 3 to indicate the SNMPv3 message processing
model.
Is that a SHOULD be?
IIRC, Operators can send SNMPv1 messages over USM and SSHTM. The
RFC3411 architecture calls for these to be modular, so an SNMPv3
message, for example, might be sent over this transport. Requiring
this to be a 3 violates RFC3411 modularity. Operators should be able
to send any message version over this transport; the document should
discuss the implications of doing so.

section 4.1
Should this section say that support of X.509 certs is REQUIRED for
interoperability purposes?

4.1.1
   Authentication using (D)TLS will require that SNMP entities are
   provisioned with certificates, which are signed by trusted
   certificate authorities.  Furthermore, SNMP entities will most
s/certificate authorities./certificate authorities (possibly itself).

   Trusted public keys from either CA certificates and/or self-signed
   certificates, must be installed through a trusted out of band
   mechanism into the server and its authenticity MUST be verified
   before access is granted.
s/through a trusted out of band mechanism/, e.g., through a trusted
out of band mechanism/
s/must be installed/MUST be installed/

   authenticated tmSecurityName of the principal is derived up using
the
"derived up"?

   entity can use for certificate verification.  SNMP entities SHOULD
   also be provisioned with a X.509 certificate revocation mechanism
we don't that to be a MUST?

   potential tlstmCertToTSNTable mapping exists before performing
s/potential//
you want it there already, right? potential means the mappng can be
added in the future. How will the engine know what potentially might
be configured in the future?

   Implementations MAY choose to discard any connections for which no
   potential tlstmCertToTSNTable mapping exists before performing
   certificate verification to avoid expending computational resources
   associated with certificate verification.
This is an implementation optimization. We probably should not be
discussing it unless it impacts interoperability. If ti impacts
interoperability, then we should probably be stating a SHOULD or a
MUST here.

   The typical enterprise configuration will map a "subjectAltName"
   component of the tbsCertificate to the TLSTM specific
tmSecurityName.
How do you know what a typical configuration will look like?
If this is a recommendation, then use SHOULD, not "typical"

tbsCertificate is not mentioned yet in the document. I recommend you
mention the cert in earlier discussions of X.509, and then point the
reader to Appendix B for more information.

You talk about mapping to a securityName, but I think you miss some
very important rules about tmSecurityName:
   The tmSecurityName MUST be a human-readable name (in
snmpAdminString
   format) representing the identity that has been set according to
the
   procedures in the Elements of Procedure.  The tmSecurityName MUST
be constant for all
   traffic passing through a TLSTM session.  Messages MUST NOT be sent
   through an existing TLS session that was established using a
   different tmSecurityName.

The mapping discussion happens in a section called "Provisioning for
the certificate" - but the mapping is not about provisioning, is it?

section 4.2
   within a single DTLS datagram.  The TLSTM SHOULD prohibit SNMP
   messages from being sent that exceeds the maximum DTLS message
size.
What are the acceptable exceptions that justify a SHOULD here, rather
than a MUST? What will likely happen if the SNMP engine sends messages
of excessive size?

      Transport Model.  This document specifies the snmpTLSDomain, the
      snmpDTLSUDPDomain and the snmpDTLSSCTPDomain" transport domains.
why do we need three different domains?

      destTransportAddress.  This parameter may also be used by the
      transport subsystem to route the message to the appropriate
      Transport Model.  This document specifies the snmpTLSDomain, the
Isn't that exactly why we have three domains? Becaise the domain is
used by the transport subsystem to decide which transport model to
use? So should there be ONE domain the subsystem needs to know about,
since all three combinations go to the same transport model? Does the
transport model have nay way to determine which combionation to use,
or does it have to rely on the domain to determine that?

   tmStateReference:  A handle/reference to tmSecurityData to be used
by
      the security model.
I believe this is incorrect. This is a reference to the tmState cache,
not the security cache. 

4.4.1
Actually, tlstm does have specific responsibilities. It creates the
tmSecurityName via the mapping tables, and creates the tmSessionID.
This is the place where those discussions really belong.

s/first prior/prior/

5.1.1
   DTLS is significantly different in terms of session handling than
       ^
    over UDP

   2)  The TLS Transport Model queries the LCD using the transport
       parameters (source and destination addresses and ports) to
       determine if a session already exists and its tlsSnmpSessionID.
So there can be only one DTLS session that exists between two
endpoints? There cannot be two with different security principals or
different securityLevels? I think that contradicts something I read
earlier about securityLevels and mappings to crypto suites.
Which table in the LCD does this query? Is the table only for DTLS/UDP
sessions?

s/through what session/through which session/

       If a matching entry in the LCD does not exist then the message
is
       passed to DTLS for processing without a corresponding
       tlsSnmpSessionID.  The incoming packet may result in a new
       session being established if the receiving entity is acting as
a
       DTLS server.  If DTLS returns success then stop processing of
       this message.  If DTLS returns an error then and the the
       tlstmSessionNoAvailableSessions counter and stop processing the
       message.
If I read this correctly, then whether DTLS returns success or returns
an error, we stop processing the message at this point. What is DTLS
doing with this packet we pass it? Does it return something to us
other than an error code? I have difficulty following the purpose and
logic in this paragraph.

The last sentence needs to be rewritten. I am not sure what it meant
to say.

"rogue" is used withiout being defined. Is this a malicious message?
Can you proivde a reference so I can understand what a rogue message
is? Is this an SNMP message? I don't recognize the term from other
SNMP documents.

I didn't review the DTLS spec. Is it accurate that DTLS receives a
packet, passes it to the application for demultiplexing, which passes
it back to DTLS to create a session(?), then DTLS passes it back to
the application, to record the sessionID, and then the application
passes it back to DTLS for decryption, which then passses the
decrypted packet to the application? Boy, so much for layering.

5.1.2
singular? would single work here - just one at a time? or is the usage
of  singular that means outstanding or unusual - does singular have a
special meaning in the DTLS world? If so, then the definition should
be discussed.

5.2
you don't check that the tmStateReference refers to a cache containing
the required values. This is something the WG decided needed to be
done.

you don't extract the transportDomain from tmStateReference, but you
will need that to know whuch security mechansism and which underlying
transport to use if you have to establish a new session.

I notice that the snmpSshtmSessionNoSessions and
tlstmSessionNoAvailableSessions counters have different name
contructions, but count the same types of errors. Can we contruct the
names in a similar fashion to make it easier for operators?

   3)  If tmSameSecurity is false and tmSessionID refers to a session
       that is no longer available then an implementation SHOULD open
a
       new session using the openSession() ASI (described in greater
       detail in step 4b).  An implementation MAY choose to return an
       error to the calling module and stop processing of the message.
Shouldn't we have standardization in this handling? Why do we need to
allow implementers to return an error rather than trying to open a new
session? Which error counter gets returned if the implementation makes
this choice?
Would this choice be better inside the openSession() processing?

what does an undefined tmSessionID look like?

   4)  If tmSessionID is undefined, then use tmTransportAddress,
       tmSecurityName and tmRequestedSecurityLevel to see if there is
a
       corresponding entry in the LCD suitable to send the message
over.

Does this decision consider DTLS vs TLS, and UDP vs TCP vs SCTP?
Domain isn't mentioned.

            Section 5.3).  Implementations MAY wish to offer message
            buffering to prevent redundant openSession() calls for the
            same cache entry. 
I am not sure what type of message buffering you refer to here. How
will you get redundant openSession() calls?

In 5592, if openSession fails, the tmtateReference being created is
also discarded. Should it be discarded here?

5.3.  Establishing a Session

   The TLS Transport Model provides the following primitive to
establish
   a new (D)TLS session (previously discussed in Section 5.3):
I don't think this was previously discussed in section 5.3, since we
just entered section 5.3.

[I have now spent 14 hours on this review and am one third of the way
through the document. I'll let you start addressing these, and I'll
try to continue the review later this week and next week.]

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 11 Dec 2009 08:46:40 -0800

DH> I reviewed draft-ietf-isms-dtls-tm-02.txt and have comments.

Thanks for the comments David.  I'll start reviewing them for needed
changes to the document.

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 23 Dec 2009 13:42:48 -0800

Hi David,

Thanks for the comments and suggestions.  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

WH: Note: I reformatted much of the comments to ensure they were more
easily readable.  Some that were more severely white space damaged I
didn't reformat due to time constraints.

* DONE Section 1 
  + DONE s/defines supports/supports/ 
    
  + DONE paragraph 4 repeats the last sentence of paragrah 1. 
    I recommend eliminating paragraph 4.
    
  + DONE section 1 says 
    The Transport Model in this document is referred to as the
    Transport Layer Security Transport Model (TLSTM).  But the
    diagram shows DTLS TM
    + WH: Good catch; figure changed.
    
  + DONE TSM is used in the diagram before being mentioned in the text. 
    + WH: Added a sentence and a reference to the paragraph above
      the diagram.
    
  + DONE Diagram 
    
* DONE Section 1.1 
  + DONE Some changes have been made to the wording and/or capitalizations in 
    
    + WH: Done as you suggested.  I actually think the text
      originally come from a pre-RFC version of the SSH document.
    
* WONTDO Section 2.1 first paragraph is a bit hard to parse. It could use 
  wordsmithing.
  + WH: The first paragraph is a sentence long and merely says
    "To properly support the SNMP over TLS Transport Model,
    the (D)TLS implementation requires the following:".  If
    you had a problem with a paragraph I doubt it was this
    one.
  
* DONE Section 2 mentions authentication, data message integrity, and 
  privacy. Section 2.1 discusses mutual authentication and encryption.
  Section 3.1 discusses a broader range of threats addressed by the
  model. I think it would be good to put the discussion of what threats
  TLSTM addresses, and how it addresses them, in one place, and couples
  that with the MUST support features from section 2.1 (which is part of
  how it addresses them).
  + WH: I've moved the MUST/SHOULD sentences into section 3 per
    your suggestion.
* DONE The "primary goal paragraph in section 2 says a goal is source 
  authentication, but section 1 explicitly says
  Authentication in this document typically refers to the English
  meaning of "serving to prove the authenticity of" the message, not
  data source authentication or peer identity authentication.
  
  There is a mismatch between how many in the security community define
  "source authentication" and the authentication done in a transport
  model. That's why SSHTM and TSM do not use the term "source
  authentication".
  + WH: changed to "peer identity authentication"
  
* WONTDO section 2 doesn't actuallly describe TLS or DTLS at all. I think it 
  should provide a quick architectural overview for SNMP readers (you
  know, TLS for Dummies ;-).
  + WH: The WG decided that such a architectural overview would be
    placed into an appendix, which is where it was moved to.
  
* DONE Section 3 
  + DONE In paragraph 2, unencrypted/encrypted was changed to 
    unprotected/protected. RFC5592 used unencrypted because any
    unencryption (decryption) is expected to be done before the message is
    passed to the MPM. This is important for the elements of procedure to
    work, and it is important to understand how the transport model fits
    into the architecture - the purpose of this section. I don't know what
    unprotected means in this context. Remember we are NOT trying to be
    consistent with other security terminology; we are supposed to remain
    consistent with other SNMP terminology (as described under
    conventions). We had a serious debate about whether to be consistent
    with SNMP or with a Security Glossary that was being published.
    Consensus was to remain consistent with other SNMP documents. We don't
    use "protected" and "unprotected" in other SNMP documents.
    + WH: changed to refer specifically to encryption and
      authentication.  I find the current paragraph in 5592
      misleading because SSH does much more than just
      encryption.  I understand your issue with the word
      "protecting" even though I think it's ok to use.  I've
      changed the text, however, to be more explicit about what
      the TLSTM is expecting from the TLS layer.
    
  + WONTDO I don't know why you added the "authenticated and intergity-checked" 
    text here, because that has nothing to do with how the transport model
    fits into the architecture.
    + WH: It definitely fits into the architecture since the
      TLSTM is outsourcing it's authentication and integrity
      protection to the (D)TLS transport.  TLSTM is explicitly
      expecting the TLS layer to have accomplished not just
      encryption (as the SSHTM says) but also verification that
      the message hasn't been modified.  If verification wasn't
      done then we'd have a real problem with using TLS.  SSH
      should have, IMHO, also described this aspect of it's
      architecture in its corresponding paragraph.  We can put
      that on the 'bis todo list ;-)
    
  + DONE The RFC Editor questioned the inconsistency of capitalization for 
    terms like Dispatcher and the applications between RFC5592 and other
    SNMP document, so we aligned them (probably imperfectly). You
    obviously prefer the opposite of the way our other ISMS documents have
    been handled. 
    + WH: Actually, I don't care that much.  It's likely my fingers
      cared, however.  I've changed them to match your expectations.
    
  + DONE In the section about establishing channels/sessions, RFC5592 says 
    multiple message sMAY be passed in the same channel. I think the same
    is accurate for (D)TLS. But you expanded this to add a SHOULD here. I
    would be very careful about this. We had significant debate about
    requests/responses having to go through the same channel/session. This
    SHOULD that you added could be misinterpreted in that context. I think
    the wording in RFC5592 fit the consensus, and your changes might
    conflict with that consensus.
    + WH: I've changed that SHOULD to a MAY.
    
  + ANSWERED I would be really careful about all these minor unnecessary
    editorial changes to text that had WG consensus. Some of the
    original text was written as it is for very specific reasons.
    + WH: the two models are different in different areas.  If
      you're referring to the above, then I agree it can stay
      the same.  In other cases, this isn't the case.  I'm, at
      this point, only changing things in the document people
      have issues with.  Since you had an issue with the above,
      I've changed it.
    
* WONTDO Section 3.1.1 was written to describe how SSH addressed the threat. 
  IIRC, the WG decided it was not necessary to describe the threat,
  since that was already done in RFC3411. Did the WG change its mind on
  this point?
  + WH: During one WG meeting this was discussed I believe (I'd
    have to go back though the audio to double check) and was
    agreed that the text should be shortened (which I did) but
    not removed as it was helpful.  The text, as is, is more
    clear to the reader IMHO.  You don't suggest changing it
    so you must be fine with it too.
  
  + DONE The application names are incorrect in the masquerade bullet. 
    I think think it is incorrect to say that TLSTM authenticates the
    applications. TLSTM authenticates the TLS server and TLS client.
    + WH: changed to: "The TLSTM provides for verification of
      the identity of the (D)TLS server through the use of the
      (D)TLS protocol and the X.509 certificates."
    
  + DONE The text does not describe the connection between X.509 
    certificates and the Access Control models that prevent
    masquerade.
    + WH: I've never liked that paragraph either.  so I've deleted it.
    
  + DONE I would be careful using the word Privacy in the Disclosure paragraph. 
    
    or to be consistent with RFC5592:
       4.  Disclosure - (D)TLS provides protection against the
           disclosure of information to unauthorized recipients or
           eavesdroppers by allowing for encryption of all traffic
           between SNMP engines.
    
    + WH: Changed to your suggested RFC5592 similar text
    
  + DONE Denial of Service: Implementations are not required to perform
    the stateless cookie exchange for every DTLS handshake, but in
    environments where an overload on server side resources is
    detectable it is RECOMMENDED that the cookie exchange is utilized.

    + WH: Um, no...  It could certainly be turned on and off
      with configuration and policy knobs.  That being said, I
      don't think your suggested text is bad either so I've
      changed it to that.  If nothing else, it suggests to do
      the right thing in the default configuration state of the
      transport implementation.
    
* DONE Section 3.1.2 
  + WONTDO /Message Protection/Message Authentication/ 
    + WH: The section discusses more than just authentication; it
      discusses encryption too.
    
  + DONE Quoting: 
    
    "The TLS Transport Model determines from (D)TLS the
    identity of the authenticated principal, and the type and
    address associated with an incoming message.  The TLS
    Transport Model provides this information to (D)TLS for
    an outgoing message."
    
    not really; the identity provided to (D)TLS for Requests
    is not yet authenticated. The identity provided to (D)TLS
    for Notifications is authorized, but not yet
    authenticated, except implicitly.
    
    + WH: Fair enough; I've changed the second sentence to "The
      TLS Transport Model provides the identity and destination
      type and address to (D)TLS for outgoing messages."  If you
      think this is still incorrect, please suggest text.
    
  + ANSWERED Quoting the document: 
    
    "If a suitable interface between the TLS Transport Model
    and the (D)TLS Handshake Protocol is implemented to allow
    the selection of security level dependent algorithms (for
    example a security level to cipher_suites mapping table)
    then different security levels may be utilized by the
    application."
    
    Will this be interoperable with engines that do not
    support selection of security dependent algorithms?
    
    + WH: yes, because they still have to meet the other
      criteria which means that if it's a fixed selection their
      security level must still be appropriate (ie, no NULL for
      auth/encr)
    
  + DONE /trust of particular algorithms and implementations should offer/ 
    trust of particular algorithms. Implementations should offer/
    (the current wording made it look like "algorithms and
    implementations" rather than the start of a new point.
    
  + ANSWERED Quoting: 
    
    "time.  Implementers are encouraged to plan for changes in operator
    trust of particular algorithms and implementations should offer
    configuration settings for mapping algorithms to SNMPv3 security
    levels."
    
    The SNMP community has historically deliberately avoided any
    attempts to classify algorithms or crypto suites by
    strength. If different engines use different mappings, then
    the assumptions of the sender may not match those of the
    receiver, and security vulnerabilities could result. I am
    not sure that would be true of a TLS environment, but we
    have traditionally steered clear of this approach in SNMP
    standards.
    
    + WH: you'll note that we're not standardizing things in
      this document.  We're merely saying to plan for
      algorithmic perceived-strength changes.  The only thing we
      state in the document is you can't use NULL algorithms.
    
  + DONE s/tlsSnmpSessionID/tlstmSessionID/ 
    
  + DONE DTLS sessions, when used over UDP, are uniquely identified within 
    the The UDP portion of the paragraph doesn't talk about the
    need for a unique address/port pairing; this is only
    mentioned when TCP/SCTP are said to NOT need it. I think the
    UDP section should talk about this requirement, or the
    TCP/SCTP should not discuss it. I am not certain it needs to
    be discussed here.
    + WH: You're very right.  In fact, I couldn't find the
      original text that required the uniqueness between ports.
      Turned out it was in a section that was removed and it was
      the place the MUST previously existed.  I've taken the
      older text from the deleted section and ensured it's in
      the new (and the sentence referencing SCTP and TLS/TCP was
      removed since it was somewhat redundant and out of place).
  + WONTDO Quoting: 
    
    "The tlsSnmpSessionID MAY be the same as the (D)TLS
    internal SessionID but 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 tlsSnmpSessionID identifier MUST NOT
    change during the entire duration of the connection from
    the TLSTM's perspective."
    
    This paragraph seems to encourage the match between
    tlstmSessionID and the TLS session ID, which we know has
    potential problems. Wouldn't it be better to say
    implementers SHOULD NOT do this because ...
    
    + WH: It says "MAY", which I don't think is an encouragement.
      It's an implementation hint that you need to be careful
      when doing so.  But if they want to work out the problems,
      they can do so and then match them (which may help them
      with other implementation related binding issues).
    
  + DONE Quoting: 
    
    "are translated by the TLS Transport Model into security
    parameters for the TLS Transport Model and security model
    (i.e., securityLevel,"
    
    RFC5592 says

    
    + WH: I've changed:
      1) s/securityLevel/tmSecurityLevel/
      2) s/i.e./e.g./
    + Both TMs (TLS and SSH) have to do translation.  This
      document merely spells out the current likely needed
      values.  You're right that it shouldn't be explicit though
      and they should be referenced as examples to keep the
      modularity safe for future change.
    
  + WONTDO Quoting 

    The ASI includes the tmStateReference, so this is
    redundant.  s/Interface (ASI) and input from the
    tmStateReference cache./Interface (ASI)./
    + WH: I believe this text helps the reader understand that
      extra important parameters are contained within the object.
    
  + DONE Quoting: 
    
    The applications that can do this should not be
    constrained by a list like this. New applications could be
    developed. I notice RFC5592 uses an even shorter list -
    whoops!  s/originators or proxy forwarders/originators,
    proxy forwarders, and possibly other applications/
    
    + WH: I made the change as "or other applications".
    
  + DONE Quoting: 
    
    You added proxy forwarders to unmanned processes, but then
    only talk about configuring notifications. Admins also
    need to configure the proxy relationships.
    
    + WH: added "and proxied requests"
    
  + DONE Quoting: 
    object and an appropriate snmpTLSAddress value.  The
    snmpTargetParamsMPModel column of the
    snmpTargetParamsTable should be set to a value of 3 to
    indicate the SNMPv3 message processing model.

    Is that a SHOULD be?

    IIRC, Operators can send SNMPv1 messages over USM and
    SSHTM. The RFC3411 architecture calls for these to be
    modular, so an SNMPv3 message, for example, might be sent
    over this transport. Requiring this to be a 3 violates
    RFC3411 modularity. Operators should be able to send any
    message version over this transport; the document should
    discuss the implications of doing so.

    + WH: Added "When used with the SNMPv3 message processing model,
    + WH: And obviously, the answer to your leading "SHOULD" is
      no...  it shouldn't be SHOULD.
    
* DONE Section 4.1 
  Should this section say that support of X.509 certs is REQUIRED for
  interoperability purposes?
  + WH: Added: " TLSTM implementations are REQUIRED to support X.509
    certificates."
  
* DONE Section 4.1.1 
  
  + DONE Quoting: 

    + WH: (possibly the certificate itself)

  + DONE Quoting: 

    + WH: changed must to MUST but didn't add the e.g..  Out of
      band is the only choice as we don't provide an TLSTM
      in-band mechanism (and that would be a challenge ;-).
    
  + DONE Quoting: 
    authenticated tmSecurityName of the principal is derived
    up using the "derived up"?
    
    + WH: s/up//
    
  + ANSWERED Quoting: 

    + WH: no we don't, though feel free to argue that we should
      do otherwise.  I can see cases where it may not be
      possible for certain devices to support revocation lists.
    
  + WONTDO Quoting: 
    
    s/potential//
    you want it there already, right? potential means the
    mappng can be added in the future. How will the engine
    know what potentially might be configured in the future?
    
    + WH: Actually, no.  It's possible that you could find a row but
      it's resulting configuration within the row won't work and
      thus it won't be a "true" match in the end.  This sentence
      is there to say that if you have no matches at all, as an
      implementation hint, you may want to not accept the
      connection at all without diving further into processing
      the message.  IE, a quick drop.
    
  + WONTDO Quoting: 

    + WH: It's an implementation hint.  As has been pointed out by
      other vendor's comments, they have been found useful and
      they're not detrimental.
    
  + DONE Quoting: 
    The typical enterprise configuration will map a
    "subjectAltName" component of the tbsCertificate to the
    TLSTM specific tmSecurityName.

    + WH: Fair point on the wording.  I changed the sentence to be:
      'Enterprise configurations are encouraged to map a
      "subjectAltName" component of the X.509 certificate to the
      TLSTM specific tmSecurityName.'  I don't think that SHOULD
      is acceptable here either as we'd be mandating deployment
      not protocol standardization.
    
  + DONE tbsCertificate is not mentioned yet in the document. I recommend you 
    mention the cert in earlier discussions of X.509, and then point the
    reader to Appendix B for more information.
    
    + WH: Changed to X.509 certificate
    
  + WONTDO You talk about mapping to a securityName, but I think 
    you miss some very important rules about tmSecurityName:
    
       The tmSecurityName MUST be a human-readable name (in
       snmpAdminString format) representing the identity that
       has been set according to the procedures in the Elements
       of Procedure.  The tmSecurityName MUST be constant for
       all traffic passing through a TLSTM session.  Messages
       MUST NOT be sent through an existing TLS session that was
       established using a different tmSecurityName.

    + WH: I don't believe we're missing anything about mapping
      to tmSecurityNames.  It is discussed in multiple places in
      the document like the EOP and the MIB as well (not just in
      the provision section).  If you feel that it should be
      discussed somewhere it is not, please specify the exact spot.
    
* DONE Section 4.2 
  
  + ANSWERED Quoting: 
    within a single DTLS datagram.  The TLSTM SHOULD prohibit
    SNMP messages from being sent that exceeds the maximum
    DTLS message size.
    
    What are the acceptable exceptions that justify a SHOULD
    here, rather than a MUST? What will likely happen if the
    SNMP engine sends messages of excessive size?
    
    + WH: I expect that there are stacks out there that will not
      permit accurate calculations of DTLS message sizes from
      inside an application.  Given that, it's a SHOULD.  If
      it's too large then it'd be an stack error that the
      implementation would have to deal with.  What the stack
      does and whether or not the application is notified is
      beyond the scope.  Warning about the problem, however, isn't.
    
  + ANSWERED Quoting: 

    + WH: Because otherwise there would be no way to configure the
      application to send it via one of the three different
      protocol variations (unless we put a delimiter in the
      address field, but I don't think that's a wise choice).
    
  + DONE Quoting: 
    
    Isn't that exactly why we have three domains? Becaise the
    domain is used by the transport subsystem to decide which
    transport model to use? So should there be ONE domain the
    subsystem needs to know about, since all three
    combinations go to the same transport model? Does the
    transport model have nay way to determine which
    combionation to use, or does it have to rely on the domain
    to determine that?
    
    + WH: I've deleted the "This parameter..." sentence as I
      agree it doesn't make much sense.
    
  + DONE Quoting: 
    tmStateReference: A handle/reference to tmSecurityData to
    be used by the security model.

    + WH: you're right (I checked 5590 to be sure)
    
* DONE Section 4.4.1 
  
  s/first prior/prior/
  
  + WH: I've updated the section to match what is in 5592
    better.  Please let me know if you find anything
    problematic with the near word-to-word copy from 5592.
  
* DONE Section 5.1.1 
  + DONE Quoting: 
    
  + ANSWERED Quoting: 
    
    So there can be only one DTLS session that exists between two
    endpoints?
    + WH: where endpoints is srcaddr/srcport/dstaddr/dstport,
      yes.  As is described as a MUST in multiple places.
    
    There cannot be two with different security principals or
    different securityLevels?
    + WH: where endpoints is srcaddr/srcport/dstaddr/dstport,
      yes.  As is described as a MUST in multiple places.
    
    I think that contradicts something I read
    earlier about securityLevels and mappings to crypto suites.
    + WH: I don't believe so.  Let me know if you find a conflict.
    
    Which table in the LCD does this query? Is the table only
    for DTLS/UDP sessions?
    + WH: It's an implementation dependent cache of data.  It
      doesn't need to be referenced by external modules so is
      not defined concretely in the document.
    
  + DONE s/through what session/through which session/ 
    
  + ANSWERED Quoting: 
    
    If a matching entry in the LCD does not exist then the message is
    passed to DTLS for processing without a corresponding
    tlsSnmpSessionID.  The incoming packet may result in a new
    session being established if the receiving entity is acting as a
    DTLS server.  If DTLS returns success then stop processing of
    this message.  If DTLS returns an error then and the the
    tlstmSessionNoAvailableSessions counter and stop processing the
    message.
    
    If I read this correctly, then whether DTLS returns
    success or returns an error, we stop processing the
    message at this point. What is DTLS doing with this packet
    we pass it? Does it return something to us other than an
    error code? I have difficulty following the purpose and
    logic in this paragraph.
    
    + WH: The point behind the paragraph is less clear after I
      removed the longer multi-paragraph version of it that
      explained in greater detail what DTLS needed to do
      internally.   Functionally, DTLS still needs to process
      messages even if we can't determine why they've arrived.
      Either way: yes, processing will stop from the transport's
      point of view regardless of whether the packet triggers an
      error or is successfully processed (ie, a TLS Hello
      message will result in a success and a garbage packet
      will result in an error; in both cases, there is nothing
      for SNMP to act upon)..
    
  + DONE The last sentence needs to be rewritten. I am not sure 
    what it meant to say.
    
    WH: rewritten to "If DTLS returns an error then increment
    the tlstmSessionNoAvailableSessions counter and stop
    processing the message."
    
  + DONE "rogue" is used withiout being defined. Is this a 
    malicious message?  Can you proivde a reference so I can
    understand what a rogue message is? Is this an SNMP message?
    I don't recognize the term from other SNMP documents.
    
    + WH: changed to "An entry may not exist, however, if a
      message not intended the SNMP entity was routed to it by
      mistake."
    
  + ANSWERED I didn't review the DTLS spec. Is it accurate that DTLS receives a 
    
    + WH: It's implementation specific.  I know for a fact that
      there are two different ways this is handled in the wild
      (currently; we're boiling down to the second one I hope):
    
                                +-------------------+
                                v                   |
      +-----+     +-----+     +-------------+     +------+
      | Net | --> | UDP | --> | Application | --> | DTLS |
      +-----+     +-----+     +-------------+     +------+
    
      Or:
    
      +-----+     +-----+     +------+     +-------------+
      | Net | --> | UDP | --> | DTLS | --> | Application |
      +-----+     +-----+     +------+     +-------------+
    
      IE, your description doesn't match the first that you were
      trying to match against.  The application may receive a
      raw UDP packet which needs processing by DTLS.  Note that
      DTLS doesn't contain a session identifier within it, which
      is why we're trying to define one for the first case where
      DTLS won't be able to cache keys and other information
      based on addr/port combinations.  You *don't* want DTLS
      trying every key it has to figure out which is the right
      one to use when decrypting a packet.
    
      Either way, TLS doesn't have a pretty application
      architecture like SNMP does.  It merely describes the
      protocol bits.  They seem to prefer short, concise
      documents unlike the SNMP WGs.
    
* DONE Section 5.1.2 
  
  + WH: I'm not sure the sentence reads as well with "single",
    but I'm not a great linguist so I'll assume your wording
    is better and I've changed it ;-)
  
* DONE Section 5.2 
  + DONE you don't check that the tmStateReference refers to a cache containing 
    the required values. This is something the WG decided needed to be
    done.
    + WH: added
    
  + DONE you don't extract the transportDomain from 
    tmStateReference, but you will need that to know whuch
    security mechansism and which underlying transport to use if
    you have to establish a new session.
    + WH: tmTransportDomain added
    
  + DONE I notice that the snmpSshtmSessionNoSessions and 
    tlstmSessionNoAvailableSessions counters have different name
    contructions, but count the same types of errors. Can we contruct the
    names in a similar fashion to make it easier for operators?
    + WH: MIB objects changed to match the SSH object structures
    
  + DONE Quoting: 
    3)  If tmSameSecurity is false and tmSessionID refers to
        a session that is no longer available then an
        implementation SHOULD open a new session using the
        openSession() ASI (described in greater detail in
        step 4b).  An implementation MAY choose to return an
        error to the calling module and stop processing of
        the message.
    
        Shouldn't we have standardization in this handling? Why do
        we need to allow implementers to return an error rather than
        trying to open a new session? Which error counter gets
        returned if the implementation makes this choice?  Would
        this choice be better inside the openSession() processing?
    
        + WH: I believe it's impossible to guarantee that a new
          session can be opened.  So, yes, they SHOULD try if they
          can on behalf of the client but either way the client may
          have to deal with errors.
    
          Note that the SSH document actually fails to catch this
          condition entirely: the EOP could select a session which
          can't be used (ie, if the SSH library has lost or dropped
          the session but the application hasn't yet been made aware
          of it).  Once selected the SSHTM assumes the session is
          valid and never does error checking on whether the message
          could actually be sent over it.
    
          I've made the snmpTlstmSessionNoSessions be returned if
          the error-route is selected.
    
  + ANSWERED what does an undefined tmSessionID look like? 
    + WH: that's implementation dependent as the format of the
      sessionID is implementation dependent.
    
  + DONE Quoting: 
    4)  If tmSessionID is undefined, then use
        tmTransportAddress, tmSecurityName and
        tmRequestedSecurityLevel to see if there is a
        corresponding entry in the LCD suitable to send the
        message over.

        + WH: I've added tmTransportDomain
    
  + ANSWERED Quoting: 
    
    I am not sure what type of message buffering you refer to
    here. How will you get redundant openSession() calls?
    
    + WH: in a threaded application, for example, or even a
      socket based application it is entirely possible for a
      management application to issue multiple command generator
      messages to be sent to the same destination before the TLS
      processing of a session has completed.  Buffering these
      for the same session would be wise.
    
  + DONE In 5592, if openSession fails, the tmtateReference 
    being created is also discarded. Should it be discarded
    here?
    
    + WH: discard note added.
    
* DONE Section 5.3.  Establishing a Session 
  
  + DONE Quoting: 
    The TLS Transport Model provides the following primitive
    to establish a new (D)TLS session (previously discussed
    in Section 5.3):
    
              I don't think this was previously discussed in section
              5.3, since we just entered section 5.3.
    
              + WH: good point.  huh.
    
  + DONE "This MAY be done automatically" - you explicitly 
    exampt Report and Response messages. rfc5590 deliberately
    did not sayt these OK, these not, but used "applications
    that initiate, such as" because SNMPv3 is designed to allow
    new applications to be developed in the future.
    + WH: changed to "This MAY be done automatically for an SNMP
      application that initiates a transaction, such as a
      command generator, a notification originator, or a proxy
      forwarder." which matches 5592 better.

  + WONTDO I am conmcerned to see the selection of cyphersuites 
    discussed in the Elements of Procedure. This is something
    that I think should be out of scope for an ISMS document. We
    are supposed to be using the existing underlying secure
    transport, without the TM having any knowldege of the
    details of the security. Which cyphersuites get used should
    be configured for the TLS layer, and the TM EOP should be
    blissfully unaware of this TLS-layer configuration. If the
    TM needs to be pre-configured with a list of the acceptable
    certificates and ciphersuites, then this TM misses the point
    of ISMS.
    + WH: We don't talk about select of ciphersuites other than
      mentioning that it has to happen and mentioning where in
      the process it happens.  We make no statements about good
      vs bad, priority ordering, policy selection knobs, etc.
      All we say is you have to do it at this point in the
      process and that the selection comes from
      implementation-specific configuration because *we're not*
      doing it.
    
  + WONTDO I think trying to support multiple security levels is a 
    mistake. If you don't want security, don't use a secure
    transport. Duh! We have multiple security level support in
    USM. I am unaware that anybody actually uses multiple
    securitylevels in the real world, except for very specific
    things like auto-discovery. You don't need that supported in
    every TM. We don't support it in SSHTM, and we don't need it
    here. Let's not add complexity for the sake of adding
    complexity. Nobody NEEDS this.
    
    Implementations can choose to supplement the standard with
    as much complxiety as their customers demand, but we don't
    need that complexity turned into a MUST-implement
    requirement of the standard. The standard should be simple
    enough to encourage implementers to implement a standard
    baseline to achieve interoperability. Stop adding
    unnecessary complexity.
    
    + WH: I'm more than sure real world users are not using
      encryption in USM because they don't need it and don't
      want the hit.  I many users of my SNMP stack that don't
      want encryption turned on all the time.  I know this is
      also true for IPsec and likely for TLS (though I'm less
      familiar with other TLS protocols and their deployed
      usage).  The positives far outweigh the minor complexity
      added.

  + WONTDO Quoting: 
    - "tlstmSessionOpenErrors is incremented, an error indication
       is returned, and processing stops.  If the session failed
       to open because the presented server certificate was
       unknown or invalid then the
       tlstmSessionUnknownServerCertificate or
       tlstmSessionInvalidServerCertificates MUST be incremented
       and a tlstmServerCertificateUnknown or
       tlstmServerInvalidCertificate notification SHOULD be sent
       as appropriate.  Reasons for server certificate
       invalidation includes, but is not limited to,
       cryptographic validation failures and an unexpected
       presented certificate identity."
    
    "includes but is not limoted to"? So different
    implementations are allowed to choose which conditions they
    want to count in their counter? So how do you compare these
    across implementations? Where is the interoperability? How
    can an operator use this information effectively if the
    implementation can choose what gets counted? A standard
    should be CLEAR and UNAMBIGUOUS.
    
    Again, I think you are getting way too detailed in the
    knowledge of the TLS implementation.
    
    + WH: As stated previously, we can't enumerate every
      possible case why a TLS stack may not be able to open a
      session.  That doesn't make the counter not valuable.  We
      label the common cases but it's well beyond our scope to
      do error accounting of the (D)TLS protocols (which may
      even change).  I think we strike a good balance of being
      on the line between too much and too little.  We don't say
      how TLS works internally, but we acknowledge that it uses
      cryptography and can generate errors associated with it.
    
  + ANSWERED step a) requires preconfiguration. Did I miss something? Is 
    this no longer the ISMS WG, which was trying to minimize or
    eliminate preconfiguration for SNMP-specific credentials and
    parameters, and just use what was already available from the
    lower layer secure transport? Complexity, complexity,
    complexity.
    + WH: You didn't miss anything.  SSH requires
      pre-configuration too.
    
  + DONE Quoting: 
    "b) The (D)TLS client side of the connection MUST verify
    that authenticated identity of the (D)TLS server's
    certificate is the certificate."
    
    I'm not sure I understand what this says. "is the certificate"? what
    certificate? The one we're checking? 
    
    + WH: Thanks for catching the editing mistake.  It should
      have been the "expected certificate" (in the same way that
      SSH has a known_hosts file to ensure the SSH server's
      presented certificate is the expected one).  I've added
      "presented" as well as "expected" to make the sentence
      clearer.
    
  + WONTDO s/determine the if the presented identity matches the/???/ 
    + WH: ???s aren't a good replacement in that sentence; It
      makes sense to me as is and you don't describe how you're
      confused so it's hard to fix your issue with it.
    
  + DONE Quoting: 
    "4)  The (D)TLS-specific session identifier is passed to the TLS
        Transport Model and associated with the tmStateReference
        cache entry to indicate that the session has been
        established successfully and to point to a specific
        (D)TLS session for future use."
    
    does this mean "set the sessionID in the tmStateReference
    cache to the session identifier passed to tlstm from TLS?
    
    + WH: Yes and good point.  I've stated this more clearly
      directly now: "The (D)TLS-specific session identifier is set in the
      sessionID of the tmStateReference passed to the TLS
      Transport Model to indicate that the session has been
      established successfully and to point to a specific (D)TLS
      session for future use."

  + ANSWERED Quoting: 
    "Servers that wish to support multiple principals at a
    particular port"
    
    Does this really have to be part of TLSTM? We are defining a
    standard baseline for interoperability. Why we do we even
    need to know if the implementers choose to support some
    additional complexity in the TLS layer?
    
    + WH: It's important that we define the way two
      implementations should interact.  Some people believe
      (myself included) that receiving notifications sent to
      multiple recipients at a notification receiver is an
      important problem to solve, and this paragraph specifies
      how it SHOULD be done.
    
  + DONE In SSHTM, we have a sessionscloses counter; is ti 
    deliberate that we don't bother to increment one for closed
    tls sessions?
    
    + WH: I've added an incrementation of the snmpTlstmSessionCloses
      counter.  Return question: What was the rational for
      incrementing the counter even in a failure case (ie, no
      session exists)?  Seems kinda odd, though I duplicated it
      to remain consistent.
    
  + DONE In SSHTM, closing a session only requires the sessionID 
    from the tmStateReference; In TLSTM, you pass in a whole
    tmStateReference. Is this really necessary?
    
    + WH: I've changed it so that only a tmSessionID is passed.