Thanks a lot for the thorough analysis, Michael
In general, i agree with everything you said, and equally would like to
see the DISCUSS cleared. Maybe some hopefully helpfull additions from my side:
UTA is IMHO an overreach by not addressing the expensive and slow progression
of certified software stack in many industrial and other "controlled networks"
that are not on the Internet. It makes (correct) claims about wide-spread
use of TLS 1.3, but does not mention that this wide-spread use is ONLY from
Internet connections, but not those non-Internet environments , where TLS 1.3
will for a long time not be equally widely available. I raised that concern
in rview of the UTA draft, but i don't think the authors did address the concern
appropriately. This leads to IMHO inappropriate expectations/requirements
raised by the UTA draft.
Wrt to evolution of RFC8995 and if/how/when we can move beyond mandatory
support for TLS 1.2 (in support of those problematic clients that can only
support
TLS 1.2):
I can see that we should consider to "upgrade" the requirements in RFC8995bis
to "MUST use TLS 1.3 (or better)" for any connections that may use the Internet.
This could then likewise be defined as an update to BRSKI PRM RFC (and some of
the other BRSKI extension RFCs). This would further limit the use of TLS 1.2 to
those BRSKI protocol legs known to stay within an isolated IP environment
(within
industrial or other controlled networks). That effectively is the beauty of
BRSKI, that it can provide application layer isolation between volatile
equipment
(supporting only TLS 1.2) and the Internet.
Cheers
Toerless
On Tue, May 06, 2025 at 07:34:14AM -0400, Michael Richardson wrote:
>
> This is about Mike Bishop and Gorry's DISCUSS comments about TLS 1.3:
>
> Gorry:
> > 1. “TLS 1.2 MAY be used”, please could you explain why this is only "MAY"
> > rather than being stronger, noting draft-ietf-uta-require-tls13 and RFC
> > 9325, which asserts that TLS 1.3 is in widespread use.
>
> Bishop:
> > RFC 8995 predates draft-ietf-uta-require-tls13, obviously, since the latter
> > is also with the IESG now. This document only restates 8995's TLS
> > requirements on the registrar and the MASA, so those don't have to change
> > here. However, in Section 7.3, should the REQUIRED/SHOULD alignment of TLS
> > versions be swapped at least for the Registrar-Agent to match the new
> > guidance? For new protocols, TLS 1.3 ought to be the requirement; TLS 1.2
> > is permitted. (Non-blocking: Consider whether to make corresponding
> > requirements on the registrar and MASA when BRSKI-PRM is being
> > used. However, without updating 8995, this would effectively make both
> > versions mandatory for servers supporting both BRSKI and BRSKI-PRM.)
>
> As Mike says, PRM is an update to RFC8995, which predates uta-require, and I
> don't think PRM should update this section of RFC8995.
> I think that there will be an RFC8995bis started in late 2026, and it would
> be nice to be able to obsolete TLS 1.2 then.
>
> HOWEVER, RFC8995, published 4 years ago, is essentially consistent with
> uta-require. UTA-REQUIRE says:
>
> Any new protocol that uses TLS MUST specify as its default TLS 1.3.
> For example, QUIC [QUICTLS] requires TLS 1.3 and specifies that
> endpoints MUST terminate the connection if an older version is used.
>
> If deployment considerations are a concern, the protocol MAY specify
> TLS 1.2 as an additional, non-default option. As a counter example,
> the Usage Profile for DNS over TLS [DNSTLS] specifies TLS 1.2 as the
> default, while also allowing TLS 1.3. For newer specifications that
> choose to support TLS 1.2, those preferences are to be reversed.
>
> We do not know what "additional, non-default option" are.
> The conversation on the UTA list did not clarify anything for us.
> I read the above as "SHOULD TLS 1.3, unless you can't"
>
> The text of RFC8995 is:
>
> Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is
> REQUIRED on the pledge side. TLS 1.3 (or newer) SHOULD be available
> on the registrar server interface, and the registrar client
> interface, but TLS 1.2 MAY be used. TLS 1.3 (or newer) SHOULD be
> available on the MASA server interface, but TLS 1.2 MAY be used.
>
> We say "SHOULD", and we do this for *OPERATIONAL* considerations.
> As permitted by UTA-REQUIRE, so we are already consistent.
>
> It should be possible for either Pledge, or Registrar to propose TLS 1.3 only
> when acting as a TLS client, but when Registrar or MASA responds, they need
> to support TLS 1.2.
>
> I will not that RFC8995 requires client side authentication to arrive at a
> form of mTLS. (A "form": provisional TLS state, see: Section 5.6.2 of
> RFC8995 explains this more)
>
> To do this, we require *libraries*, *TLS terminators* and frameworks that
> support TLS client authentication. For hardware offload devices, this
> implies support for RFC9440 headers, or some proprietary equivalent.
> Given how TLS 1.3 does client authentication differently than 1.2, often
> requiring changes to frameworks, we still think that this presents hurdles to
> implementers. We receive feedback that while new TLS-using applications can
> often be added to router control planes and IoT devices, deploying new TLS
> libraries requires new FIPS certification. Remember that FIPS does not
> actually evaluate source code, but rather compiled binaries.
>
> While TLS 1.3 might be widespread in browsers, TLS 1.3 with client
> authentication support is not. It's not even enabled by default in a number
> of browsers. The advice out there is to do TLS 1.2 only, which I find
> unfortunate.
>
> I experienced problems with Ruby On Rails frameworks only two weeks ago
> (after an
> upgrade to eventsmachine and thin), where use of TLS 1.3 lost the client
> certificate, breaking everything. I had to monkey patch the framework to
> work around this lack in a rather unpleasant way.
>
> Mike Bishop's other comments about HTTP codes was fixed in version 20.
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-anima-brski-prm-19&url2=draft-ietf-anima-brski-prm-21&difftype=--html
>
> Please clear your DISCUSS.
>
> --
> Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
--
---
t...@cs.fau.de
_______________________________________________
Anima mailing list -- anima@ietf.org
To unsubscribe send an email to anima-le...@ietf.org
