Juergen,

It seems to me that all of these references argue for asking IANA to maintain 
the one-octet identifiers for the hashing algorithms (i.e., including the 
addition of new identifiers as new algorithms are developed), even after TLS 
1.2 fades from use. That will allow the fingerprint algorithm to remain 
unchanged in all of these scenarios and greatly simplifies our update effort.

Regards,
Ken Vaughn

Trevilon LLC
6606 FM 1488 RD #148-503
Magnolia, TX 77354
+1-936-647-1910
+1-571-331-5670 cell
kvau...@trevilon.com
www.trevilon.com

> On Nov 19, 2021, at 1:40 PM, Jürgen Schönwälder 
> <j.schoenwael...@jacobs-university.de> wrote:
> 
> Let me add one additional observation: RFC 6353 has been a blueprint
> for the YANG data model for SNMP configuration defined in RFC 7407.
> The ietf-x509-cert-to-name module, which is part of RFC 7407, defines
> a tls-fingerprint, which is also using a 1 octet hashing algorithm
> identifier. If we expand SNMP's TC, we should also look at the YANG
> equivalent. I also spotted that the YANG definition is imported by
> draft-ietf-netconf-https-notif-09.txt, I am not sure whether there are
> any other imports of this YANG definition (or the SNMP TC).
> 
> /js
> 
> On Fri, Nov 19, 2021 at 07:57:32PM +0100, Jürgen Schönwälder wrote:
>> Hi,
>> 
>> any clarifications that are necessary to run SNMP over (D)TLS 1.3 are
>> worth to work on. Looking at the document, it leaves me a bit puzzled
>> of what is actually changed. I think all text that is in RFC 6353 and
>> not modified should be removed from the update (for example, I think
>> there is no need to republish text concerning USM). For the MIB
>> module, it would help a lot if the revision clause would detail what
>> has actually changed instead of just saying "This version updated the
>> MIB to support (D)TLS 1.3." I like to see concrete text like
>> 
>> - SnmpTLSFingerprint has been depracted and SnmpTLS13Fingerprint
>>  has been introduced.
>> 
>> - The snmpTlstmCertToTSNTable has been deprecated and a new
>>  snmpTlstmCertToTSN13Table has been introduced.
>> 
>> - The snmpTlstmParamsTable has been deprecated and a new
>>  snmpTlstmParams13Table has been introduced
>> 
>> I find it problematic to embed "13" in the new object names as this
>> suggests the objects work only for TLS 1.3, which I hope is not the
>> case, i.e., I hope we do not have do yet another update when (D)TLS
>> 1.4 comes along in the future - or is the idea we actually do that? I
>> think there should also be clear guidelines what implementations
>> should do, implement the new objects and accept also D(TLS) 1.2
>> configurations via them or should the new objects only be supported
>> for D(TLS) 1.3 (and higher?) configurations?
>> 
>> /js
>> 
>> PS: There are also some bugs in the MIB module, mpTlstmAddrCount
>>    should be snmpTlstmAddrCount and CONTACT-INFO string is not
>>    terminated.
>> 
>> On Fri, Nov 19, 2021 at 04:26:50PM +0000, Joe Clarke (jclarke) wrote:
>>> Hello, WG.  Kenneth presented
>>> https://datatracker.ietf.org/doc/draft-vaughn-tlstm-update/ at IETF112
>>> to us, and this was previously presented at SecDispatch at IETF111.  The
>>> feeling there was that this work had merit, but Sec didn't have enough
>>> SNMP experience to be the owner.  At the AD level, the feeling was that
>>> perhaps opsawg did have the expertise and could pick this up.
>>> 
>>> Therefore, this serves as a three week call for adoption of this draft. 
>>> The three weeks is being given due to the US holiday next week.  There
>>> has already been some comments regarding scope that have been raised
>>> on-list, and Kenneth has called out potential courses of action in his
>>> 112 presentation.
>>> 
>>> Please respond by December 10, 2021 regarding your thoughts on adopting
>>> this work as well as comments on the work so far.
>>> 
>>> Thanks.
>>> 
>>> Joe
>>> 
>>> _______________________________________________
>>> OPSAWG mailing list
>>> OPSAWG@ietf.org
>>> https://www.ietf.org/mailman/listinfo/opsawg
>> 
>> -- 
>> Juergen Schoenwaelder           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/>
> 
> -- 
> Juergen Schoenwaelder           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/ 
> <https://www.jacobs-university.de/>>
> 
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org <mailto:OPSAWG@ietf.org>
> https://www.ietf.org/mailman/listinfo/opsawg 
> <https://www.ietf.org/mailman/listinfo/opsawg>
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to