Wrong, an SRV record for HTTPS already exists[0]. The problem is that the current recommendation is not to publish both "_https._tcp" and "_http._tcp", but to publish only the latter and let the client negotiate HTTPS using redirects and pinning. This recommendation is dumb as it doesn't solve the introduction mitm attack I originally described about 10 posts up. Browser vendors could make a statement on their SRV behaviour and agree to favour https if such a record exists.

> I'm not sure what the analog between HTTP/2 and SCTP is. SCTP is a transport protocol. It's something you'd run HTTP/2 on top of.

HTTP/2s primary achievement is to work around head-of-line blocking in TCP. SCTP already solved that problem. There is now less incentive to push HTTP/1.x streams over SCTP. The parallels are clear with DNSSEC and DNScurve. We have authentication now, it can be done (inefficiently) end-to-end. The added incentive of confidentiality weighed against the cost of a new round of redeployment isn't great. I think DNSSEC has already gone over the tipping point in the circles that ultimately matter.

> In any case: DNSSEC is shitty now, makes the Internet shittier, and actually has the interesting property of getting shittier the more people deploy it.

s~DNSSEC~HTTP/2~

> I'm mystified by this notion that we're past some "point of no return" with DNSSEC. We clearly are not.

I'm not hearing a coherent plan B from you or anyone else to solve these cross-protocol problems. HSTS and HPKP do not solve the problem of shitty CAs, DNSSEC opens to the door to a free alternative that, in the very least, means there are fewer entities we have to trust (hundreds -> a handful). HSTS and HPKP do not solve the introduction problem, DNSSEC adds some hope of helping there. What are your suggestions?

[0] http://dns-sd.org/ServiceTypes.html