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

["David Harrington" <[e-mail]>]

Re: sessions

    These parts should probably explicitly say that the concept
    of "session" here is totally unrelated to TLS sessions in
    RFC 5246 (which are TLS-internal optimization detail not
    visible to TLSTM). But the name "tlsSessionID" is very
    poorly chosen, since it's very different from the TLS
    SessionID in RFC 5246.
    + WH: How does tlsSnmpSessionID sound?  I've changed it to this.

SNMP does not have sessions. RFC5590 says:

   The architecture defined in [RFC3411] and the Transport Subsystem
   defined in this document do not support SNMP sessions or include a
   session selector in the Abstract Service Interfaces.

   The Transport Subsystem might support transport sessions.  [...]

  However, because the handling of transport sessions is specific to
   each Transport Model, some Transport Models MAY restrict selecting
a
   particular transport session.  [...]

   Implementations SHOULD be able to maintain some reasonable number
of
   concurrent transport sessions, [...]

and from RFC5591:

   The Transport Security Model does not work with transport sessions
   directly.  Instead the transport-related state is associated with a
   unique combination of transportDomain, transportAddress,
   securityName, and securityLevel, and is referenced via the
   tmStateReference parameter.  How and if this is mapped to a
   particular transport or channel is the responsibility of the
   Transport Subsystem.

So any session ID here is specific to the TLS Transport Model
Ergo, I recommend tlstmSessionID.

