Question regarding RFC 6353

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Question regarding RFC 6353

Kenneth Vaughn
Hello and thank you for your time.

I am providing guidance to both ISO TC 204 and the USDOT on the best policies on upgrading systems currently based on prior versions of SNMP to the latest security solutions for SNMPv3.

RFC 6353 (TLSTM for SNMP) specifically references RFC 5246 (TLSv1.2), however, TLS has been updated to TLSv1.3. I have not identified any technical reason why using TLSv1.3 would create problems vs TLSv1.2, but technically RFC6353 does not require this.

Are there any plans to update RFC6353 to reference TLSv1.3? If not, are you aware of any technical problem in others (e.g., ISO TC 204, USDOT, etc) writing a specification that requires the use of RFC 6353 with the stated exception that all references to TLSv1.2 must be replaced with references to TLSv1.3? Or do you believe it would be appropriate to submit (and do you believe there would there be an IETF group interested in receiving) a proposal for a new RFC that updates the reference? If so, who should that update proposal be sent to?

Thank you for your help in this matter.

Regards,
Ken Vaughn

Trevilon LLC
6606 FM 1488 RD #148-503
Magnolia, TX 77354
+1-936-647-1910
+1-571-331-5670 cell


_______________________________________________
Isms mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/isms
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding RFC 6353

Juergen Schoenwaelder-2
Dear Kenneth,

RFC 6353 says in section 9.2.1:

   Implementations of TLS typically support multiple versions of the
   Transport Layer Security protocol as well as the older Secure Sockets
   Layer (SSL) protocol.  Because of known security vulnerabilities,
   TLSTM clients and servers MUST NOT request, offer, or use SSL 2.0.
   See Appendix E.2 of [RFC5246] for further details.

This text was published 9 years ago and this it would surely look
different today. RFC 7568 (June 2015) has deprecated the usage of SSL
3.0. There is currently an Internet-Draft

https://tools.ietf.org/id/draft-ietf-tls-oldversions-deprecate-06.html

aiming to deprecate TLS 1.0 and TLS 1.1. This draft does not update
RFC 6363 but this might actually be an omission (I will contact the
authors to clarify this in a separate email).

TLS versions evolve and what the IETF seems to be doing is to
deprecate outdated TLS versions while protocols are usually designed
to work with newer TLS versions. I assume that RFC 6353 has no
technical issues to work with TLS 1.3 since it does not go into the
TLS internals. Unless someone finds a problem with using RFC 6353 with
TLS 1.3, I do not see a need to update RFC 6353. (The IETF generally
does not spin RFCs to fix references that have become outdated.)

If the above I-D gets published as RFC XXXX and if it formally updates
RFC 6353, then requiring the implementation of RFC 6353 and RFC XXXX
essentially says that (today) TLS 1.2 or 1.3 are required. I do not
know whether other SDOs want to be even stricter than this today the
long term trajectory of any TLS version seems to be its deprecation.

/js

On Fri, Jul 17, 2020 at 07:58:58AM -0500, Kenneth Vaughn wrote:

> Hello and thank you for your time.
>
> I am providing guidance to both ISO TC 204 and the USDOT on the best policies on upgrading systems currently based on prior versions of SNMP to the latest security solutions for SNMPv3.
>
> RFC 6353 (TLSTM for SNMP) specifically references RFC 5246 (TLSv1.2), however, TLS has been updated to TLSv1.3. I have not identified any technical reason why using TLSv1.3 would create problems vs TLSv1.2, but technically RFC6353 does not require this.
>
> Are there any plans to update RFC6353 to reference TLSv1.3? If not, are you aware of any technical problem in others (e.g., ISO TC 204, USDOT, etc) writing a specification that requires the use of RFC 6353 with the stated exception that all references to TLSv1.2 must be replaced with references to TLSv1.3? Or do you believe it would be appropriate to submit (and do you believe there would there be an IETF group interested in receiving) a proposal for a new RFC that updates the reference? If so, who should that update proposal be sent to?
>
> Thank you for your help in this matter.
>
> Regards,
> Ken Vaughn
>
> Trevilon LLC
> 6606 FM 1488 RD #148-503
> Magnolia, TX 77354
> +1-936-647-1910
> +1-571-331-5670 cell
> www.trevilon.com
>

