Re: [Isms] Question regarding RFC 6353

[tom petch <[e-mail]>]

From: Wes Hardaker <[e-mail]>
Sent: 21 July 2020 23:46
tom petch <[e-mail]> 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