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

[<[e-mail]>]

Some random comments scribbled on printout during my flight earlier
today (or yesterday, depending on your point of view :-):

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

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

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

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

- Section 5.3 (last para) and Section 8.2: (D)TLS does have the
"server_name" extension that does allow doing this.

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

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

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

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

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

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

- The openSession ASI in Section 4.4.1 looks very different
from the SSHTM ASI -- is this intentional?

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

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

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.

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

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

- Section 10: SSHTM uses ports >1023 -- should be good enough for
TLSTM, too (the criteria for allocating ports <1023 is much stricter).

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

- Should the document say something about MTU/avoiding fragmentation
for DTLS-over-UDP?

- DTLS allows multiple DTLS records in a single datagram -- should
the document say something about this?

- Should the document say something about SCTP Partial Reliability,
or use of SCTP streams?

Minor editorial comments:

- The document title should have the acronym "TLS" in it.

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

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

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

- Section 3.1.2: This text should probably mention that TLS 
does not have any NULL integrity cipher suites.

- MIB, tlstmParamsEntry: should "usable" be "unusable"?

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

- Global: s/US-US-ASCII/US-ASCII/;

- The reference [x509] looks wrong.

- Appendix A and B: I would suggest deleting these. 

- Appendix C: "blueberry" is not a valid rfc822Name
("[e-mail]" would be)

Best regards,
Pasi