Updates to the TLS Transport Model for SNMP
draft-ietf-opsawg-tlstm-update-15

Received changes through RFC Editor sync (created alias RFC 9456, changed abstract to 'This document updates RFC 6353 ("Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)") 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.', changed pages to 30, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2023-11-08, changed IESG state to RFC Published, created updates relation between draft-ietf-opsawg-tlstm-update and RFC 6353)

IANA state will be changed back to "IANA OK" after the IANA Considerations has been updated to include a new "Description" field for the registry to be created at https://www.iana.org/assignments/smi-numbers. This field is being discussed.

[Ballot discuss]
Thanks for this document update. I have a minor DISCUSS that should be easy to resolve, and some comments.

Should Section 2.3 or the Security Considerations not reference RFC 9325
"Recommendations for Secure Use of Transport Layer Security (TLS) and
Datagram Transport Layer Security (DTLS)" ? For one thing, it documents
that if one needs to still use TLS 1.2, what options should be used or avoided.

[Ballot comment]
        REVISION    "202209090000Z"
        DESCRIPTION "This version of this MIB module is part of
                RFC XXXX; see the RFC itself for full legal
                notices.  This version:


It will be easy to miss this "RFC XXXX" for the RFC Editor, can be make a clearer note
for the RFC editor to update that?

The REVISION is a date. Should that be updated to the publication date, or is it used
as a sort of early code point ?


        Historically, the 1-octet hashing algorithm identifier 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.

I'm not sure "obsolete" is the right word?

Also, looking at:

https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-18
snmpTlstmCertCommonName OBJECT-IDENTITY

I don't see a note the registry is closed.

Perhaps weaken the claim to just "however, this registry is no longer in use for TLS 1.3
and above and are not expected to have any new registrations added to it."

        The policy for updates is Expert Review.

Why not specification required or RFC required?  (Or split the range, as Roman alluded to as well)

[Ballot comment]
Thank you for the work on this document.

I was going to have the same comment as Roman's first point. Additionally, and in any case, it would be good in my opinion to expand the Expert Guidelines, as the only guideline right now is "consult the security area" (and even then, it's only encouraged).

For more input about what I think should be there, RFC 8126 says it best:
  The required documentation and review criteria, giving clear guidance
  to the designated expert, should be provided when defining the
  registry.  **It is particularly important to lay out what should be
  considered when performing an evaluation and reasons for rejecting a
  request.**  It is also a good idea to include, when possible, a sense
  of whether many registrations are expected over time, or if the
  registry is expected to be updated infrequently or in exceptional
  circumstances only.

[Ballot comment]
Thanks for working on this specification. Special thanks for the shepherd's write-up, it was very helpful.

I was just wondering - as there is an intended impact on the future here,

  "Renegotiation of sessions is not supported as it is not supported by TLS 1.3."

what is the intended implication on the application of future versions of TLS?

[Ballot comment]
Thanks for this document. Thanks also to Joe Clarke for the detailed and helpful shepherd writeup.

I noticed one nit that I don’t think I’ve seen mentioned yet, “SMNPv3” -> “SNMPv3”.

[Ballot comment]
Thanks for this document. Thanks also to Joe Clarke for the detailed and helpful shepherd right up.

I noticed one nit that I don’t think I’ve seen mentioned yet, “SMNPv3” -> “SNMPv3”.

[Ballot comment]
** Section 6. Per the new IANA registry:

-- Is the WG sure that expert review for the entire registry is sufficient?  I’ll point out that the “TLS HashAlgorithm” from which it forked defines ranges for code points (to include standards track … expert review). 

-- I applaud the design of this registry incorporating the notion of “Recommended”.  Based on the TLS experience of using that flag, specifically Section 5 of RFC8447, does stronger guidance need to be added on the threshold for getting a “Y” and the semantics of “N”.  In RFC8847, “Recommended=Y” requires a standards track; and “Recommended=N” allows for the possibility that the proposed algorithm is not “flawed”, simply that it hasn’t been reviewed by the IETF.

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-opsawg-tlstm-update-12
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points.

Special thanks to Joe Clarke for the shepherd's detailed write-up including the WG consensus **and** the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### MIB Doctor review

Like Lars, I wonder whether there was a MIB doctor review.

### Section 3.1