> _______________________________________________
> Isms mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/isms


--
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/>

_______________________________________________
Isms mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/isms
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding RFC 6353

tom petch-4
From: Isms <[hidden email]> on behalf of Juergen Schoenwaelder <[hidden email]>
Sent: 17 July 2020 17:11

Dear Kenneth,

RFC 6353 says in section 9.2.1:

   Implementations of TLS typically support multiple versions of the
   Transport Layer Security protocol as well as the older Secure Sockets
   Layer (SSL) protocol.  Because of known security vulnerabilities,
   TLSTM clients and servers MUST NOT request, offer, or use SSL 2.0.
   See Appendix E.2 of [RFC5246] for further details.

This text was published 9 years ago and this it would surely look
different today. RFC 7568 (June 2015) has deprecated the usage of SSL
3.0. There is currently an Internet-Draft

https://tools.ietf.org/id/draft-ietf-tls-oldversions-deprecate-06.html

aiming to deprecate TLS 1.0 and TLS 1.1. This draft does not update
RFC 6363 but this might actually be an omission (I will contact the
authors to clarify this in a separate email).

TLS versions evolve and what the IETF seems to be doing is to
deprecate outdated TLS versions while protocols are usually designed
to work with newer TLS versions. I assume that RFC 6353 has no
technical issues to work with TLS 1.3 since it does not go into the
TLS internals. Unless someone finds a problem with using RFC 6353 with
TLS 1.3, I do not see a need to update RFC 6353. (The IETF generally
does not spin RFCs to fix references that have become outdated.)

If the above I-D gets published as RFC XXXX and if it formally updates
RFC 6353, then requiring the implementation of RFC 6353 and RFC XXXX
essentially says that (today) TLS 1.2 or 1.3 are required. I do not
know whether other SDOs want to be even stricter than this today the
long term trajectory of any TLS version seems to be its deprecation.

<tp>
What a question of CoB on a Friday afternoon.

I think that it may be more complicated than that.  TLS 1.3 is a radical restructuring of TLS so that e.g. the concept of a ciphersuite changes, digital signatures are specified separately and while renegotiation has gone, TLS has never been much of a fan of client authentication which SNMP is fussy about and prohibited renegotiation as a result.  I think that a some features of TLS 1.3 would need banning so that the client authentication cannot change.  And some users have found TLS 1.3 not fit for purpose since it renders a number of operational practices impossible, especially in areas where the security of the organisation takes precedence over the security of the individual, not a view that receives much support in the IETF TLS WG!  There is an I-D about this in the IETF OPSEC WG and what the future holds for this is hard to know, more politics than engineering.

I see the focus of the IETF on YANG these days and think it unlikely that the IETF would update that RFC unless a lot of energy appeared to do so.

And I do not believe that the TLS WG has shown much interest in the consequences for other protocols of deprecating earlier versions of TLS.

I will think some more but it might be a slow process.

Tom Petch
/js

On Fri, Jul 17, 2020 at 07:58:58AM -0500, Kenneth Vaughn wrote:

> Hello and thank you for your time.
>
> I am providing guidance to both ISO TC 204 and the USDOT on the best policies on upgrading systems currently based on prior versions of SNMP to the latest security solutions for SNMPv3.
>
> RFC 6353 (TLSTM for SNMP) specifically references RFC 5246 (TLSv1.2), however, TLS has been updated to TLSv1.3. I have not identified any technical reason why using TLSv1.3 would create problems vs TLSv1.2, but technically RFC6353 does not require this.
>
> Are there any plans to update RFC6353 to reference TLSv1.3? If not, are you aware of any technical problem in others (e.g., ISO TC 204, USDOT, etc) writing a specification that requires the use of RFC 6353 with the stated exception that all references to TLSv1.2 must be replaced with references to TLSv1.3? Or do you believe it would be appropriate to submit (and do you believe there would there be an IETF group interested in receiving) a proposal for a new RFC that updates the reference? If so, who should that update proposal be sent to?
>
> Thank you for your help in this matter.
>
> Regards,
> Ken Vaughn
>
> Trevilon LLC
> 6606 FM 1488 RD #148-503
> Magnolia, TX 77354
> +1-936-647-1910
> +1-571-331-5670 cell
> www.trevilon.com
>

