Re: [Acme] Agenda topics -- draft
Heho, Kevin and I (me speaking) would appreciate a small slot (5-10m) to talk about our draft plans, is possible, see my other mail. Met vriendelijke groet, Dr.-Ing. Tobias Fiebig, Assistant Professor / Universitair Docent Department Engineering Systems and Services Informatie- en Communicatie Technologie (ICT) TU Delft / Dept. ESS Faculty of Technology, Policy and Management (TBM) Building 31 Jaffalaan 5 - room B3.170 2628 BX Delft P.O.Box 5015 2600 GA Delft, The Netherlands T +31 (0)15 27 85700 E mailto:t.fie...@tudelft.nl Present: Monday t/m Friday From: Acme On Behalf Of Salz, Rich Sent: Tuesday, October 16, 2018 2:23 PM To: acme@ietf.org Subject: [Acme] Agenda topics -- draft ACME is meeting at IETF 103 in the last session, Thursday II. 16:10-18:10 Draft agenda is as follows: Administrivia, 15 minutes Note well, jabber, minute-takers Brief updates, 15 minutes ACME, CAA challenge, IP identifier challenge, ALPN challenge STAR, 20 min Update as a result of the last-minute ACME changes, etc. Was already in WGLC; seeking a doc shepherd Email TLS certs and EMAIL end-user certs, 15 Who will read? Ready for WGLC? TN Authority Token documents, 20 Updates Any other business ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] ACME DV Security Considerations Draft
Dear all, At the IETF in Montreal, I presented findings on security issues with domain validation in ACME, and were encouraged to write a short draft outlining attacks and possible defenses. We now created a first draft, which outlines the general structure and contents we are aiming for, see https://datatracker.ietf.org/doc/draft-fiebig-acme-esecacme. We are looking forward to your input on our plans. Met vriendelijke groet, Dr.-Ing. Tobias Fiebig, Assistant Professor / Universitair Docent Department Engineering Systems and Services Informatie- en Communicatie Technologie (ICT) TU Delft / Dept. ESS Faculty of Technology, Policy and Management (TBM) Building 31 Jaffalaan 5 - room B3.170 2628 BX Delft P.O.Box 5015 2600 GA Delft, The Netherlands T +31 (0)15 27 85700 E t.fie...@tudelft.nl Present: Monday t/m Friday ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] ACME Operational best practices
Hi all, During the last couple of months, several papers and posts on attacking current domain validation techniques and practices were published. While some could be mitigated by DNSSEC and CAA validation, there are also several operational techniques that could be implemented to increase CA's security posture (https-validation for pre-issued certificates [0], multi-vantage-point validation [1], etc.). IIRC, Let's Encrypt is already experimenting with multi-vantage-point validation. Back when we submitted Cloud Strife [0] to NDSS, we reached out to the list on pushing our mitigations toward a recommendation/best practices RFC. Given that with the Birge-Lee paper, there is now a second attack vector, we (Kevin Borgolte and I, but we are open to more collaborators and already talked with Prateek Mittal from the BGP MitM paper [1]) would like to author a RFC on mitigating IP-use-after-free/IP-misuse attacks. This RFC would summarize the operational recommendations as well as how various other measures can (and cannot, CAA for example has to be configured correctly to be helpful) mitigate these attacks. However, before we dive into writing, we would like to get your feedback, hear your opinions and concerns, discuss on the list and in person (Kevin and I are in Montreal this week), and feel out whether you think that this is useful to the community to pursue. We are looking forward to your feedback and interesting discussions. Best, Tobias [0] Borgolte, Kevin, et al. "Cloud Strife: Mitigating the Security Risks of Domain-validated Certificates." Proceedings of Internet Society Symposium on Network and Distributed System Security (NDSS). 2018. [1] Birge-Lee, Henry, et al. "Bamboozling Certificate Authorities with BGP." 27th USENIX Security Symposium (USENIX Security 18). USENIX Association. Met vriendelijke groet, Dr.-Ing. Tobias Fiebig, Assistant Professor / Universitair Docent Department Engineering Systems and Services Informatie- en Communicatie Technologie (ICT) TU Delft / Dept. ESS Faculty of Technology, Policy and Management (TBM) Building 31 Jaffalaan 5 - room B3.170 2628 BX Delft P.O.Box 5015 2600 GA Delft, The Netherlands T +31 (0)15 27 85700 E t.fie...@tudelft.nl Present: Monday t/m Friday ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Stale DNS and high-risk issuance
Hello Ilari, > [1] Just as example, the following kinds of stuff are (legimately) seen fairly > often or more: > > > - Rolling over the account key for each renewal (this is usually caused > by containers forgetting things). > - Rolling over the TLS key for each renewal (some actually recommend > this, I do not). Sometimes with very frequent renewals. > - Getting multiple certificates with different keys for multiple > servers with the same name. > - Handling validation on separate system and pushing the certificates > (and likely the TLS keys too, probably not in safe manner!) to server > systems. These systems might utilize HTTP redirects (which HTTP-01 > does follow) or DNS CNAMEs (which DNS-01 does follow). > - Users wiping out the TLS keys and account keys (without backup!) to > "reset" something (admin mistake). > - Transferring site between servers and losing the keys (account and > TLS) in the process. > - Users using all sorts of whacky ACME clients that just do not > implement anything more than bare minimum for the common case. > - Users using HTTPS on servers they don't have proper control of > DNS for (can't edit records, or can only use very few record > types, at worst only A/, or worse yet, A only). > > Thinking about recovery is rather important. One of the major reasons HPKP > is so hated is lack of pretty much any kind of recovery. I am seriously interested in surveying this kind of behavior, not only to quantify it, but also to understand MOs during systems' operation. While some of these cases seem relatively easy to measure (yet sometimes not to distinguish, i.e., cases 1 and 2), others seem to be harder harder to measure, e.g., the 4th case. The main problem here is that this would certainly require cooperation from LE. What are your thoughts on this? > [2] This was actually one of the major reasons why the PoP challenge was > removed. Well, technically it should be sufficient to do the channel over HTTPs to reach the same result in comparison to actually signing the challenge. Met vriendelijke groet, Tobias Fiebig, Department Engineering Systems and Services Informatie- en Communicatie Technologie (ICT) TU Delft / Dept. ESS Faculty of Technology, Policy and Management (TBM) Building 31 Jaffalaan 5 - room B3.170 2628 BX Delft P.O.Box 5015 2600 GA Delft, The Netherlands T +31 (0)15 27 85700 E t.fie...@tudelft.nl Present: Monday t/m Friday ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
