To OPSAWG, especially MIB doctors and SNMP-experts:
We have contacted the TLS community about potentially allowing for the
continued use and maintenance of the IANA TLS HashAlgorithm Registry (RFC 5246)
in the update to RFC 6353 so that we do not have to redefine its fingerprint
algorithm. The TLS community expressed a valid concern that if the registry is
maintained by adding new values, it would imply that those new values could be
used within TLS 1.2; thus our proposal to continue to reference the existing
table was not accepted.
We now have two potential options as follows:
1. Deprecate and replace the existing fingerprint algorithm with a new one. The
fingerprint algorithm is used in the index of most of the tables within the RFC
6353 MIB; as a result, deprecating the fingerprint algorithm requires
deprecating the assocaited tables; in practice, this results in redefining the
entire MIB in RFC 6353.
2. Revise the DESCRIPTION clause of SnmpTLSFingerprint to refer to a new,
parallel HashAlgorithm Registry. Specifically, we would replace the second
paragraph of its DESCRIPTION clause, which currently reads:
> An SnmpTLSFingerprint value is composed of a 1-octet hashing algorithm
> identifier followed by the fingerprint value. The octet value encoded is
> taken from the IANA TLS HashAlgorithm Registry (RFC 5246). The remaining
> octets are filled using the results of the hashing algorithm.
To something like the following:
> An SnmpTLSFingerprint value is composed of a 1-octet hashing algorithm
> identifier followed by the fingerprint value. The octet 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 SnmpTLSFingerprintAlgorithm 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.
While option 2 greatly simplifies the update, the question is whether this can
be considered a valid revision to the MIB. Per RFC 2578 Section 10, the
DESCRIPTION clause can only be updated with "clarifications and additional
information ... Otherwise, if the semantics of any previously defined object
are changed (i.e., if a non-editorial change is made to any clause other than
those specifically allowed above), then the OBJECT IDENTIFIER value associated
with that object must also be changed."
So our question to the group is "Does option 2 qualify as a valid
"clarification and additional information" or are we forced into option 1?".
Option 1 would require a complete replacement MIB with corresponding impacts to
existing code to support the new TLS version, so I believe Option 2 would be
preferred, if allowed.
Regards,
Ken Vaughn
Trevilon LLC
6606 FM 1488 RD #148-503
Magnolia, TX 77354
+1-936-647-1910
+1-571-331-5670 cell
[email protected]
www.trevilon.com
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
