ekr____

> The design intent is still bad though: we should never have given CAs universal issuance privileges.

This is sort of right and sort of wrong. It's true that you could have a DNSSEC-style regime where only one entity could issue for a given domain, but as long as you're going to allow third party issuance at all, then you have to contend with the fact that most CAs want to issue in the big gTLDs (.com, .org, etc.) and so narrowing issuance doesn't help that much in many cases.

> Had browser makers supported DANE instead, and had we embraced DNSSEC instead of casting aspersions on it, we wouldn't have needed Let's Encrypt because ownership of a domain name would have already, by that very fact, let you authenticate to anyone.

This is ahistorical. By the time that DANE was designed, the WebPKI model was well entrenched and there was a huge population of browsers that couldn't really be upgraded and also only supported the WebPKI. If you wanted something that was acceptable to those browsers, it had to be WebPKI and it had to be cross-signed, hence Let's Encrypt.

I suppose you could argue that at some point after that one could have tried to deploy DANE and phase out LE and the rest of the WebPKI. I don't think that's true for the reasons that have been discussed on HN about DNSSEC, but that's really not the same as you wouldn't have needed LE in the first place.

People have debated DANE endlessly here, so I'm not sure how much more I have to add at this point. However, browsers, at least, do swiftly handle revocation for CAs, as indicated in this comment: https://news.ycombinator.com/item?id=50167244. They also handle EE revocation to varying extents, with Firefox having complete coverage and other browsers having partial coverage.

This isn't quite how TLS feature negotiation works.

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.

TLS is an extensible protocol. For instance, you can add new key establishment algorithms or cipher suites. What this specification is saying is that the IETF will not be publishing such extensions for TLS 1.2. For example, they will not be adding post-quantum key establishment.

No disagreement there.

I have no opinion on ULA+NPTv6, other than Experimental doesn't mean you shouldn't use it. How else would people experiment. It does mean that the level of vetting by the IETF is potentially lower.

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.

In fairness, I do think that this situation is somewhat different. As I noted above (https://news.ycombinator.com/item?id=48812792), there are two main routes to an Informational RFC of this kind.

* 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 document actually is being advanced as Informational, though there are also non-IETF Informational RFCs (see upthread).

> What’s his next step if the authors publish as an information RFC? He can’t stop that, right?

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.

Good question.

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.

You're right. Bad writing on my part. Edited to make it clear.

Adding a little color here... There are already code points registered for pure ML-KEM on the basis of the draft.

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.

> (2) The RFC at issue documents the possibility of running TLS with pure MLKEM rather than in a hybrid configuration with ECDH. Hybrid TLS is already the mainstream, documented, standardized method for using PQC in a TLS connection. Bernstein is canvassing opposition to any documentation of the possibility of pure MLKEM in TLS.

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.

That's not really possible to explain in this space, unfortunately, but the overall idea is that there are mathematical techniques that allow you to prove that you have a valid certificate without revealing which one it is.

This isn't correct. With ZKP-based systems even the CA can't track you. That's the "zero-knowledge" part.

The proof is bound to a cryptographic key stored in a tamper-resistant module (as in a phone).

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

Note that the EU is proposing to do this [0]. The ZKP part is a bit of a WIP and there have been some questions about the quality [1].

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

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

My sense is that many jurisdictions do not consider this sufficient, as they want to prevent parents from allowing their children to access restricted material (as happens fairly frequently). However, I guess we'll see.

> You don't wind up in a database for buying alcohol.

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.

Note that California AB1043 isn't actually age verification; rather it just requires the OS to ask for your age, not check it.

Hence Encrypted Client Hello (https://datatracker.ietf.org/doc/rfc9849/), though deployment is still thin.

Typically these APIs are designed so you can't make arbitrary queries, but rather there are fixed age brackets.

RFC 10000 will not be published. They're just going to skip past the number.

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.

Original author here: Yeah a lot of the evergreening techniques (chiral switch, etc.) don't prevent anyone from getting the original, though of course doctors may try to switch you. The inhaler thing is double bad because of the CFC ban.

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.

That's amazing. A lot of people import them from Canada, but this is much more interesting.

Let's Encrypt certificates are free.

Thanks for your explanation. I understand what you're talking about, but this all just seems to be entirely orthogonal to age assurance mandates, which are largely about controlling which content and experiences minors engage with, in many cases regardless of what parents want.

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.

I'm not following you here.

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.

> The only device mandates that should be taking place is for the default installations of web clients should be checking to see if parental controls are enabled. This only impacts the major browsers. An intern at each browser company could add this check in minutes. If they are enabled and the person logged in is on a regular account (not admin or power user of sorts) then the base installation of web clients must check for an RTA header [1]. If present, prompt for a override password and also give the option for the admin to approve-list the domain at that time. That's it. Not perfect, nothing is or will be.

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.