This text is repeated, is it on purpose ?
```
The reason 0-RTT is disallowed is that there are no "safe" messages that if replayed will be guaranteed to cause no harm at a server side: all incoming notification or command responses are meant to be acted upon only once. See Security considerations section for further details
```

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
# GEN AD review of draft-ietf-opsawg-tlstm-update-12

CC @larseggert

Thanks to Joel Halpern for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/VI00LPj0gVfsGW_qOfw9JlGAJdE).

## Comments

### Paragraph 2
```
                Updates to the TLS Transport Model for SNMP
                    draft-ietf-opsawg-tlstm-update-12
```
Was there a mibdoctors review of this I-D? Should there be?

### Section 1, paragraph 1
```
    This document updates and clarifies how the rules of [RFC6353] apply
    when using Transport Layer Security (TLS) or Datagram Transport Layer
    Security (DTLS) versions later than 1.2.  This document jointly
    refers to these two protocols as "(D)TLS".  The update also
    incorporates the [RFC8996] update, which prohibits the use of TLS
    versions prior to TLS 1.2.
```
Should this document then not also obsolete RFC8996?

### Missing references

No reference entries found for these items, which were mentioned in the text:
`[RFC3413]`, `[RFC2579]`, `[RFC3411]`, `[RFC2578]`, and `[RFC2580]`.

### Uncited references

Document updates `RFC6353`, but does not cite it as a reference, which is a bit
odd.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Reference `[RFC5953]` to `RFC5953`, which was obsoleted by `RFC6353` (this may
be on purpose).

Reference `[RFC5246]` to `RFC5246`, which was obsoleted by `RFC8446` (this may
be on purpose).

### Grammar/style

#### Section 4, paragraph 28
```
s not specify converting to lowercase so this involves an extra step). This
                                    ^^^
```
Use a comma before "so" if it connects two independent clauses (unless they are
closely connected and short).

#### Section 4, paragraph 90
```
nd this hash value MUST match exactly or the connection MUST NOT be establis
                                    ^^^
```
Use a comma before "or" if it connects two independent clauses (unless they are
closely connected and short).

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-opsawg-tlstm-update-12. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

A new registry is to be created called the SNMP-TLSTM HashAlgorithm registry. The new registry will be located on the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry page located at:

https://www.iana.org/assignments/smi-numbers/

IANA Question --> It is not completely clear where this registry should be located on the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry page. Could the authors describe, more precisely, the exact location they would like the new registry to appear on the page?

The new registry will be managed through Expert Review as defined by RFC8126. There are initial registrations in the new registry as follows:

Value Description Recommended Reference
0 none N [RFC5246]
1 md5 N [RFC5246]
2 sha1 N [RFC5246]
3 sha224 Y [RFC5246]
4 sha256 Y [RFC5246]
5 sha384 Y [RFC5246]
6 sha512 Y [RFC5246]
7 reserved [RFC8447]
8 intrinsic N [RFC8422]
9-223 reserved [RFC8447]
224-255 private [RFC5246]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-02-20):

From: The IESG
To: IETF-Announce
CC: draft-ietf-opsawg-tlstm-update@ietf.org, jclarke@cisco.com, opsawg-chairs@ietf.org, opsawg@ietf.org, rwilton@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Updates to the TLS Transport Model for SNMP) to Proposed Standard


The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document: - 'Updates to
the TLS Transport Model for SNMP'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-02-20. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document updates RFC 6353 "Transport Layer Security (TLS)
  Transport Model for the Simple Network Management Protocol (SNMP)",
  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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tlstm-update/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

## Document History

The document was actively discussed between a number of working group individuals as well as in consultation with members of the TLS working group.  No one has expressed dissent in the work or its direction, but I would have liked to see reviews from the SEC DIR and from the broader OPS DIR.  Requests for those reviews went unanswered.

One area to pay special attention to is how new hash algorithms are allocated in the new IANA-maintained registry.  One thought was to have new algorithms auto-added based on work happening in TLS 1.3.  However, that could lead to a proliferation of algorithms in this registry that are never used.  Therefore, the current text stipulates an additional expert review and work on behalf of interested parties to propose a new hash algorithm be added (and that represents the consensus of the group).

It is also important to call out that the reason this document requests a new registry vs. adding to the existing one is that the TLS working group did not want to imply that any new algorithms added to the existing fingerprint registry worked with TLS 1.2.  Choosing this approach allowed for a much more simplified update to RFC 6353.

## Additional Reviews

