Let's Encrypt has also just added a new post in which they've been working tirelessly on a new nginx and apache plugin to certbot utilizing HTTP-01 validation:
It seems they are predicting TLS-SNI-0x going away for a lengthy period of time.
That said, the ALPN proposal is a start.
Though rather than just having it as a mere marker, it should incorporate features to securely indicate which domain label it is attempting to validate and achieve consensus on part of validator and the endpoint being validated.
I am hopeful such a scheme may be useful for future deployments down the road. I think it is likely before there is infrastructure in place utilizing a new mechanism of that kind that current needs will need to be met with one of the other mechanisms.
The speed and resource with which Let's Encrypt is working on solutions to migrate users to non-TLS-SNI validations might well be a signal.
The draft work which proposes what amounts to an ALPN protocol-name echo as an implicit signal to some heretofore unspecified compliance with ACME workarounds is a mistake. Even the suggestion to "scan alexa's top sites" to see if accidentally-clashing behavior is observed in the wild is naive at best, mind-numbingly misguided at worst.
Like you suggest, it's important to be explicit, and if they wish to lean on yet another protocol, now is an opportunity to enumerate the exact behaviors they want. It's good that this work has begun, but I hope it won't be rushed.
Agree 100%. I actually just joined the ACME mailing list to comment along those lines.
I hope that wasn't against protocol.
It will do favor to no-one to rush this. It's broken bad enough that it needs a fresh cycle of iteration and testing.
The Alexa scan idea is weak. Of course no one advertises "acme" as an ALPN name now. There's no incentive to today. If the proposal Mr. Rudenberg made were accepted, there'd be plenty of incentive for these same broken shared hosts to advertise an ALPN identifier of "acme". It just wouldn't be coupled with any incentive to fix the other issues.
On that topic, the proposed edit does not even attempt to define what circumstances/facts/assertions a presenter of the ALPN "acme" is hypothetically promising. No attempt is even made to extract a gentleman's agreement that a shared host vulnerable to the attacks which have been described would not advertise this ALPN. Of course, there's no real point to trying to extract that. The shared host would have no incentive to hold up their end of that promise.
But if this proposal as suggested moved forward without further revision, there would be incentive to make your TLS endpoint with "acme" tomorrow, whether or not your infrastructure is secure against the actual attack vectors that have effectively disqualified TLS-SNI-01 and TLS-SNI-02 at the present.
https://community.letsencrypt.org/t/help-test-certbot-apache...
It seems they are predicting TLS-SNI-0x going away for a lengthy period of time.
That said, the ALPN proposal is a start.
Though rather than just having it as a mere marker, it should incorporate features to securely indicate which domain label it is attempting to validate and achieve consensus on part of validator and the endpoint being validated.
I am hopeful such a scheme may be useful for future deployments down the road. I think it is likely before there is infrastructure in place utilizing a new mechanism of that kind that current needs will need to be met with one of the other mechanisms.
The speed and resource with which Let's Encrypt is working on solutions to migrate users to non-TLS-SNI validations might well be a signal.