dbh

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Wes Hardaker
> Sent: Tuesday, December 08, 2009 7:19 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [Isms] wg last call on the (d)tls transport model
> 
> >>>>> On Fri, 6 Nov 2009 12:15:14 +0100, <[e-mail]>
said:
> 
> PE> Some random comments scribbled on printout during my 
> flight earlier
> PE> today (or yesterday, depending on your point of view :-):
> 
> Pasi,
> 
> 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
> 
> 
> * DONE Technical 
>   + DONE How the notification originator authenticates the 
> other end (TLS 
>     server) when fingerprints are not used is very unclear (the
>     fingerprint case is clear). Section 5.3, step 3b, 
> suggests we could
>     use path validation, but it doesn't e.g. say what the "reference
>     identity" (in draft-saintandre-tls-server-id-check 
> terminology) would
>     be. Perhaps the MIB should allow specifying that 
> reference identity.
>     (MIB, tlstmAddrTable, is relevant here.)
>     
>     + WH: This was discussed in a past WG meeting and it was
>       determined that it was out of scope to establish X.509
>       path validation management.  So that's left up to possible
>       future work, possibly within the PKIX or other working
>       group that wants to take on creating an X.509 TA MIB.  I
>       will state this fact more clearly and make sure it's
>       declared as implementation dependent.
>     
>     + WH: I've reworded the section to make it much clearer about
>       exactly what must be done.  See if the new wording fixes
>       your issues.
>     
>   + DONE (I guess this applies to command generators, too, to 
> some degree 
>     at least -- they also act as TLS clients, and have to
authenticate
>     the server somehow.)
>     + WH: correct...  They're in the same boat.  If there is no
>       fingerprint for outgoing connections it's expected they do
>       path validation through another out-of-scope process.
>       
>   + DONE While TLS supports several different authentication 
>     mechanism (X.509 certs, OpenPGP certs, pre-shared keys,
>     Kerberos, SRP, ...), TLSTM supports only one of them (X.509
>     certs). This should be mentioned in e.g. Section 1 and Section
>     4.1.
>     + WH: I've added sentences to both those locations stating that
>       other authentication forms are outside the scope of this
>       specification.
>     
>   + DONE Section 1.1, 2nd to last paragraph, and Section 3.1.3: 
>     These parts should probably explicitly say that the concept
>     of "session" here is totally unrelated to TLS sessions in
>     RFC 5246 (which are TLS-internal optimization detail not
>     visible to TLSTM). But the name "tlsSessionID" is very
>     poorly chosen, since it's very different from the TLS
>     SessionID in RFC 5246.
>     + WH: How does tlsSnmpSessionID sound?  I've changed it to this.
>     + WH: Note that I think it's possible to use the same sessionID
>       for both uses.  It gets a bit more trick after
>       renegotiation though since the SNMP session ID can't
>       change.  I've added text describing this potential conflict.
>     
>   + DONE Section 5.3 (last para) and Section 8.2: (D)TLS does 
> have the 
>     "server_name" extension that does allow doing this.
>     + WH: Added a reference to RFC4366.
>       
>   + DONE MIB, Snmp*Address TCs: do we need four pages worth 
> of new TCs 
>     to just describe (IPv4 address/IPv6 address/hostname)+port? 
>     Surely many existing MIBs use address+port, too, and we could
>     import from somewhere?
>     + WH: per discussion at IETF, I've changed this so it's a single
>       address TC now and the 3 Domains all use it.
>     
>   + DONE MIB, Fingerprint TC, last paragraph: this is not really 
>     consistent with how certificate fingerprints are used in many
>     other protocols -- usually we compare just the fingerprint
>     (not the whole certificate), and assume it's produced by a
>     good hash function.
>     + WH: Per IETF discussion I've made it so that fingerprints can
>       be used as the method of comparison.  (Originally the text
>       was actually written to allow for "cheap" referencing
>       methods (beyond just hash fingerprints)).
>     
>   + DONE MIB, tlstmCertToSNSANType: is SecurityName case 
> sensitive?  If it 
>     is, you need to specify the case for IPv6 address, and probably
>     normalize the dNSName and domain part of rfc822name 
> (e.g., convert to
>     lower case).
>     + WH: Modified per discussion results during the IETF meeting.
>     
>   + DONE MIB, tlstmCertToSNSANType: how would othername be 
> converted to 
>     SnmpAdminString? (which is UTF-8, so "take the raw DER" 
> does not work,
>     and it would be very administator-unfriendly, too)
>     + WH: As per discussion from the IETF, we're no longer directly
>       defining otherName mappings but do have an extensible OID
>       selection mechanism so future documents can define an
>       otherName mapping.
>     
>   + DONE Sections 3.3 and others: the document has snmpTLSDomain, 
>     snmpDTLSUDPDomain and snmpDTLSSCTPDomain. Probably for 
> consistency,
>     the first should be snmpTLSTCPDomain, since SCTP would 
> also normally
>     use TLS, not DTLS (there's a draft proposing how to run DTLS
over
>     SCTP, but it's just work in progress, not something that 
> can be done
>     today).
>     + WH: Ok, I've changed it.
>     
>   + DONE Section 2.1: if the CG/NO is always the (D)TLS 
> client, and it MUST 
>     be authenticated (2nd bullet), then why is authenticating 
> the client
>     only SHOULD? (1st bullet)
>     + WH: Because I changed one from a SHOULD to a MUST and missed
the
>       second.  Thanks for the catch.  I also cleaned up the wording
a
>       bit more to make it clearer.
>     
>   + DONE The openSession ASI in Section 4.4.1 looks very different 
>     from the SSHTM ASI -- is this intentional?
>     + WH: The SSH document changed from the point where that text
>       was copied and I didn't catch it.  I've realigned the
>       document to the published RFC.
>     
>   + DONE Section 4.4.1: "this restriction is not needed for 
> TLS or DTLS over 
>     SCTP": this restriction is present in TLS-over-TCP/SCTP, too,
but
>     TCP/SCTP take care of ensuring that <src IP, src port, 
> dst IP, dst port>
>     is unique.
>     + WH: That section was actually dropped as it was TLS specific
>       ASIs and is no longer included with the document.
>     
>   + DONE Section 4.4.2 and 4.4.3: I think these sections should be 
>     just deleted -- these are TLS internal details. Furthermore,
>     for normal TLS (or DTLS, when a single datagram contains
>     multiple DTLS records), TLSTM cannot even determine
>     "wholeTlsMsgLength", since that would require parsing the TLS
>     messages (which would be a layering violation).
>     + WH: I agree and per discussion during the WG meeting, I've
>       removed them.
>     
>   + DONE Section 5.1.1 is also a bit questionable; it also seems to 
>     suggest parsing DTLS records by TLSTM. And the details aren't
>     quite right: the same demultiplexing (mapping incoming UDP
>     packet, based on <src IP,src port,dst IP, dst port> tuple, to
>     the right DTLS connection/context) has to happen for DTLS
>     handshake messages, too, not just DTLS application data
>     messages.
>     + WH: Per discussion at the IETF I've simplified it quite a bit
>       so it still discusses demultiplexing within UDP but
>       doesn't talk about (D)TLS specific packet types.  See if
>       the new text looks better to you.
>     
>   + DONE Section 8.1, 1st paragraph: the last sentence of this 
>     paragraph is very confusing, since the sessions this document
>     talks about are totally unrelated to TLS sessions (and TLS
>     session resumption).  Besides, all TLS implementations support
>     session resumption, so this SHOULD is not really needed in
>     this document.
>     + WH: I've dropped the sentence
>     
>   + DONE Section 8.1, 2nd paragraph: Separate ports might be a 
>     reasonable idea, but I don't understand what the rest of the
>     paragraph is saying...
>     + WH: It's discussing SNMP specific message types.  But I agree
>       it's not needed.  Not only that, we're asking for separate
>       ports from IANA anyway.  So...  I've deleted the whole
>       paragraph as I don't think any of it is necessary.
>     
>   + DONE Section 10: SSHTM uses ports >1023 -- should be good enough

