Skip to main content

Updates to the TLS Transport Model for SNMP

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: The IESG <>,,,,,,
Subject: Protocol Action: 'Updates to the TLS Transport Model for SNMP' to Proposed Standard (draft-ietf-opsawg-tlstm-update-14.txt)

The IESG has approved the following document:
- 'Updates to the TLS Transport Model for SNMP'
  (draft-ietf-opsawg-tlstm-update-14.txt) as Proposed Standard

This document is the product of the Operations and Management Area Working

The IESG contact persons are Warren Kumari and Robert Wilton.

A URL of this Internet-Draft is:

Ballot Text

Technical Summary

   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.

Working Group Summary

   From the shepherd writeup:

    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.

Document Quality

   This is really a security update.  My understanding is that
   there are vendors who are keen to implement, and others can
   be expected to do over time.


   Doc Shepherd is Joe Clarke
   Responsible AD is Rob Wilton

   IANA experts are TBD (need to check with authors and SEC ADs).

RFC Editor Note