On 06/05/2025 12:34, 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"
That would be my reading. However, looking at the I-D, I don't see the
case written down that I now see presented below.
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.
Claiming consistency with this in the document, and citing
draft-ietf-uta-require-tls13 would go a long way to resolving my own
discussion.
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(e) 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.
It seems that this also would be good to explicitly state - I suggest
both of those statements could likely be suitably made in the introduction.
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
For my side, I will be happy to clear my DISCUSS when the text explains
the current relationship to draft-ietf-uta-require-tls13, and I think
you may already have the thoughts behind that above. I am looking
forward to a text proposal.
Best wishes,
Gorry
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
