Hi Kevin,
Sorry for the delay. Here are my AD review comments for
draft-ietf-opsawg-tlstm-update-10. All my comments are pretty minor. Please
let me know if you have any questions/comments, or otherwise can just post an
updated version which I can then send off for IETF LC.
Minor level comments:
(1) p 4, sec 2.3. TLS Version
[RFC6353] states that TLSTM clients and servers MUST NOT request,
offer, or use SSL 2.0. [RFC8996] prohibits the use of (D)TLS
versions prior to version 1.2. TLSTMv1.3 MUST only be used with
(D)TLS version 1.2 and later.
It wasn't clear to me exactly what is meant by TLSTMv1.3, and this is the only
use of this term. Could you be more specific here please?
(2) p 6, sec 4. MIB Module Definition
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info)."
Please add the RFC 2119 boilerplate text to this MIB. E.g.,
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
(3) p 9, sec 4. MIB Module Definition
An SnmpTLSFingerprint value is composed of a 1-octet hashing
algorithm identifier followed by the fingerprint value. The
1-octet identifier value encoded is based on the IANA TLS
HashAlgorithm Registry (RFC 5246); however, this registry is
only applicable to (D)TLS protocol versions prior to 1.3,
which are now designated as obsolete and are not expected to
ever support additional values. To allow the fingerprint
algorithm to support additional hashing algorithms that might
be used by later versions of (D)TLS, the octet value encoded
is taken from IANA SNMP-TLSTM HashAlgorithm Registry. The
initial values within this registry are identical to the
values in the TLS HashAlgorithm registry but can be extended
to support new hashing algorithms as needed. The remaining
octets of the SnmpTLSFingerprint value are filled using the
results of the hashing algorithm.
This description somewhat mixes the definition of what the field is, along with
some historical context. Hence, I suggest that it might be helpful to split
the description between what the field is now vs how is was derived. E.g.,
perhaps something like:
An SnmpTLSFingerprint value is composed of a 1-octet hashing
algorithm identifier followed by the fingerprint value:
The 1-octet identifier value encoded is taken from the
IANA SNMP-TLSTM HashAlgorithm Registry.
The remaining octets of the SnmpTLSFingerprint value are
filled using the results of the hashing algorithm.
Historically, this field was based on the IANA TLS
HashAlgorithm Registry (RFC 5246); however, this registry is
only applicable to (D)TLS protocol versions prior to 1.3,
which are now designated as obsolete and are not expected to
ever support additional values. To allow the fingerprint
algorithm to support additional hashing algorithms that might
be used by later versions of (D)TLS, the octet value encoded
is now taken from IANA SNMP-TLSTM HashAlgorithm Registry. The
initial values within this registry are identical to the
values in the TLS HashAlgorithm registry but can be extended
to support new hashing algorithms as needed. The remaining
octets of the SnmpTLSFingerprint value are filled using the
results of the hashing algorithm.
It also wasn't clear to me whether there is a restriction that only versions of
(D)TLS greater than 1.3 may use an algorithm value greater than 8, and whether
that restriction must be stated here.
Nit level comments:
(4) p 8, sec 4. MIB Module Definition
Values of this textual convention are not guaranteed to be
directly usable as transport layer addressing information,
potenitally requiring additional processing, such as run-time
resolution. As such, applications that write them MUST be
prepared for handling errors if such values are not
supported, or cannot be resolved (if resolution occurs at the
time of the management operation).
Typo, potenitally -> potentially
(5) p 15, sec 4. MIB Module Definition
certificate, then additional rows MUST be searched looking
Extra line break in the description above?
(6) p 27, sec 5. Security Considerations
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example, by using IPsec),
even then, there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the objects
in this MIB module.
Suggest eliding the "even then" since the sentence starts with "Even ..."
(7) p 31, sec 8.2. Informative References
Kenneth Vaughn (editor)
Trevilon LLC
1060 Highway 107 South
Del Rio, TN 37727
United States of America
Phone: +1 571 331 5670
Email: kvau...@trevilon.com
Grammar nits from an automated tool:
Grammar Warnings:
Section: 3.2, draft text:
This document does not specify an application profile, hence all of the
compliance requirements in [RFC8446] apply.
Warning: Consider using all the.
Suggested change: "all the"
Section: 6, draft text:
IANA is asked to create a new registry called the SNMP-TLSTM HashAlgorithm
Registry in the Structure of Management Information (SMI) Numbers (MIB Module
Registrations) Group and to update the proposed URL reference in the above MIB
( listed as "https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml";
under SnmpTLSFingerprint), if needed, to accurately reflect its location.
Warning: Don't put a space after the opening parenthesis.
Suggested change: "("
Regards,
Rob
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
