859 karma · joined September 22, 2021
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...
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.
https://mailarchive.ietf.org/arch/msg/tools-discuss/EpoQcVt_...
RFC #s are issued sometime before publication, so they can come out out of order. I would expect 9999, 10001, etc. to show up eventually.
I didn't dig into the details of the fluticasone HFA switch, but my impression is that while it's obvious to replace the propellant, apparently you do need to do some engineering (e.g., on the nozzle) to make it work right. I don't know enough about what they actually had to do to know if the patent should have been granted or not.
Again, this isn't an endorsement of these mandates; I'm just saying that what you're proposing here doesn't address the objectives that policymakers who are in favor of these mandates are trying to achieve.
Certainly parents can install parental control software, but what does this have to do with children's PII being shared with sites?
Just so we're on the same page, the way AB1043 works is that the OS determines the user's age and then shares the age bracket with apps. No PII is shared with sites (this is not to say that the age isn't sensitive, but it's not PII as usually regarded). Is your concern here that sites get access to children's information because children visit certain sites regardless of legislation? That's a real thing, but it seems mostly orthogonal to age assurance.
It's useful to contrast this with the various device-based mandates that have been created in order to get a sense of what legislators seem to be trying to do. With that in mind, a few points:
* What you are proposing allows parents to opt in via parental controls, but age assurance mandates (both device-side and server-side) tend to require positive action to enter unrestricted modes. In some cases (CA AB 1043, for instance), this is just a matter of entering your age. In others, you actually need to demonstrate your age via some technical mechanism.
* While many age assurance mandates focus on adult content, which is primarily consumed via the Web, others (e.g., Australia's Social Media Minimum Age) focus on social networking, which is primarily consumed via apps, so anything that is Web only will not be effective.
* Site-level granularity isn't really fine enough in some cases. For example, the New York SAFE for Kids act prohibits certain behaviors such as algorithmic recommendations when a user is a minor, but doesn't require blocking minor usage entirely. It's potentially possible to implement this with something like RTA, but it would have to at minimum be at much finer granularity.
Section VI of https://kgi.georgetown.edu/wp-content/uploads/2026/01/Age_As... goes into quite a bit more detail about various architectures (disclaimer, I'm an author).
None of this is an endorsement of age assurance techniques; I'm just trying to help flesh out the situation.
> All legislation regarding age verification must revolve around this otherwise people must reject it as an abusive form of tracking and privacy invasion.
It's a bit late for that, given that around half of US states already have some kind of age assurance mandate.
Specifically, if you bind authentication to the connection, then an attacker who impersonates the server (in this case because it's the first connection, but in other settings because they have a fake certificate), then client authentication is not portable to another connection, so the attacker can't mount a classic MITM attack. However -- and this is a big however -- that doesn't mean that there aren't serious security problems. For example:
* If you use SSH to copy a secret such as an API key to the server, then the attacker still knows the API key.
* If you download some file (e.g., a script) from the server and then trust it, the attacker can use that to provide a malicious script.