Version numbers are negotiated and some of the parameters are carried along with the version, but a lot of functionality (e.g., cipher suites) is individually negotiated and to some extent orthogonal to the version. This of course also allows you to add new features to an existing version.

What this draft is saying is that the IETF will not be adding new features targeted at TLS 1.2.

WRT IPv4 NAT, I'm not sure how much we can infer from the status. Many people at IETF were (and some still are) very anti-NAT, in part because they felt that IPv6 was the right solution. As a result, the IETF really avoided doing anything that looked like it was endorsing NAT, even though it's obviously just a fact of the Internet.

* Through the IETF

* Through the Independent Stream

The GOST documents went through the Independent Stream and therefore do not have IETF imprimateur. These documents are proposed for the IETF Stream and therefore require IETF Consensus to publish.

I know this is all super confusing. The basic problem is that the vast majority of RFCs come out of the IETF and so people often act as if all RFCs do. This is of course in part why people pursue Independent Stream publication rather than just publishing things on their own..

This is a slightly complicated question. There are several main routes to an Informational RFC.

* Through the IETF Stream, either through the Working Group (what is happening now) or via sponsorship by an Area Director. The former is what is happening now (this document is not up for Proposed Standard). I don't think the latter is likely to happen if TLS WG decides not to publish. If the TLS WG does decide to publish, then there are a number of steps afterward (AD review, IETF Last Call, IESG Review), plus potential avenues for appeal at some of these stages.

* Through the Independent Submissions Editor (ISE) (though in another comment wbl says that the ISE is not going to publish cryptography standards https://news.ycombinator.com/item?id=48812844). This is essentially at the sole discretion of the ISE and can't be appealed.

In either case, if the document makes it through all these gates and is eventually published as an RFC, then that's pretty much it, as RFCs aren't changed once published.

If the document is dropped by the IETF, nothing at all would happen. It's already a valid code point registration, and indeed the authors could have just published the document, registered the code points, and stopped (see: https://datatracker.ietf.org/doc/draft-barnes-tls-this-could...).

If the authors decided to later pick up the document somewhere else, then they could probably get the reference changed to whatever that was, as long as the semantics were identical.

The hybrid code point you reference is "preliminary" in the sense that when the RFC for hybrid ECC/ML-KEM is published (it's already been approved, https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/), it will replace the reference in the registry. However, it will have the same code point and the same semantics. If, for some reason, the IETF were to change the semantics, a new code point would have to be assigned for interop reasons.

Two more pieces of context here: 1. The IETF allows code point registrations based purely on the existence of a specification, and the pure ML-KEM code points have already been assigned (https://www.iana.org/assignments/tls-parameters/tls-paramete...). The question at hand is whether the IETF will publish an RFC documenting the ML-KEM cipher suites [edited to make clear that ML-KEM is documented already].

2. It is also possible to publish an RFC via what's called "Independent Submission" (https://www.rfc-editor.org/authors/rfc-independent-submissio...), which is not subject to the IETF Consensus process. This is, for instance, how the GOST RFC (https://datatracker.ietf.org/doc/rfc9367/) was published. If the IETF opts not to publish this draft, the authors can still submit it to the Independent Submissions Editor.

See https://educatedguesswork.org/posts/age-verification-id/#dev... for some more detail.

[0] https://digital-strategy.ec.europa.eu/en/faqs/eu-age-verific...

[1] https://proton.me/blog/eu-age-verification-app-hacked

I don't think this is a good assumption. It's not uncommon for stores to scan your ID when you buy alcohol.

> This proposal puts your name right next to the category of porn you're into, which will be a great way to coerce all those politicians into voting for the "correct" bill. Would be a shame if they found out a state senator watched porn, so maybe they'd better vote yes on the proposal.

This is not quite how typical systems are structured. Rather, the service provider outsources the age assurance to some third party Age Verification Provider (AVP), which then just returns an age estimate or a yes/no. Commonly, the AVP will have a stated policy that they don't share your identity with the client.

Obviously, you have to trust the AVP to comply with this policy, which is not ideal. There are approaches (e.g., zero-knowledge proofs) that provide some technical privacy protections, but they're not currently in wide use.

Note: this is not an endorsement of age assurance; I'm just trying to clarify the situation.