again your talking about stuff unrelated to acme (and unlikely to potentially effect acme)
your talking about inherent problems with https (or all public key cryptography) (thus only addressable/fixable by https related ietf groups) acme cannot (and should not) expect its users to develop/run/use software with an otherwise completely non-standard https implementation (and thus missing any improvements/bug-fixes etc within wider https protocol/libraries) it uses https because its an existing/maintained/developed widely available protocol (and will improve with any underlying improvements to the base protocol) but acme is designed to use https not for security, just for transport its security is designed to be in the data sent/received so eavesdropping (mitm) cannot be advantageous to 3rd parties and yes many improvements could be added to https but as all automatable ones can be as effectively be intercepted by a suitably technically proficient mitm (if you check dns, mitm dns) if you check 3rd party (mitm 3rd pary) etc etc if its visual check key on a webpage (regexp replace good/bad key on all traffic to victim mitm his whole internet) only 100% secure method is out of band (phone sms etc. even these can be mitm if your a state level actor) thats why the improvements to https are made elsewhere and rigorously tested adopted/abandoned by that community thats why we rely on browsers/https libraries to secure themselves usually based on arrives with trusted keys, trusts updates to this list that are signed with an already trusted one imperfect but perfection is impossible (all we can add is hoops to jump, restrictions etc) but all automated public-key checks can obviously themselves be compromised if you have access to the client or wire At 13:52 23/10/2018 Tuesday, Kas wrote: >On 10/23/2018 2:47 PM, Salz, Rich wrote: >>> I don't know, there is many ways, but most likely someone will design an >> attack out of this and use it. >> >>If so (and I doubt it), such an attack would work on any web server/client >>combination, and is not specific to ACME. > >I don't have the mind set to think like an attacker, in internet security you >can be astonished how attackers think, but let say you can only manage to know >when a server (lets say university campus server) will request a certificate >then all what you need is to make sure dns pointed to your laptop, and >continue with the issuance the certificate, now you can utilize the CRL url in >your certificate to make the victim clients makes call to an illicit url, >monitored by the authority and that url let them download 50mb (crl request >doesn't have size limit), how the victims can explain their phones and laptops >downloaded such things, and here is the kick, the security software installed >on the PC might make that request, those requests are not monitored by the >system and most likely will bypass any firewall. > >I completely agree many of those attacks not specific to ACME, but with ACME >it's concerning the parties in contact with the victim, and ACME has the >ability to prevent and enhance the internet in overall. > >The core of the problem is with root store and who to trust, 15-20 years ago >downloading a root store and verify it was something alien and unaccepted, now >downloading 5mb can take few seconds and verifying it take way less, acme >server can issue certificates using more than one CA certificate even it might >have more than one root certificate, so why not to supply mini store so the >clients of acme server can communicate in secure manner without trusting the >system or any pre-supplied data, they just download the root store from >example.com and you are good to go, all what is needed is acme URL or DNS with >a key for DNSSEC or a key supplied by the ACME server itself. > >The current internet has well defined security protocols but in many cases >depends on weak points, while creating new draft for such lets say root store >will not go further than a draft or may be a RFC without adoption, and that >why acme protocol and this draft has the power to change all of that, i am not >calling for reinventing the wheel but to put a seed for better and secure >internet, this seed might replace the crippled wheel, this draft will be mass >adopted and i know this out of scope of this protocol intended usage, but >still it has the power and the opportunity to do so, and on top of that you >all who can make that happen, just think out of the box, and discuss this in >depth, will this be best practice or bad practice? will such expansion to this >protocol make the internet more secure or useless waste of time ? does such >extra measures to secure the certificate issuance contradict with other RFC or >enhance them? > > >Please don't only think about this as how to prevent an attack (one or many) >because what can go wrong will do, and this draft does have way more power and >ability to move things very far in security, and i trust you can do good by at >least discussing the big picture and how things will be in few years from now, >as whole current system is wired with human factor administrating few key >points, and all those secure castles are waiting for one CA server to fail and >this will disturb the whole internet to its core. _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
