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 <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
