From: OPSAWG <[email protected]> on behalf of Kenneth Vaughn
<[email protected]>
Sent: 05 May 2022 19:19
I have no real problem either way; unless I hear someone else argue for making
it automatic in the next couple of days, I will delete the last two sentences
of the first paragraph of the IANA Considerations so that it will read:
This document requires the establishment of a new SNMP-TLSTM HashAlgorithm
Registry, which is referenced in the above MIB as being located at
"http://www.iana.org/assignments/tlstm-parameters/";. The initial values for
this table MUST be identical to the contents of the TLS HashAlgorithm Registry
(RFC 5246).
While future additions to the IANA TLS HashAlgorithm Registry are not expected,
any future addition to the IANA TLS HashAlgorithm Registry MUST be consistent
with the values assigned in the proposed IANA SNMP-TLSTM HashAlgorithm Registry.
<tp>
Problem one; the IANA website is a mess because IANA do what they are told:-(
This makes data difficult or impossible to find. The RFC on IANA now calls for
a two part structure of group and registry. Here a group exists for SMI and
that is where anyone should expect to find this registry so the instructions
should then ask for the creation of a algorithm registry in the
Structure of Management Information (SMI) Numbers (MIB Module Registrations)
Group (alongside such as
SMI Security for Cryptographic Algorithms).
You have already seen how familiar security experts are with the abbreviation
TLSTM.
Problem two; the registry you suggest for initial values includes MD5. If that
gets past IESG then it is time to abandon any pretence of security. I think
that only four values are currently appropriate.
Problem three; a registry needs an update policy. Expert Review might be
suitable. It is up to IANA and the IESG to find experts, not us.
Tom Petch
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]<mailto:[email protected]>
www.trevilon.com<http://www.trevilon.com>
On May 5, 2022, at 11:31 AM, Jürgen Schönwälder
<[email protected]<mailto:[email protected]>>
wrote:
We made the mistake by simply reusing the TLS hash algorithm for a
different purpose. We now factor things out by having a separate
registry for the hashing algorithms used to create certficate
fingerprints. But why would we now tie this back to TLS hashing
algorithms? In modern TLS, I think they only register entire
ciphersuites, do we really expect them to go an register any new hash
algorithm that comes along into the registry of hash algorithms for
producing certificate fingerprints?
I understand the "we are too lazy to do this" argument but then still
I would expect that if a new hash is being implemented for certificate
fingerprinting, someone would find the energy to register it.
/js
On Thu, May 05, 2022 at 11:15:46AM -0500, Kenneth Vaughn wrote:
There is no definition of TLSTMv1.3 nor do we version MIB modules
Agreed, This is old text that I missed from when this was intended to be a
replacement to RFC 6353 rather than an update. I think it is best to just
delete the sentence so the paragraph would now read "[RFC6353] stated 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." While the statement
is not technically required as it is stated elsewhere, I believe there was a
comment during IETF 113 that we should be explicit about this.
In addition, a new entry
MUST be added to the SNMP-TLSTM HashAlgorithm Registry every time a
new hash algorithm is approved for any version of TLS or DTLS.
I guess there are two issues here: 1) What do we want and 2) What wording is
used for IANA instructions
In the first case, while I accept that there is not a strict technical
requirement to implement every hash algorithm adopted by TLS, I am hard pressed
to think of why we would ever not want to support one (or what practical harm
it would cause). If we don't make the cross-assignment automatic, it seems as
if it would be incumbent upon the WG to explicitly make requests every time a
new hash algorithm came along. That seems to be extra bureaucratic work for
OPSAWG and it seems as if it would be easier to make it a part of the IANA
process. So the proposal is that it should be automatic (which is in agreement
with a comment made at the IETF 113 meeting)
If we agree that it should be automatic, then the second issue is how do we
state this. I am happy to revise the wording as appropriate; I certainly am not
an expert in writing those statements.
If we don't want it to be automatic, then perhaps we need to reach consensus on
how new entries will be added.
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]<mailto:[email protected]>
www.trevilon.com
On May 5, 2022, at 10:32 AM, Jürgen Schönwälder
<[email protected]> wrote:
Before I go and check the details...
[...] TLSTMv1.3 MUST only be used with
(D)TLS version 1.2 and later.
What does this MUST tell me? There is no definition of TLSTMv1.3 nor
do we version MIB modules. I understand the intention of the statement
but we need to be more careful about the wording.
And what about this:
[...] In addition, a new entry
MUST be added to the SNMP-TLSTM HashAlgorithm Registry every time a
new hash algorithm is approved for any version of TLS or DTLS.
Why would that be a MUST? The SnmpTLSFingerprint is used by the MIB
module to hash certificates and as such this hashing has nothing to do
with any TLS internal use of hash algorithms. The reuse of the TLS
hash registry back then was a matter of convenience, not a matter of
having a strong binding to the TLS internal usage of hash algorithms.
/js
On Thu, May 05, 2022 at 10:09:45AM -0500, Kenneth Vaughn wrote:
I have uploaded a new version of the "Updates to the TLS Transport Model for
SNMP". This version includes the following changes:
Changed the name of the registry to the SNMP-TLSTM registry
Updated reference to DTLS 1.3 to reflect the publication of RFC 9147
Clarified the first paragraph of Conventions to indicate that references to
TLS, DTLS, (D)TLS, and TLSTM are version neutral except where specific versions
need to be cited.
Changed "SNMPv3" to "SNMP" in several locations where the specific version
reference was unnecessary with our convention statement
Indicated that Additional Rules for TLS 1.3 "may additionally apply to future
versions of TLS"
The document has been through several review cycles and has also been vetted by
the TLS WG. At this point, changes are primarily editorial and I believe it is
stable enough to proceed to the next step of the approval process.
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
On May 5, 2022, at 10:07 AM, [email protected] wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working Group
WG of the IETF.
Title : Updates to the TLS Transport Model for SNMP
Author : Kenneth Vaughn
Filename : draft-ietf-opsawg-tlstm-update-03.txt
Pages : 30
Date : 2022-05-05
Abstract:
This document updates the TLS Transport Model (TLSTM), as defined in
RFC 6353, to reflect changes necessary to support Transport Layer
Security Version 1.3 (TLS 1.3) and Datagram Transport Layer Security
Version 1.3 (DTLS 1.3), which are jointly known as "(D)TLS 1.3".
This document is compatible with (D)TLS 1.2 and is intended to be
compatible with future versions of SNMP and (D)TLS.
This document updates the SNMP-TLS-TM-MIB as defined in RFC 6353.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tlstm-update/
There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-opsawg-tlstm-update-03.html
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-tlstm-update-03
Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
--
Jürgen Schönwälder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
--
Jürgen Schönwälder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
