dns caching is less than a 2 day cert (if sensible dns cache times set by you)
so your talking about a cdn you used to authorize suddenly becoming an attacker and dns cache poisoning to do so (as if switching from a cdn A to cdn B normally you expect to operate through both for whatever time you told ppl to dns cache for rather than have half your clients (seeing old dns) fail suddenly) if a planned move you would reduce the cache time from say 24h to 5mins, 24 hours prior to the swich, then at the time of the switch re-raise to 24 after testing new dns values work (so ideally after this 5 mins you can tell the old cdn to purge, most though most wait 24 hours for any bad isps who have told their caches to ignore your cache maximums if below their minimums, (very few nowdays)) either way your 'bad actor' cdn has 2 days with your cert 'fix' so it really dosnt 'fix' them also as your ex-cdn being a traceable legal entity (unlike anon blackhat hacker) is sue able easily so i cant see the real world case and as it really is becominng more edge by the second its way outside of a CAs purview to fix its the sort of thing i think is not a case for acme having normal or short term certs but for acme to allow CA to provide fixed term certs provider/CA X can decide themselves to profit from your use-scenario by offering normal user acme api (certs of nominal term) special user acme api (delivering all certs with a shorter fixed term) rather than having a selector in the design of the protocol for user custom terms, thus if wanting short lease certs pitch the idea to CAs and see if any is interested in doing business with you, equally finding a cdn willing to adjust their system to accommodate (nb a your chosen cdn like your chosen anti-malware provider should be wholey trusted, before use, to not become a hacker tomorrow, or your shopping for both based on the wrong criteria, as both can own you in ways you could never conceivably ever detect, and both rely on their good reputation/security to stay in business, trying to adjust acme, CAs , dns or any other protocol to make it easier to distrust a cdn is pointless, you have to trust them or build/operate your own there is no middle ground) At 19:12 25/07/2016 Monday, Yaron Sheffer wrote: >Hi Alan, > >Please refer back to my answer. We are talking MITM attacks here, not regular >operation. The attacker can spoof DNS, e.g. by colluding with a local ISP. > >Thanks, > Yaron > >On 25/07/16 20:36, Alan Doherty wrote: >>i have to ask how/why would you be sending the user to said cdn supplier (via >>dns) >>in the first place >>for them to see said expired cert (plus warnings if client gives them) >> >>i agree, user/owner sudden distrust of a previously trusted cdn is the worst >>possible reason to demand CAs provide a method to have insanely short (and >>thus more expensive to provide in terms of resources) certs available >> >>(renewal takes X resources, CA has resources to handle Y normal renewals per >>90 days) based on letsencrypt terms >>a 2 day cert is x*45 times the resources thus ,to handle the same amount of >>customers 45 times the server capacity and bandwith to operate >> >>i would suggest for the few requiring/demanding their chosen cdn salt earth >>and delete all data when they leave policy instead pay the extra at start to >>have explicit personalised terms of service drawn up with their cdn supplier >>they will terminate/delete/purge all data within x hours or notification >>instead >> >>rather than making the CA (and cdn) work harder (not smarter) every day just >>so they (the owner) can have less hassle the 1 day they quit >> >>automation may make repetitive tasks easier, but its still never good to >>repeat tasks more often unnecessarily just because automation has made it >>possible/easy >> >>(especially as a cdn will normally have a maxed out san cert on each ip to >>enable swapping/loadbalancing reassigning domains to servers on the fly, and >>thus 1 customer demanding a 2 day renewal basically causes all to be 2 day >>renewal) >> >> >> >>at 17:38 25/07/2016 Monday, Yaron Sheffer wrote: >>>I think we are slowly but surely getting into the weeds on this one. When we >>>talk about "CDN revocation" (for lack of a better term), we mean that after >>>a certain date, the owner of the content: >>> >>>- Does not want the CDN, or a rogue employee of the CDN, to present the >>>content as an authoritative source. If the user sees a big browser warning, >>>that would *not* look authoritative. >>> >>>- Does not want the CDN to be able to MITM the site for more sensitive >>>traffic, such as POST messages that contain user passwords. >>> >>>Short-term certs would handle this use case just fine. >>> >>>And as a content owner, it's really nice to able to leave a CDN whenever I >>>want to, without having to rely on it to keep my secrets for a few more >>>years while we no longer have a business relationship. >>> >>>Thanks, >>> Yaron >>> >>>_______________________________________________ >>>Acme mailing list >>>[email protected] >>>https://www.ietf.org/mailman/listinfo/acme > >_______________________________________________ >Acme mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
