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

[Wes Hardaker <[e-mail]>]

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