Re: [Acme] dns-01 challenge limitations
Simon Ser said: > > Are there specific reasons why dns-01 requires updating a DNS > record? > > > > Yes, because it proves you control the zone. > Right, but there could be other ways to prove this as well. care to share? what other methods are there to prove that you have access to the DNS zone RIGHT NOW. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] dns-01 challenge limitations
maybe one could make it so an email specific to the domain that is verified could be used instead to just screw the entire DNS thing? I mean CAs have used e-Mail based issuance over the address in the whois (no longer practical due to increase of whois privacy by default) or the standardized hostmaster etc addresses. that way any given acme client would only need access to the inbox of that specific mail which probably is a whole lot easier than DNS stuff. Am So., 13. Sept. 2020 um 11:13 Uhr schrieb Simon Ser : > > On Friday, September 11, 2020 4:26 PM, Ryan Sleevi > wrote: > > > > > On Fri, Sep 11, 2020 at 9:28 AM Philipp Junghannß < > teamhydro55...@gmail.com> wrote: > > > > > > > problem is obviously also the CA/Browser Forum has certain > requirements, > > > > and I guess having access to some kind of direct verification at the > time > > > > of issue might be probably one of these. > > > > > > This is the correct answer. > > > > > > While the IETF can certainly explore developing voluntary standards for > > > other methods, the ability for CAs to adopt these methods is limited > by CAs > > > customers: the browsers and operating systems that include and use CAs > to > > > validate domain names on their behalf. > > > > > > The explicit goal by several browser/OS vendors is to obtain a fresh > proof > > > of control over a domain, and reduce/eliminate any caching or reuse. > > > Delegation (by keys or persistent records) is definitely an area of > > > expressed concern. > > My take is that in theory it's an understandable goal, but that in > practice, > this detoriorates security. > > In practice, ACME clients: > > 1. Have a static, long-term token stored in their configuration file > 2. The token is powerful and can update any DNS record in the zone > > How come browser/OS vendors are fine with this, but not with a different > approach involving an ACME-specific key? > > Sure, since this happens behind the ACME/DNS protocols and is an > implementation > detail, this isn't ACME's responsibility anymore. However, because > browsers/OS > vendors have this requirement of not allowing delegated proofs, we end up > with > a worse situation than necessary. > > Ultimately, ACME clients need a way to update DNS records to solve the > dns-01 > challenge. Ignoring and pushing the problem down to the DNS operators does > not > fix the root cause. > > If an ACME client needs to prove that they have authority over a DNS zone, > they > will need some kind of authorization/key/token or similar, be it > vendor-specific or not. Why not acknowlege this fact and come up with a > reasonable standard? > > > > I think the suggest of more uniform APIs for managing DNS is very much > in > > > line with those goals, and would help far more than ACME. > > Yes, no matter what ACME requires, a standardized API to update DNS records > would be nice. Michael Richardson suggested that such an API (or a subset > of) > already exists (via secure DDNS), but isn't supported by most DNS operators > (even if supported by some DNS daemons). > > Establishing a new standard involves talking to existing DNS operators, > and ask > them to implement the new standard. For them, the new standard wouldn't > have a > high enough return on investment: ACME clients already volunteer to > implement > each and every proprietary API. Even if a good standard ticking the > checkboxes > of RFC 5218 existed, I don't think it would be successful (no "Positive Net > Value" for DNS operators). > > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] dns-01 challenge limitations
well Certificate transparency is one something should maybe keep notifications for. Also I can understand the problem, but I have not decided the outcome, I merely stated what I got as an answer back then. problem is obviously also the CA/Browser Forum has certain requirements, and I guess having access to some kind of direct verification at the time of issue might be probably one of these. Am Fr., 11. Sept. 2020 um 15:21 Uhr schrieb Simon Ser : > Hi, > > On Friday, September 11, 2020 3:13 PM, Philipp Junghannß < > teamhydro55...@gmail.com> wrote: > > > I have asked that question in the LE forum iirc the problem is that > > someone could place that record once and as long as someone doesnt > > look at it all the time one can easily miss the fact that someone can > > create wildcards and stuff for that domain, so the point is to prove > > that dns access is given at the time of issuance. > > If someone has once write access to the DNS, they can set an > acme-challenge record, redirect all requests, and issue wildcard certs. > That would be easy to miss, too. > > > you could maybe use a different DNS Server which has a better API, > > and potentially even can be used by ACME. > > The issue at hand isn't that a particular DNS registry operator isn't > supported by a particular ACME client. What I want to fix is the need > for all ACME clients to support all DNS registry operators. > > Thanks, > > Simon > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] dns-01 challenge limitations
I have asked that question in the LE forum iirc the problem is that someone could place that record once and as long as someone doesnt look at it all the time one can easily miss the fact that someone can create wildcards and stuff for that domain, so the point is to prove that dns access is given at the time of issuance. you could maybe use a different DNS Server which has a better API, and potentially even can be used by ACME. Regards Am Fr., 11. Sept. 2020 um 15:09 Uhr schrieb Simon Ser : > Hi all, > > I've been working on an ACME client acting as a TLS termination proxy. In > order > to retrieve wildcard certificates from the Let's Encrypt ACME servers, > support > for the dns-01 challenge is required. > > dns-01 requires the ACME client to complete the challenge by updating a DNS > record. This is bothersome because this often requires interacting with the > DNS registry operator. This is typically done via vendor-specific APIs, > with > access control handled via vendor-specific means (tokens, public keys, > etc). > > I understand that it's difficult for ACME clients to prove that they are > authorized to obtain wildcard certificates. However, have other > alternatives > been considered? > > For instance, it would be possible to require users to add a short public > key > in a DNS TXT record, then ask the ACME client to sign challenges with that > key. > Something like this would significantly ease the development of ACME > clients. > > Are there specific reasons why dns-01 requires updating a DNS record? > > Thanks, > > Simon Ser > > (CC mholt, I figured you might be interested in this for Caddy too) > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] { "cassandrahernandez...@gmail.com" }
how about you first explain what you are eventalking about, instead of just coming around with a list and saying that they are all bad people? also in what way is this related to the ACME mailing list? Regards Am Sa., 7. März 2020 um 22:39 Uhr schrieb mar isa her < cassandrahernandez...@gmail.com>: > These are all bad people. > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Certificate chains including roots
But isn't the point of this proposal that the client CANNOT be expected knowing the root like with DANE/TLSA'd servers with a custom root or whatever? Am 12.03.2018 15:57 schrieb "Jörn Heissler" : > On Mon, Mar 12, 2018 at 12:25:14 +, Hugo Landau wrote: > > 1. Clarify the specification to state that the root certificate must > > always appear in the chain at the end. Clients should be advised to > > pop the root certificate if they are procuring certificate chains > > for non-DANE applications only. Failure to do so will result in > > unnecessary but harmless transmission of the root certificate > > during TLS handshakes. > > > > 2. Don't include the root certificate but provide a way to retrieve it, > > e.g. via a Link header. > > > > 3. Clarify the specification to state that the root certificate must > > not appear in the chain, and that roots must be retrieved using the > > AIA URL inside the final certificate in the chain if it is needed. > > This minimises the chance of clients for non-DANE applications > > messing up and provides a viable method for discovery of the root > > CA for applications which need it. > > > > I'd support option 1 or option 3 equally. Either way, I think this > > should be clarified. > > > > Thoughts? > > There's one more option which I'd actually prefer. > > 4. Root certificate does not appear in the chain but it's expected > that clients already know it. E.g. look in /etc/ssl/certs/. > > Rationale is that the client shouldn't blindly trust that the chain > received by the acme server is valid. > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Idea about automated OV validation
well true passports/ID cards are intresting although there's alayes the problem about the access structure and so on. German ID cards for example can only be read with a certificate from a "permission certificate authority", which are most probably selected by the gov and I wouldnt expect those permission certs to come cheap, they also require documentation about how the company handles privacy and so on and so on, add some more countries with their own respective systems into the mix and we have pure chaos. I doubt a non-profit CA like LE could do that well. 2017-12-01 15:21 GMT+01:00 Sebastian Nielsen : > Also could be done by having a interface where you scan your passport with > a NFC compatible reader (both mobile phone and desktop NFC reader could be > supported) and the government-signed data is uploaded. > > > > So automated validation for private IV certs could be done too (IV = > Individual certs). So free code signing and IV validated certs. > > > > https://community.letsencrypt.org/t/iv-certificates-both- > server-and-code-via-automated-nfc-passport-id-validation/44838 > > > > *Från:* Acme [mailto:acme-boun...@ietf.org] *För *Philipp Junghannß > *Skickat:* den 1 december 2017 14:57 > *Till:* Matthias Merkel > *Kopia:* IETF ACME > *Ämne:* Re: [Acme] Idea about automated OV validation > > > > if that's what other CAs do that's not a bad Idea although there's of > course the question whether there are some other manual checks needed. > > > > but cheap to almost free OVs/code signing certs would be great although > that sadly doesnt make it easier for normal people without a company to get > IVs or code signing certs, but the Idea is certainly not bad. > > > > 2017-12-01 14:53 GMT+01:00 Matthias Merkel : > > I had the following idea about automating verification and issuance of OV > SSL certificates: Couldn't a CA in theory use the D&B API to check the > company name, address and phone number and then place an automatic call? > That's basically what most CAs do anyways so is there any reason why they > couldn't do it? That would also be a way for Let's Encrypt to issue OV > certificates and code signing certificates. > > > > > > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Idea about automated OV validation
if that's what other CAs do that's not a bad Idea although there's of course the question whether there are some other manual checks needed. but cheap to almost free OVs/code signing certs would be great although that sadly doesnt make it easier for normal people without a company to get IVs or code signing certs, but the Idea is certainly not bad. 2017-12-01 14:53 GMT+01:00 Matthias Merkel : > I had the following idea about automating verification and issuance of OV > SSL certificates: Couldn't a CA in theory use the D&B API to check the > company name, address and phone number and then place an automatic call? > That's basically what most CAs do anyways so is there any reason why they > couldn't do it? That would also be a way for Let's Encrypt to issue OV > certificates and code signing certificates. > > > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Looking for comments on https://github.com/ietf-wg-acme/acme/issues/215
well I think it's a bad idea. as I commented in the issue directly TLS-SNI-01 fell straight on the face because of the way servers may handle hosts without a setting. 2016-12-03 13:35 GMT+01:00 Patrick Figel : > I wrote together some thoughts on this proposal here[1]. In short, I think > it's > vulnerable to the default vhost attack that caused simpleHTTP to be > dropped, and > it's not compatible with the "Agreed-Upon Change to Website" method > described > in the BRs, which would prevent adoption by any publicly-trusted CA. > > The proposed workaround for this issue[2] would make this a variant of > tls-sni, > AIUI, which already has these pseudo-hostnames, so I think we're down to > "allow > other ports" here, and I believe there's consensus against this. > > Patrick > > [1]: https://mailarchive.ietf.org/arch/msg/acme/ > QiXu84RJtURfGVVEYfSpRdtcU5o > [2]: https://mailarchive.ietf.org/arch/msg/acme/ > NFKJ5sqBePGlJglKRwodc5m4ZEo > > On Sat, Dec 3, 2016 at 3:18 AM, Salz, Rich wrote: > > With the couple of recent pull requests, the document editors are about > to > > close all but on issue, #215. > > > > > > > > Does the WG have any feelings on this? Is it something we need to > address > > NOW, or can we add a new type of challenge later on if there’s interest? > > > > > > > > Please reply on-list by earl next week. > > > > > > > > -- > > > > Senior Architect, Akamai Technologies > > > > Member, OpenSSL Dev Team > > > > IM: richs...@jabber.at Twitter: RichSalz > > > > > > > > > > ___ > > Acme mailing list > > Acme@ietf.org > > https://www.ietf.org/mailman/listinfo/acme > > > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Nonces and replay attacks
well wouldnt make much sense to use a nonce in the first place, if it isnt in the signature. but a nonce is a number which should only be used once, and since it's generated at random, there is no reason why the server shoudnt throw a proper nonce e.g. if the randomizer of Alice's system is crap or whatever. 2016-11-25 17:36 GMT+01:00 Sam Kuper : > Hi Daniel, > > On 25/11/2016, Daniel McCarney wrote: > > I can see no good reason for this to be "SHOULD" rather than "MUST". > >> Please can it be changed to "MUST"? Otherwise, a client might have no > >> way of knowing why the request failed, and therefore no reasonable way > >> to proceed. > > > > This seems reasonable, I would also be supportive of a change like this. > > Excellent. Thank you. > > >> That looks dangerous to me. If the server implements the requirement > >> above, then when Mallory's attempt to replay Alice's request has just > >> failed, the server will reply with a fresh nonce, thereby > >> potentially giving Mallory the means to usurp Alice's session. Ouch! > > > > You start by talking about an adversary that is replaying existing > > messages, > > which causes the badNonce error when the request is replayed the second > > time. But when you say "potentially giving Mallory the means to usurp > > Alice's session", that would require the adversary construct a new signed > > message using the nonce without the participation of Alice - this > shouldn't > > be > > possible in the MITM threat model that the nonce usage is meant to > address. > > Ah, indeed, if the request must contain the new nonce and be signed > with Alice's private key, then you are correct, and my previous reply > (to Philipp) was overly hasty. > > Thanks for your explanation, and apologies to Philipp for my > misunderstanding. > > Sam > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Nonces and replay attacks
Doesnt the request have to be signed and stuff anyway by the account key? Am 25.11.2016 16:44 schrieb "Sam Kuper" : > Dear all, > > I am new to this mailing list, and am likewise new to reading the draft > ACME protocol with a critical eye. I hope to avoid committing any > blunders, but ask your forbearance for my newness, should I fail. > > draft-ietf-acme-acme-04, section 5.5 contains two pieces of text that I > think could be improved. These improvements would be substantive to the > protocol, not merely editorial, which is why I am raising them on the > mailing list. > > The first piece of text is this: > > > When a server rejects a request because its nonce value was > > unacceptable (or not present), it SHOULD provide HTTP status code 400 > > (Bad Request), and indicate the ACME error code > > "urn:ietf:params:acme:error:badNonce". > > I can see no good reason for this to be "SHOULD" rather than "MUST". > Please can it be changed to "MUST"? Otherwise, a client might have no > way of knowing why the request failed, and therefore no reasonable way > to proceed. > > The second piece of text is this: > > > An error response with the "badNonce" error code MUST include a > > Replay-Nonce header with a fresh nonce. On receiving such a response, > > a client SHOULD retry the request using the new nonce. > > That looks dangerous to me. If the server implements the requirement > above, then when Mallory's attempt to replay Alice's request has just > failed, the server will reply with a fresh nonce, thereby > potentially giving Mallory the means to usurp Alice's session. Ouch! > > That being so, a suitable replacement for the second piece of text > quoted above would be: > > > An error response with the "badNonce" error code MUST NOT include a > > Replay-Nonce header with a fresh nonce. On receiving such a response, > > a client SHOULD log it and attempt to notify its human operator that > > the server has reported evidence of a replay attack. > > Best wishes, > > Sam > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] IDN encoding
shouldnt IDNs just get Punycoded? at least that's the common standard for IDN stuff iirc. 2016-08-30 0:51 GMT+02:00 Roland Bracewell Shoemaker : > I'd be interested in hearing peoples thoughts about this PR which adds > language about how IDNs should be encoded by clients who wish to use > them as identifier values. > > https://github.com/ietf-wg-acme/acme/pull/184 > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Support issuing certificates to subdomains when top level domain-ownership can be verified
well I brought this already up as "walk-up authorisations" or similar. Rich Salz brought up domains like wordpress.com and github.io as examples where the parent shouldnt get certs with another check, but I personally think that this is junk. this is (obviously) because the parent could take control of the subdomain and verify it anyway that's just how the system works. not allowing a walk up for subs just makes it more annoying. also talking about cache-poisoning and other funny stuff, one could say that walk up only can occur only in certain conditions, for example that there needs a flag set as a record in DNS and secured by DNSSec and the CA could easily check the DNSSec. also unlike the CA system DNSSec works with a tree-like structure so it's pretty limited on who can sign for what. for example for the domain "google.com" there are only 3 entities that can sign for it. one is obviously Google themselves, then we have the Management of the .com DNSSec key and finnaly (obviously enough) the ICANN with the root key. so one could say that if the authorisation is done via DNSSec'ed DNS authorisation plus a record indicating walk-up it would be fine enough and that would be pretty strict. it may be that in some cases the subdomains are controlled by another entity but it isnt a secret that the parent can take control anyway. That's just my opinin. Best regards (or for all the german readers, MFG) Philipp Junghannß / My1 2016-07-26 22:34 GMT+02:00 Ted Hardie : > On Tue, Jul 26, 2016 at 1:13 PM, Richard Barnes wrote: > >> >> >> On Tue, Jul 26, 2016 at 6:48 PM, Patrick Figel >> wrote: >> >>> On 26/07/16 18:00, Peter Bowen wrote: >>> > I don't see anything in the ACME specification that disallows this >>> > at the protocol level. I think a CA could request you validate a >>> > DNS identifier of 'example.com', then accept that authorization for >>> > the issuance of 'ship.example.com'. Conversely, ACME does not >>> > require CAs allow such and I hope it stays that way. CA policy >>> > should be distinct from ACME. >>> >>> Agreed that this should be a policy decision. >> >> >> +1 >> > > So, it's more than a policy decision, unfortunately; it's a combination of > two properties of the DNS that are problematic. The first is that control > of a specific label has no easily generalized implication about > administrative control of subsidiary labels. The IAB controls .ARPA, for > example, but has delegated e164.arpa in a way that would make allowing the > IAB to request certificates for delegations under it to be a pretty > problem. The same problem occurs for many gTLDs, ccTLDs, and a number of > second level domains. The work in the DBOUND working group also notes > this in describing delegation > <https://datatracker.ietf.org/doc/draft-deccio-dbound-organizational-domain-policy/?include_text=1> > : > > "However, policies governing the use of domain names do not always align > with those lines of delegation. There are currently no generally reliable > methods to reconcile domain names with policy for their use." > > They are working on the problem, of course, but it is still a problem. > > The second issue is that this seriously worsens the cache poisoning > attack; if you manage to cache poison the CA's view of the hierarchical > ancestor, you would now be able to generate certificates for all its > descendants. > > So, while I agree that this is a policy issue, I believe that the > specification should have a statement that the default should be > restrictive and why. I don't think that the text should be in an appendix, > frankly, but should be pretty much front and center with appropriate > warnings. > > (as an individual) > > Ted > >> >> >>> It's worth pointing out, >>> however, that prior drafts contained language that made it clear that >>> it's a policy decision, which seems to have been removed in the acme-03 >>> draft. It used to read: >>> "It is up to the server's local policy to decide which names are >>> acceptable in a certificate, given the authorizations that the server >>> associates with the client's account key." >>> >>> Was this removed deliberately, or did it get lost as part >>> of the "Application" change? I think it would make sense to add >>> something like that to the CA Policy Considerations section, just to >>> make it clear that this is indeed a policy decision (unless the WG >>> thinks otherwise?) >>> >> >> It was a
Re: [Acme] Account deactivation
I dont even exactly know whether the right to be forgotten works with data that isnt even public. my personal opinion on this is that if no certs get revoked that all account data stays unil the certs expire. this right was mostly executed on google and their results are public. but your ACME Account data (e.g. your IP Addresses, domains etc) are all private because nobody can just say "what domains does User X have" or whatever. also if there are any laws regarding data retention or anything else regarding liability and stuff it wouldnt be wise to delete data regarding that. also as Rich Salz already said, ACME cant deal with any weird geographic law. I have no Idea what a "Calea" is, but the laws regarding that "Calea" thing are probably also something ACME cannot really account for. that's my opinion. Regards. 2016-05-24 1:07 GMT+02:00 Salz, Rich : > > Let me explain a bit more: Shall a CA receive a valid and trustworthy > request for deletion of an account/authorization, the CA must totally erase > any trace of data regarding that account > > Speaking as a WG chair, I disagree. EU data retention, like US Calea > laws, are outside the scope of the protocol. > > > CAs follow the best interests of the users, don't they? > > As commercial vendors, their shareholders should come first. > > Speaking as an individual, I support the MR. > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Comment on draft-landau-acme-caa-00
but then again, a key enforcement can also allow for this key not needing to prove a challenge since it already IS approved. 2016-04-22 14:50 GMT+02:00 Yaron Sheffer : > Hi, > > I support tightening ACME with additional security controls, and the > Account Key seems like a good place to start. But given that we have a > DNS-based authorization method, this proposal looks like overkill. > > If the attacker has access to the DNS zone for the host being certified, > then they can use this access (with DNS-01) to issue a certificate. > Moreover, they can change the CAA record or add new ones, making this > protection moot. (Reminder: CAA records are evaluated "bottom up", i.e. the > most specific one wins). > > If the attacker does not have access to the DNS zone, the proposed > protection becomes interesting. But then a simpler, easier to manage > solution would be to limit the allowed challenges. So maybe instead of > specifying an account key, use > > example.com. IN CAA 0 issue "example.net; \ > acme-ac=dns-01 > > (where "ac" is Allowed Challenge). This would mandate that the CA only use > DNS-01 and no other challenge, ensuring that the ACME client must prove > control of DNS. > > Thanks, > Yaron > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] [acme] Account deletion for security currently useless if rolled over
Okay didnt know that one yet. Am 18.04.2016 18:32 schrieb "Richard Barnes" : > You can already revoke with the cert key. > > On Mon, Apr 18, 2016 at 12:30 PM, Philipp Junghannß < > teamhydro55...@gmail.com> wrote: > >> In my opinion it would be also nice if you could revoke with the cert key >> making it possible to remove the cert even if the acc is down. >> Am 18.04.2016 18:15 schrieb "sheel.at" : >> >>> Suppose an account key gets compromised. To prevent abuse, the owner can >>> delete the account: >>> >>> https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md#deleting-an-account >>> However, people having the key can simply change it without any effort: >>> >>> https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md#account-key-roll-over >>> >>> What happens if the attacker does so before the owner can react, or even >>> before the owner notices anything of the breach? >>> >>> I suggest changing tha specs (and implementation) to keep old keys after >>> changes for while. More specifically: >>> * When an account key is rolled over, the old key is kept for eg. 30 >>> days. >>> * Multiple changes within this 30 days mean that there are multiple old >>> keys. >>> * Account deletion is possible with any of the saved keys, be it old or >>> new. >>> * Everything else (other than account deletion) only accepts the new >>> (newest) key. >>> >>> Related: >>> The owner has no possibiliy to revoke certificates issued by the >>> attacker. For proper uses, nuking all certs when deleting the account >>> might be not what the users like, but for the attack scenarion... >>> >>> Related 2 (yeah, it's getting bothersome) >>> If there is an "optional" certificate nuking when deleting accounts, the >>> attacker could issue certificates and then delete the accountwithout >>> destroying the certificates(the attacker!), to prevent the real owner >>> from destroying the certificates. Meaning, a "partially" deleted account >>> has to stay around for ... as long as there are non-expired >>> certificates?, just for the possibility that someone wants to delete the >>> rest too. (But without being useful for anything else other than >>> deleting) >>> >>> ... >>> I'm rather new to the Let'sEncrypt internals, so if I missed the fact >>> that there is a solution already, please forgive me. >>> >>> Otherwise, sorry, I know spec'ing and implementing this would be >>> annoying. But without this, the possibility for deleting an account key >>> is not particularly useful. >>> >>> >>> ___ >>> Acme mailing list >>> Acme@ietf.org >>> https://www.ietf.org/mailman/listinfo/acme >>> >> >> ___ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> >> > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] [acme] Account deletion for security currently useless if rolled over
In my opinion it would be also nice if you could revoke with the cert key making it possible to remove the cert even if the acc is down. Am 18.04.2016 18:15 schrieb "sheel.at" : > Suppose an account key gets compromised. To prevent abuse, the owner can > delete the account: > > https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md#deleting-an-account > However, people having the key can simply change it without any effort: > > https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md#account-key-roll-over > > What happens if the attacker does so before the owner can react, or even > before the owner notices anything of the breach? > > I suggest changing tha specs (and implementation) to keep old keys after > changes for while. More specifically: > * When an account key is rolled over, the old key is kept for eg. 30 days. > * Multiple changes within this 30 days mean that there are multiple old > keys. > * Account deletion is possible with any of the saved keys, be it old or > new. > * Everything else (other than account deletion) only accepts the new > (newest) key. > > Related: > The owner has no possibiliy to revoke certificates issued by the > attacker. For proper uses, nuking all certs when deleting the account > might be not what the users like, but for the attack scenarion... > > Related 2 (yeah, it's getting bothersome) > If there is an "optional" certificate nuking when deleting accounts, the > attacker could issue certificates and then delete the accountwithout > destroying the certificates(the attacker!), to prevent the real owner > from destroying the certificates. Meaning, a "partially" deleted account > has to stay around for ... as long as there are non-expired > certificates?, just for the possibility that someone wants to delete the > rest too. (But without being useful for anything else other than deleting) > > ... > I'm rather new to the Let'sEncrypt internals, so if I missed the fact > that there is a solution already, please forgive me. > > Otherwise, sorry, I know spec'ing and implementing this would be > annoying. But without this, the possibility for deleting an account key > is not particularly useful. > > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Exposed rate limits
wait a sec you *do* have overrides for LE? it was iirc stated often enough that nothing can be done about rate limits... 2016-03-22 0:11 GMT+01:00 Jacob Hoffman-Andrews : > On 03/21/2016 04:05 PM, Phillip Hallam-Baker wrote: > > What is an abusive rate may depend on the source. Some large ISPs > > might generate a number of requests that might be considered a DoS > > attack coming from a residential IP. > Agreed. How we manage this within Let's Encrypt is to have a set of rate > limit overrides to deal with legitimate heavy users. > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Exposed rate limits
well My idea would be: display the most restrictive by default. add option to list all. about the code vs readable message I would think of a hybrid approach. apply a code and a message. the code coule be used so the client if it knows it that it could e.g. translate it into different languges etc. and the embedded message copes with all clients that dont know the code yet, also add a code for "other" which can be used for stuff that doesnt have a code yet 2016-03-21 23:51 GMT+01:00 J.C. Jones : > On Mon, Mar 21, 2016 at 3:45 PM, Niklas Keller wrote: > > Will it be possible to standardize all names? Other CAs may use other > rate > > limits. So should `RateLimit-Name` be a code or a human readable message? > > My guess is that getting an exhaustive list of rate limits would be > difficult, and that implementing CAs may want to adjust these values > quickly outside IETF. > > It's probably good to leave flexibility it in, if we can. Further thought: > Instead of or in addition to a name, there could be a URI to a description > or help document. > > Cheers, > > - J.C. > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] HTTP and DNS Challenge string
there are iirc no multi name http-01 and dns-01. you have to do each one on its own. 2016-03-21 20:43 GMT+01:00 Ilari Liusvaara : > On Mon, Mar 21, 2016 at 03:36:49PM -0400, Richard Barnes wrote: > > Having the token also lets the validation server operator specify which > > names the key is being authorized for. I might have virtual hosting box > > with 200 names on it; I don't want to authorize any given key for all of > > them. > > Huh? Aren't authorization lookups inherently per-name (outside ones > specifically desinged to cover multiple names), so admins/servers can > authorize keys on per-name basis? > > > -Ilari > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] HTTP and DNS Challenge string
that should pretty much what it will be about. 2016-03-21 11:03 GMT+01:00 Thomas Lußnig : > Currently > > 1) Client->Server Request(domain.xy) => Response(nonce to be signed) > --> Server fetch CAA record > 2) Client->Server Request(Please check via dns/http) > --> Server check resouce > 3*) Client->Server Is the Check complete(Please check via dns/http) > > > My Idea > > 1) Client->Server Request(domain.xy) => Response(nonce to be signed) > --> Server fetch CAA record + DNS(acme.pubkey.domain.xy) to get the PIN of > account key > 2) Client->Server Request(Signed nonce with private key, Public Key) => > Response(Sucess/Failed) > > > > > Am 21.03.2016 um 10:34 schrieb Philipp Junghannß: > >> to sign an extra random value because it should probably have signed one >> when trying to request the cert so they can just check for the >> > > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] HTTP and DNS Challenge string
I didnt even specify a direct order in the first place but the client could tell the user on how to do the stuff if there is no key. pre-publishing is one of the reasons for this since it also allows you to delegate a subdomain to someone else in DNS challenge without having to wait for a challenge. also you even need to sign an extra random value because it should probably have signed one when trying to request the cert so they can just check for the records/keyfile and compare the signature. regards. 2016-03-21 10:29 GMT+01:00 Thomas Lußnig : > Hi Philipp, > > why not switch the handling. > Publish the Fingerprint of your public Key in DNS/WEB. > And the challenge is then to sign the random value with your public key. > This would also speed up the whole process. Since the acme server > can get the pub key when you request the domain and check than your > response. > And not you tell him check the webpage now and wait till he checked the > page. > > Gruß Thomas > > > Am 21.03.2016 um 09:42 schrieb Philipp Junghannß: > > hello, I have a little proposal: > > https://github.com/ietf-wg-acme/acme/issues/88 > > in short, I see not THAT much reason to use a completely random string for > the challenges, I think it would be better to just use your account key. > the only thing random keys are is increase annoyance when you cannot work > automatically (try manually posting 14 challenges from SSH to your web > folder and you'll get my point) > > my Idea is that instead of a random string you rather use your account key > (or a hash of it) as the challenge. with that you dont always have to > create and delete challenge records because you can just let it stay there > which essentially also lowers the strain of DNS Servers during renewal > times (in case of DNS validation) > > also the servers of the ACME-CA will also have less strain because they > dont need to send extra challenges and check those, because the possession > of the key is already proven because it needs to sign every request to the > ACME protocol, that's why it makes sense to just use the esatblished > identity instead of establishing something completely new and then linking > it. They just need to download the key file/records and check whether the > key we want is inside > > also when you want to create a SAN cert with http challenge for multiple > webroots you can just copypaste the same file to all webroots and the > automation doesnt have to worry about anything else. > > best regards. > > > ___ > Acme mailing listAcme@ietf.orghttps://www.ietf.org/mailman/listinfo/acme > > > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Exposed rate limits
adding to this some parts of rate limits should be maybe made a bit clearer if not already (e.g. if you have multiple different domains in a SAN which will get the count, just the CN? or all of them? also it would be nice to add a command that gives you the ability to check the limits before even thinking of creating a cert. 2016-03-21 9:28 GMT+01:00 Niklas Keller : > Morning, > > I added a PR exposing potential rate limits to clients. Rate limits can be > used to show warnings to the user, e.g. when certificate issuance is > limited to 5 certificates per 7 days and you already issued 3. A single > client can't count these, because they may be on different servers using > different clients. > > https://github.com/ietf-wg-acme/acme/pull/104 > > Best Regards, > Niklas Keller > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Quick feedback on two PRs
as the situation is now I am against removing the PoP becase it is really helpful when the automation cannot do its thing (there are so many reasons why you cant really automate everything. but when there will be some other changes to the challenges which would make it a bit more humanly possible to create a SAN certificate with more than just 2 domains. regards 2016-03-21 3:14 GMT+01:00 Richard Barnes : > Hey all, > > I've published a two PRs that I think should be non-controversial, but > they're significant enough that I wanted to run them by the group. I would > appreciate it if you could take a look and give a quick thumbs up / thumbs > down in Github (at the indicated URIs). If you have any substantive > comments, please reply in this thread. > > #101 Remove proof-of-possession challenge > https://github.com/ietf-wg-acme/acme/pull/101 > > #102 Replace in-band account recovery with `meta` > https://github.com/ietf-wg-acme/acme/pull/102 > > I'm happy to hold any of these if they need more discussion, but if > there's no disagreement before the I-D deadline at midnight UTC, I'll go > ahead and merge them before I post -02. > > Thanks, > --Richard > > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] wildcard validation
I think so too. but I also think that while talking about wildcard validation in DNS that it would be pretty intresting to bring this up: https://github.com/ietf-wg-acme/acme/issues/89 in short, this would let the dns-challenge walk up meaning that if you already have completed the challenge for a higher level domain you can automatically also count as authorized for a subdomain. this would also be nice because the randomness of the token makes it REALLY annoying to create a large SAN cert in a manual environment (e.g. there's no proper client for your use-case, machine etc.) before the DNS Challenge was a thing I had to copy the strings for webroot/http-01 auth from my SSH to my computer (while making sure not to hit ctrl-c because it doesnt copy but cancel in terminal, making it even more annoying as it already is.) Regards. 2016-03-21 9:02 GMT+01:00 Niklas Keller : > i would propose for either http or dns verification requiring at least a >> temporary wilcard in dns >> then for the verification server to either lookup >> >> http://random-generated.domain.tld/.well-known/acme-challenge/challenge-string > > > That's not possible, because several providers allow the registration of > any subdomain, e.g. DynDNS providers. > > >> dns verification is trickyer but could require instead of >> _acme-challenge.example.com. 300 IN TXT "token" >> >> _acme-challenge.challenge-string.example.com. 300 IN TXT "token" >> > > For DNS challenges, I think it's fine when _acme-challenge.example.com > authorizes *.example.com. > > >> for example or >> _acme-challenge._wildcard_.example.com. 300 IN TXT "token" >> >> or to demon straight ability to create wildcards >> random-generated._acme-challenge.example.com. 300 IN TXT "token" >> >> as this would require the applicant setup >> *._acme-challenge.example.com. >> >> >> i hope this is the right place if not please feel free to redirect me, as >> either way acme is a huge leap forward in cert issuance and improving >> reliability through automation >> > > Regards, Niklas > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] HTTP and DNS Challenge string
hello, I have a little proposal: https://github.com/ietf-wg-acme/acme/issues/88 in short, I see not THAT much reason to use a completely random string for the challenges, I think it would be better to just use your account key. the only thing random keys are is increase annoyance when you cannot work automatically (try manually posting 14 challenges from SSH to your web folder and you'll get my point) my Idea is that instead of a random string you rather use your account key (or a hash of it) as the challenge. with that you dont always have to create and delete challenge records because you can just let it stay there which essentially also lowers the strain of DNS Servers during renewal times (in case of DNS validation) also the servers of the ACME-CA will also have less strain because they dont need to send extra challenges and check those, because the possession of the key is already proven because it needs to sign every request to the ACME protocol, that's why it makes sense to just use the esatblished identity instead of establishing something completely new and then linking it. They just need to download the key file/records and check whether the key we want is inside also when you want to create a SAN cert with http challenge for multiple webroots you can just copypaste the same file to all webroots and the automation doesnt have to worry about anything else. best regards. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