The contents of this document do interact closely with TLS and thus a review from the TLS WG was requested.  Their input was key in choosing this document's current direction (see above).  However, I would have liked to have received some other directorate-level reviews to reinforce the approach in the registry is sound.

From a MIB standpoint, by taking a simplified approach, the updates were minimal.  That is, even though this document moves to a new hash algorithm registry, the semantics of the MIB and the SnmpTLSFingerprint textual convention remain the same, thus backwards compatibility is preserved.  This was confirmed by Jürgen Shönwälder.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

SEC DIR and OPS DIR should review.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.  This is the correct type based on the RFC it updates and that it defines a [modified] MIB module.  This status is correctly reflected in Datatracker.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes.  An IPR call was conducted and no IPR was reported.  The author explicitly stated he knows of no IPR.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Most IDNITS have been sorted.  However, this is still a reference to the obsolete RFC 5246, and that is intentional as we are incorporating the values from the old TLS 1.2 registry.

Also note, the references from the MIB have been added as norm/inform references (in a style similar to what is done in YANG modules), and in the case of RFC 5890, has been made normative with new language in the MIB.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

References look correct.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are freely available.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

It will update RFC 6353.  That metadata in the document is correct.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The ask of IANA is clearly called out.  One registry is requested with initial contents clearly spelled out.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The one new registry is SNMP-TLSTM HashAlgorithm Registry.  It is designated as expert review whereby the Security Area via the TLS WG is consulted as to whether or not a new algorithm should be added.  New algorithms should not show up here first.  They would appear in the TLS Cipher Suites registry.  Someone wanting to use the same algorithm for SNMP TLSTM would then request that algorithm receive a one-byte allocation in this new registry.

# Document Shepherd Write-Up for Group Documents

## Document History

The document was actively discussed between a number of working group individuals as well as in consultation with members of the TLS working group.  No one has expressed dissent in the work or its direction, but I would have liked to see reviews from the SEC DIR and from the broader OPS DIR.  Requests for those reviews went unanswered.

One area to pay special attention to is how new hash algorithms are allocated in the new IANA-maintained registry.  One thought was to have new algorithms auto-added based on work happening in TLS 1.3.  However, that could lead to a proliferation of algorithms in this registry that are never used.  Therefore, the current text stipulates an additional expert review and work on behalf of interested parties to propose a new hash algorithm be added (and that represents the consensus of the group).

It is also important to call out that the reason this document requests a new registry vs. adding to the existing one is that the TLS working group did not want to imply that any new algorithms added to the existing fingerprint registry worked with TLS 1.2.  Choosing this approach allowed for a much more simplified update to RFC 6353.

## Additional Reviews

The contents of this document do interact closely with TLS and thus a review from the TLS WG was requested.  Their input was key in choosing this document's current direction (see above).  However, I would have liked to have received some other directorate-level reviews to reinforce the approach in the registry is sound.

From a MIB standpoint, by taking a simplified approach, the updates were minimal.  That is, even though this document moves to a new hash algorithm registry, the semantics of the MIB and the SnmpTLSFingerprint textual convention remain the same, thus backwards compatibility is preserved.  This was confirmed by Jürgen Shönwälder.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

SEC DIR and OPS DIR should review.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard.  This is the correct type based on the RFC it updates and that it defines a [modified] MIB module.  This status is correctly reflected in Datatracker.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes.  An IPR call was conducted and no IPR was reported.  The author explicitly stated he knows of no IPR.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Most IDNITS have been sorted.  However, this is still a reference to the obsolete RFC 5246, and that is intentional as we are incorporating the values from the old TLS 1.2 registry.

Also note, the references from the MIB have been added as norm/inform references (in a style similar to what is done in YANG modules), and in the case of RFC 5890, has been made normative with new language in the MIB.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

References look correct.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are freely available.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

It will update RFC 6353.  That metadata in the document is correct.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The ask of IANA is clearly called out.  One registry is requested with initial contents clearly spelled out.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

The one new registry is SNMP-TLSTM HashAlgorithm Registry.  It is designated as expert review whereby the Security Area via the TLS WG is consulted as to whether or not a new algorithm should be added.  New algorithms should not show up here first.  They would appear in the TLS Cipher Suites registry.  Someone wanting to use the same algorithm for SNMP TLSTM would then request that algorithm receive a one-byte allocation in this new registry.

Extending LC for this to try and get some directorate reviews.  Plus, some LC comments came from the WG, and a revised I-D will be required.