>     for TLSTM, too (the criteria for allocating ports <1023 is
>     much stricter).
>     + WH: I don't mind something higher and at the WG meeting
>       everyone agreed.  Changed.
>     
>   + DONE In normal SNMP-over-UDP, if e.g. the notification receiver 
>     restarts, that's not a problem: at least if the notification
>     generator didn't send anything exactly when the restart was
>     ongoing, everything will continue just fine after the restart.
>     
>     But when using DTLS-over-UDP, if the notification receiver
>     restarts, the notification generator has to know that it needs
>     to start a new DTLS "connection" (because otherwise the
>     receiver will just silently drop all the packets it gets). The
>     same problem has been discussed for syslog-over-DTLS recently,
>     and draft-seggelmann-tls-dtls-heartbeat proposes one possible
>     solution.
>     
>     In SNMP most requests result in a response, so if no 
> response is seen,
>     *some* component will know there's something wrong. But 
> since TLSTM
>     isn't supposed to know about PDU types, it might be 
> architecturally
>     slightly tricky how opening a new DTLS "connection" 
> should be triggered
>     here. But the document should probably say something 
> about this issue.
>     
>     + WH: Per discussion in the WG meeting text was added to
>       reference the heartbeat work and to recommend that users
>       implement a dead-peer detection mechanism.
>     
>   + DONE Should the document say something about MTU/avoiding 
> fragmentation 
>     for DTLS-over-UDP?
>     + WH: I added a paragraph in the operational considerations
>       section that functionally says we can't summarize all
>       those problems but readers should be aware of them.  I
>       think if we dove down into it in depth it would amount to
>       pages of discussions about the ramifications of each
>       selection choice.
>     
>   + DONE DTLS allows multiple DTLS records in a single 
> datagram -- should 
>     the document say something about this?
>     + WH: I've added some text describing this during the incoming
>       processing EOPs.
>     
>   + DONE Should the document say something about SCTP Partial 
> Reliability, 
>     or use of SCTP streams?
>     + WH: I think this falls into the text already added for
>       "understand what's beneath you" in the operational
>       considerations.
>     
> * DONE Minor editorial comments: 
>   
>   + DONE The document title should have the acronym "TLS" in it. 
>     + WH: Added
>     
>   + DONE Section 4.1.1: While the actual details of how self-signed 
>     certificates can be used in TLSTM (in the rest of the spec) look
>     mostly OK, I would recommend against using the term 
> "trust anchor" to
>     refer to self-signed end-entity certificates.
>     + WH: You're right it's another over-used term and is confusing
>       depending on your definition of it (some use it as the
>       keying material, but 5280 seems to declare it the entity
>       producing the keying material)... How does this sound:
>     
>       "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."
>     
>   + DONE Section 3.1.1, item 4, 2nd paragraph: this is quite 
> unclear, and goes 
>     into details that are IMHO not relevant for TLSTM. 
> Perhaps something
>     like "Most TLS cipher suites do encryption" ?
>     + I removed the offending text and shortened it so that it
really
>       says "(D)TLS" supports encryption.
> 
>   + DONE Section 3.1.1, item 5,: the sentence about 
> "amplification" is quite 
>     unclear; the main purpose of DTLS cookie exchange is to limit
>     server-side resource consumption, not amplification (and 
> "detecting"
>     amplification could be tricky).
>     + WH: You're absolutely right about this.  I'm surprised 
> no one (myself
>       included) has caught this before.  Thanks for pointing it
>       out.  I've changed it to:
>     
>       "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."
>     
>   + DONE Section 3.1.2: This text should probably mention that TLS 
>     does not have any NULL integrity cipher suites.
>     + WH: I tried to clean this up a bit, but I'm not sure it should
>       be our job to describe what TLS has and what it doesn't.
>       (There is nothing prohibiting one from being created in the
>       future, EG.)
>     
>   + DONE MIB, tlstmParamsEntry: should "usable" be "unusable"? 
>     + WH: Yep; Juergen caught this too.
>     
>   + WONTDO Section 9, "DTLS is more vulnerable to denial of 
> service attacks". 
>     Well, a hypothetical version of DTLS that didn't include 
> the cookie
>     exchange might be more vulnerable, but since we don't have such
>     a version, this isn't really true.
>     + WH: I think the text following that statement functionally
says
>       just this so I don't think any changes are needed.  The
>       paragraph is really there to remind users that they need to
>       use cookies.
>   + DONE Global: s/US-US-ASCII/US-ASCII/; 
>     + WH: Whoops; that was a search-and-replace gone awry
> 
>   + DONE The reference [x509] looks wrong. 
>     + WH: I think that was originally a reference to RSA which I
>       removed long ago.  I've changed it to reference the ITU doc.
>     
>   + WONTDO Appendix A and B: I would suggest deleting these. 
>     + WH: The WG decided that these contained useful information but
>       should move to an appendix.
>     
>   + DONE Appendix C: "blueberry" is not a valid rfc822Name 
>     ("[e-mail]" would be)
>     + WH: changed
> 
> -- 
> Wes Hardaker
> Cobham Analytic Solutions
> _______________________________________________
> Isms mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isms
>