> _______________________________________________
> Isms mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/isms


--
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/>

_______________________________________________
Isms mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/isms
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding RFC 6353

Wes Hardaker-2
tom petch <[hidden email]> writes:

> I think that it may be more complicated than that.  TLS 1.3 is a
> radical restructuring of TLS so that e.g. the concept of a ciphersuite
> changes, digital signatures are specified separately and while
> renegotiation has gone, TLS has never been much of a fan of client
> authentication which SNMP is fussy about and prohibited renegotiation
> as a result.

I think client-based certificate authentication is the only thing that
would prevent RFC6353 from working over TLS 1.3, and I doubt it'll be a
problem (but haven't done the work to prove it).  RFC6353 was explicitly
written to not specify one specific version of TLS to use.  The only
thing it states authoritatively is in 9.2.1:

   Because of known security vulnerabilities,
   TLSTM clients and servers MUST NOT request, offer, or use SSL 2.0.
   See Appendix E.2 of [RFC5246] for further details.

The reference to TLS 1.2 via RFC5246 is in the document because we had
to normatively reference *some* version of TLS, and that's what was
available then.  No where in the document does it say "that's the only
version you should use".
--
Wes Hardaker
USC/ISI

_______________________________________________
Isms mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/isms
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding RFC 6353

tom petch-4
From: Wes Hardaker <[hidden email]>
Sent: 21 July 2020 23:46
tom petch <[hidden email]> writes:

> I think that it may be more complicated than that.  TLS 1.3 is a
> radical restructuring of TLS so that e.g. the concept of a ciphersuite
> changes, digital signatures are specified separately and while
> renegotiation has gone, TLS has never been much of a fan of client
> authentication which SNMP is fussy about and prohibited renegotiation
> as a result.

I think client-based certificate authentication is the only thing that
would prevent RFC6353 from working over TLS 1.3, and I doubt it'll be a
problem (but haven't done the work to prove it).  RFC6353 was explicitly
written to not specify one specific version of TLS to use.  The only
thing it states authoritatively is in 9.2.1:

   Because of known security vulnerabilities,
   TLSTM clients and servers MUST NOT request, offer, or use SSL 2.0.
   See Appendix E.2 of [RFC5246] for further details.

The reference to TLS 1.2 via RFC5246 is in the document because we had
to normatively reference *some* version of TLS, and that's what was
available then.  No where in the document does it say "that's the only
version you should use".

<tp>
Yes, my concern is more one of Fear, Uncertainty and Doubt as opposed to hard engineering, but this is security so it behoves us to be cautious.  I see many strands

Security is about operational practices and
draft-ietf-opsec-ns-impact
looks at what may be difficult or impractical with TLS 1.3 compared to
TLS 1.2.  Note that it is an I-D and it might be a year or two before
the IETF gets to decide whether or not to publish it as an RFC by which
time all sorts of things might have happened.  The issues in the I-D have
appeared on the TLS WG list and been rejected.  The I-D was proposed for
adoption by the TLS WG and was rejected although it did get some review
and constructive feedback, that is, its description of the behaviour of TLS1.3 has been reviewed.
I commend that I-D to anyone looking to migrate to TLS1.3 who has anything more than
an HTTP web server.

Part of the ethos of the TLS WG is that where there is a conflict
between the security of an individual and that of an organisation then
the former takes precedence which I see as relevant here.

TLS, like SSL before it, has little concern with the authentication of
the user, that often being done with renegotiation.  For OAM in general,
and SNMP in particular, user authentication is paramount; the protocol
must yield an authenticated identity.  Given the major reconstruction of
TLS with 1.3, I would not assume that the user identity is ok without a
careful study.  SNMP prohibited renegotiation as TLS1.3 has done for
different reasons.  The TLS WG has just approved an I-D
draft-ietf-tls-exported-authenticator
which offers a replacement for renegotiation; is that ok for SNMP?
probably not. The approach to signature schemes has changed in TLS 1.3;
is there any impact on user certificate chains?  Much of the work on
TLS1.3 was on facilitating 0-RTT; is that ok?  I think that given
security is involved, then TLS 1.3 and all the TLS1.3 extensions need
careful examination from the perspective of delivering an authenticated
user identity before I would regard it as... well, not safe, because I
never say anything is safe but rather without any risk that I can see.

My background is operations, not security, so I have a 101 understanding
of security and TLS (but will never be a cryptographer:-)

HTH

Tom Petch
--
Wes Hardaker
USC/ISI

_______________________________________________
Isms mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/isms
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding RFC 6353

Kenneth Vaughn
Tom et al.

Thank you for this great information. We will continue to study this topic and will present the information to the corresponding transportation WGs to decide on our future direction. 

To give you some background, within the US, the Intelligent Transportation Systems (ITS) industry adopted the use of SNMPv1 in the late 1990s for managing an array of field devices (signal controllers, ramp meters, message signs, etc.). We have standardized the data for these devices (and some other issues) under the National Transportation Communications for ITS Protocol (NTCIP), which is a joint effort among the American Association of State Highway and Transportation Officials (AASHTO), the Institute of Transportation Engineers (ITE), and the National Electrical Manufacturers Association (NEMA). 

Around the same time, the UK adopted SNMP (v2) to manage some of their field devices using a separate set of MIBs (under their UTMC project). 

Over the years, the US and UK solutions have been almost universally adopted within those two countries while also being widely deployed in other countries. 

From the beginning, I have been complaining about the lack of security in these standards, but SNMPv3 was not released until the early 2000’s after deployments had already started and there was little interest within the industry to revisit a decision when most networks at the time were private networks and many of the links were extremely slow (e.g., 1200 bps to the field - this even led to the development of a much more bandwidth friendly version of SNMP that is specific to ITS). However, there is now increased interest in securing the protocol due to:
- Higher speed communication networks - often shared 
- Higher speed processors in field equipment that run modern operating systems (e.g., Linux)
- Increased cybersecurity threats - and a few attacks that have impacted operations in specific areas
- The need to prepare for connected vehicles in the relatively near future.

Within the last decade, I have been involved in the development of two ISO TC 204 standards to address this issue (ISO 15784-2 defining how to use SNMP - including SNMPv3 - within ITS and ISO 20684 (all parts), which defines standardized data for devices).

After twenty years, the US is now accepting that we need to secure our protocol and is undertaking the current study to investigate the best way to achieve this. My best guess at this point is that the WG will decide to maintain the path towards using SNMPv3. It seems to me that the way in which we use the protocol is somewhat different than traditional network management. Based on my review of various articles, it seems as if the network management industry was (and still is) happy to use SNMP for network monitoring potentially with very basic security - but migrated to NETCONF for the purposes of device configuration, which tends to be a very manual process.  Within ITS, we use SNMP for both of these purposes but also use it for automated command and control on a fairly regular basis (e.g., altering signal timing, changing a message on a sign, etc). And the majority of our configuration commands are often just minor tweaks to a rather massive amount of information in the device. Thus, my impression of NETCONF and even RESTCONF with JSON is that they would entail a significant change in logic within our systems coupled with an increase in bandwidth and processing utilization while not providing any real practical benefit for our industry - except for the odd case of the complete (or substantial) controller re-configuration process - which is fairly rare. If you think I have somehow mis-characterized the impacts of NETCONF/RESTCONF, I am happy to be corrected, but assuming that my analysis is correct, I think our industry would prefer to continue the use of SNMP - or perhaps migrate to a completely different solution, in particular there would be some advantages to using data distribution technologies such as AMQP, MQTT, Kafka, or DDS but these obviously have very different trade-offs offering much better monitoring and data sharing while not handling the command and control as well.

I will keep you posted as the project progresses, but I suspect that there will likely be real interest within our industry to make sure that the security for SNMPv3 is maintained and updated to work with TLSv1.3. While I understand that the efforts to produce this type of documentation might have to depend heavily on ITS support, I would certainly hope that any such maintenance can be performed under the auspices of IETF so that other users of SNMPv3 can directly benefit from these efforts (e.g., rather than developing this update as an ISO or NTCIP standard where most of my involvement has been to date on this topic).

NOTE: As an aside, there might also be interest within the ITS community to add support for SNMPv3 using IEEE 1609.2 certs rather than just X.509 certs (https://datatracker.ietf.org/doc/draft-msahli-ise-ieee1609/), but this is likely a longer-term issue and obviously has to await feedback from the relevant ITS committees.

Regards,
Ken Vaughn

Trevilon LLC
6606 FM 1488 RD #148-503
Magnolia, TX 77354
+1-936-647-1910
+1-571-331-5670 cell

On Jul 22, 2020, at 4:40 AM, tom petch <[hidden email]> wrote:

From: Wes Hardaker <[hidden email]>
Sent: 21 July 2020 23:46
tom petch <[hidden email]> writes:

I think that it may be more complicated than that.  TLS 1.3 is a
radical restructuring of TLS so that e.g. the concept of a ciphersuite
changes, digital signatures are specified separately and while
renegotiation has gone, TLS has never been much of a fan of client
authentication which SNMP is fussy about and prohibited renegotiation
as a result.

I think client-based certificate authentication is the only thing that
would prevent RFC6353 from working over TLS 1.3, and I doubt it'll be a
problem (but haven't done the work to prove it).  RFC6353 was explicitly
written to not specify one specific version of TLS to use.  The only
thing it states authoritatively is in 9.2.1:

  Because of known security vulnerabilities,
  TLSTM clients and servers MUST NOT request, offer, or use SSL 2.0.
  See Appendix E.2 of [RFC5246] for further details.

The reference to TLS 1.2 via RFC5246 is in the document because we had
to normatively reference *some* version of TLS, and that's what was
available then.  No where in the document does it say "that's the only
version you should use".

<tp>
Yes, my concern is more one of Fear, Uncertainty and Doubt as opposed to hard engineering, but this is security so it behoves us to be cautious.  I see many strands

Security is about operational practices and
draft-ietf-opsec-ns-impact
looks at what may be difficult or impractical with TLS 1.3 compared to
TLS 1.2.  Note that it is an I-D and it might be a year or two before
the IETF gets to decide whether or not to publish it as an RFC by which
time all sorts of things might have happened.  The issues in the I-D have
appeared on the TLS WG list and been rejected.  The I-D was proposed for
adoption by the TLS WG and was rejected although it did get some review
and constructive feedback, that is, its description of the behaviour of TLS1.3 has been reviewed.
I commend that I-D to anyone looking to migrate to TLS1.3 who has anything more than
an HTTP web server.

Part of the ethos of the TLS WG is that where there is a conflict
between the security of an individual and that of an organisation then
the former takes precedence which I see as relevant here.

TLS, like SSL before it, has little concern with the authentication of
the user, that often being done with renegotiation.  For OAM in general,
and SNMP in particular, user authentication is paramount; the protocol
must yield an authenticated identity.  Given the major reconstruction of
TLS with 1.3, I would not assume that the user identity is ok without a
careful study.  SNMP prohibited renegotiation as TLS1.3 has done for
different reasons.  The TLS WG has just approved an I-D
draft-ietf-tls-exported-authenticator
which offers a replacement for renegotiation; is that ok for SNMP?
probably not. The approach to signature schemes has changed in TLS 1.3;
is there any impact on user certificate chains?  Much of the work on
TLS1.3 was on facilitating 0-RTT; is that ok?  I think that given
security is involved, then TLS 1.3 and all the TLS1.3 extensions need
careful examination from the perspective of delivering an authenticated
user identity before I would regard it as... well, not safe, because I
never say anything is safe but rather without any risk that I can see.

My background is operations, not security, so I have a 101 understanding
of security and TLS (but will never be a cryptographer:-)

HTH

Tom Petch
--
Wes Hardaker
USC/ISI



_______________________________________________
Isms mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/isms
Reply | Threaded
Open this post in threaded view
|

Re: Question regarding RFC 6353

tom petch-4
From: Kenneth Vaughn <[hidden email]>
Sent: 22 July 2020 17:58

Tom et al.

Thank you for this great information. We will continue to study this topic and will present the information to the corresponding transportation WGs to decide on our future direction.

Kenneth

RFC 8996 has now been published and this deprecates TLS and DTLS before 1.2 and so updates RFC5953 and RFC6353 but does not do anything to add 1.3 to SNMP:-( something I cannot see the IETF undertaking - it is all YANG these days

Tom Petch


To give you some background, within the US, the Intelligent Transportation Systems (ITS) industry adopted the use of SNMPv1 in the late 1990s for managing an array of field devices (signal controllers, ramp meters, message signs, etc.). We have standardized the data for these devices (and some other issues) under the National Transportation Communications for ITS Protocol (NTCIP), which is a joint effort among the American Association of State Highway and Transportation Officials (AASHTO), the Institute of Transportation Engineers (ITE), and the National Electrical Manufacturers Association (NEMA).

Around the same time, the UK adopted SNMP (v2) to manage some of their field devices using a separate set of MIBs (under their UTMC project).

Over the years, the US and UK solutions have been almost universally adopted within those two countries while also being widely deployed in other countries.

>From the beginning, I have been complaining about the lack of security in these standards, but SNMPv3 was not released until the early 2000’s after deployments had already started and there was little interest within the industry to revisit a decision when most networks at the time were private networks and many of the links were extremely slow (e.g., 1200 bps to the field - this even led to the development of a much more bandwidth friendly version of SNMP that is specific to ITS). However, there is now increased interest in securing the protocol due to:
- Higher speed communication networks - often shared
- Higher speed processors in field equipment that run modern operating systems (e.g., Linux)
- Increased cybersecurity threats - and a few attacks that have impacted operations in specific areas
- The need to prepare for connected vehicles in the relatively near future.

Within the last decade, I have been involved in the development of two ISO TC 204 standards to address this issue (ISO 15784-2 defining how to use SNMP - including SNMPv3 - within ITS and ISO 20684 (all parts), which defines standardized data for devices).

After twenty years, the US is now accepting that we need to secure our protocol and is undertaking the current study to investigate the best way to achieve this. My best guess at this point is that the WG will decide to maintain the path towards using SNMPv3. It seems to me that the way in which we use the protocol is somewhat different than traditional network management. Based on my review of various articles, it seems as if the network management industry was (and still is) happy to use SNMP for network monitoring potentially with very basic security - but migrated to NETCONF for the purposes of device configuration, which tends to be a very manual process.  Within ITS, we use SNMP for both of these purposes but also use it for automated command and control on a fairly regular basis (e.g., altering signal timing, changing a message on a sign, etc). And the majority of our configuration commands are often just minor tweaks to a rather massive amount of information in the device. Thus, my impression of NETCONF and even RESTCONF with JSON is that they would entail a significant change in logic within our systems coupled with an increase in bandwidth and processing utilization while not providing any real practical benefit for our industry - except for the odd case of the complete (or substantial) controller re-configuration process - which is fairly rare. If you think I have somehow mis-characterized the impacts of NETCONF/RESTCONF, I am happy to be corrected, but assuming that my analysis is correct, I think our industry would prefer to continue the use of SNMP - or perhaps migrate to a completely different solution, in particular there would be some advantages to using data distribution technologies such as AMQP, MQTT, Kafka, or DDS but these obviously have very different trade-offs offering much better monitoring and data sharing while not handling the command and control as well.

I will keep you posted as the project progresses, but I suspect that there will likely be real interest within our industry to make sure that the security for SNMPv3 is maintained and updated to work with TLSv1.3. While I understand that the efforts to produce this type of documentation might have to depend heavily on ITS support, I would certainly hope that any such maintenance can be performed under the auspices of IETF so that other users of SNMPv3 can directly benefit from these efforts (e.g., rather than developing this update as an ISO or NTCIP standard where most of my involvement has been to date on this topic).

NOTE: As an aside, there might also be interest within the ITS community to add support for SNMPv3 using IEEE 1609.2 certs rather than just X.509 certs (https://datatracker.ietf.org/doc/draft-msahli-ise-ieee1609/), but this is likely a longer-term issue and obviously has to await feedback from the relevant ITS committees.

Regards,
Ken Vaughn

Trevilon LLC
6606 FM 1488 RD #148-503
Magnolia, TX 77354
+1-936-647-1910
+1-571-331-5670 cell
www.trevilon.com<http://www.trevilon.com>

On Jul 22, 2020, at 4:40 AM, tom petch <[hidden email]<mailto:[hidden email]>> wrote:

From: Wes Hardaker <[hidden email]<mailto:[hidden email]>>
Sent: 21 July 2020 23:46
tom petch <[hidden email]<mailto:[hidden email]>> writes:

I think that it may be more complicated than that.  TLS 1.3 is a
radical restructuring of TLS so that e.g. the concept of a ciphersuite
changes, digital signatures are specified separately and while
renegotiation has gone, TLS has never been much of a fan of client
authentication which SNMP is fussy about and prohibited renegotiation
as a result.

I think client-based certificate authentication is the only thing that
would prevent RFC6353 from working over TLS 1.3, and I doubt it'll be a
problem (but haven't done the work to prove it).  RFC6353 was explicitly
written to not specify one specific version of TLS to use.  The only
thing it states authoritatively is in 9.2.1:

  Because of known security vulnerabilities,
  TLSTM clients and servers MUST NOT request, offer, or use SSL 2.0.
  See Appendix E.2 of [RFC5246] for further details.

The reference to TLS 1.2 via RFC5246 is in the document because we had
to normatively reference *some* version of TLS, and that's what was
available then.  No where in the document does it say "that's the only
version you should use".

<tp>
Yes, my concern is more one of Fear, Uncertainty and Doubt as opposed to hard engineering, but this is security so it behoves us to be cautious.  I see many strands

Security is about operational practices and
draft-ietf-opsec-ns-impact
looks at what may be difficult or impractical with TLS 1.3 compared to
TLS 1.2.  Note that it is an I-D and it might be a year or two before
the IETF gets to decide whether or not to publish it as an RFC by which
time all sorts of things might have happened.  The issues in the I-D have
appeared on the TLS WG list and been rejected.  The I-D was proposed for
adoption by the TLS WG and was rejected although it did get some review
and constructive feedback, that is, its description of the behaviour of TLS1.3 has been reviewed.
I commend that I-D to anyone looking to migrate to TLS1.3 who has anything more than
an HTTP web server.

Part of the ethos of the TLS WG is that where there is a conflict
between the security of an individual and that of an organisation then
the former takes precedence which I see as relevant here.

TLS, like SSL before it, has little concern with the authentication of
the user, that often being done with renegotiation.  For OAM in general,
and SNMP in particular, user authentication is paramount; the protocol
must yield an authenticated identity.  Given the major reconstruction of
TLS with 1.3, I would not assume that the user identity is ok without a
careful study.  SNMP prohibited renegotiation as TLS1.3 has done for
different reasons.  The TLS WG has just approved an I-D
draft-ietf-tls-exported-authenticator
which offers a replacement for renegotiation; is that ok for SNMP?
probably not. The approach to signature schemes has changed in TLS 1.3;
is there any impact on user certificate chains?  Much of the work on
TLS1.3 was on facilitating 0-RTT; is that ok?  I think that given
security is involved, then TLS 1.3 and all the TLS1.3 extensions need
careful examination from the perspective of delivering an authenticated
user identity before I would regard it as... well, not safe, because I
never say anything is safe but rather without any risk that I can see.

My background is operations, not security, so I have a 101 understanding
of security and TLS (but will never be a cryptographer:-)

HTH

Tom Petch
--
Wes Hardaker
USC/ISI



_______________________________________________
Isms mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/isms