ekr____
Joined 5 years ago
Karma
861
Submissions
270
Member since
Sep 23
Recent submissions
Comment · 11 days ago
Comment · 11 days ago
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.
Comment · 3 months ago
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.
Comment · 3 months ago
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.
Comment · 3 months ago
No disagreement there.
Comment · 3 months ago
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.
Comment · 3 months ago
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..
Comment · 3 months ago
This document actually is being advanced as Informational, though there are also non-IETF Informational RFCs (see upthread).
Comment · 3 months ago
> 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.
Comment · 3 months ago
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.
Comment · 3 months ago
You're right. Bad writing on my part. Edited to make it clear.
Comment · 3 months ago
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.
Comment · 3 months ago
> (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.
Comment · 4 months ago
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.
Comment · 4 months ago
This isn't correct. With ZKP-based systems even the CA can't track you. That's the "zero-knowledge" part.
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.