Re: [Acme] Fixing the TLS-SNI challenge type
I strongly support the ideas that Martin Thompson is presenting on this matter. While this is a major change, it provides an opportunity build a mechanism to achieve the actual security goal: to ensure that the TLS endpoint that you’re speaking to when you follow all the routing steps a real browser would for a given endpoint successfully negotiates, within this new protocol, proof of possession of the validation challenge token along with confirmation, possession of the account key, and confirmation of what actual DNS label is being validated. > On Jan 11, 2018, at 9:46 PM, Matthew D. Hardeman > wrote: > > Hi, guys, > > I’m entirely new to this list and not sure whether or not I’m welcome, but I > have some comments on the ALPN idea. > > In order to actually be an improvement in security, the ALPN needs to be more > than a mere marker of support. > > Consider: The new mechanism is implemented and Let’s Encrypt deploys. > > Customer’s of not-secure-shared-webhost-A complain that they can’t get > validations via this easy mechanism. (The complaint would actually likely > originate internally by their own development staff.) > > Rather than do the work to ALSO fix the insecure aspects of the > infrastructure, they’ll hastily patch in the “acme" name. > > To add security, perhaps the SNI that is sent should be the actual domain > label that is being validated, along with the “acme” ALPN name. At this > point, an actual ALPN extension should negotiate the authentication, with the > server having the opportunity to bind the proper target name to a desired > authentication and then if and only if the server has available the account > key credentials of the requestor, would it be able to answer with a proper > authentication. > > Just adding a marker with the hammer being that just doing this without > implementing the promises that are supposed to be implied on pain of > violating an RFC is… Likely to get laughed at in a derisive way by the very > web hosts whose behavior now has you contemplating improvements to the > protocol. > > There’s no fast way out of this mess. > ___ > 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] Fixing the TLS-SNI challenge type
Hi, guys, I’m entirely new to this list and not sure whether or not I’m welcome, but I have some comments on the ALPN idea. In order to actually be an improvement in security, the ALPN needs to be more than a mere marker of support. Consider: The new mechanism is implemented and Let’s Encrypt deploys. Customer’s of not-secure-shared-webhost-A complain that they can’t get validations via this easy mechanism. (The complaint would actually likely originate internally by their own development staff.) Rather than do the work to ALSO fix the insecure aspects of the infrastructure, they’ll hastily patch in the “acme" name. To add security, perhaps the SNI that is sent should be the actual domain label that is being validated, along with the “acme” ALPN name. At this point, an actual ALPN extension should negotiate the authentication, with the server having the opportunity to bind the proper target name to a desired authentication and then if and only if the server has available the account key credentials of the requestor, would it be able to answer with a proper authentication. Just adding a marker with the hammer being that just doing this without implementing the promises that are supposed to be implied on pain of violating an RFC is… Likely to get laughed at in a derisive way by the very web hosts whose behavior now has you contemplating improvements to the protocol. There’s no fast way out of this mess. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Fixing the TLS-SNI challenge type
The confidentiality point was a minor one, certainly, but it would represent an improvement. TLS-SNI is a protocol already, but it's more complicated than it needs to be. Certificate generation is a pretty big lift compared to the other challenges. On Fri, Jan 12, 2018 at 2:29 PM, Jonathan Rudenberg wrote: > >> On Jan 11, 2018, at 22:26, Martin Thomson wrote: >> >> If you are using a new protocol, all of the concerns Peter have come >> into play. If you are there, why wouldn't you do the challenge >> validation within the new protocol rather than using the certificate >> (which is sent in the clear in current TLS versions). That might be >> easier to implement than generating the self-signed certificate… > > I don’t think an entirely new protocol makes sense. In order to do the > TLS/SNI/ALPN handshake a certificate is already sent in the ServerHello, so > there’s no reason not to use it to transport the authorization token. > Generating a self-signed certificate is trivial, and I’m not aware of any > relevant security concerns around fetching the authorization in the clear > (the dns-01 and http-01 challenge types are plaintext as well). ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Fixing the TLS-SNI challenge type
> On Jan 11, 2018, at 22:26, Martin Thomson wrote: > > If you are using a new protocol, all of the concerns Peter have come > into play. If you are there, why wouldn't you do the challenge > validation within the new protocol rather than using the certificate > (which is sent in the clear in current TLS versions). That might be > easier to implement than generating the self-signed certificate… I don’t think an entirely new protocol makes sense. In order to do the TLS/SNI/ALPN handshake a certificate is already sent in the ServerHello, so there’s no reason not to use it to transport the authorization token. Generating a self-signed certificate is trivial, and I’m not aware of any relevant security concerns around fetching the authorization in the clear (the dns-01 and http-01 challenge types are plaintext as well). ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Fixing the TLS-SNI challenge type
If you are using a new protocol, all of the concerns Peter have come into play. If you are there, why wouldn't you do the challenge validation within the new protocol rather than using the certificate (which is sent in the clear in current TLS versions). That might be easier to implement than generating the self-signed certificate... On Fri, Jan 12, 2018 at 2:06 PM, Roland Bracewell Shoemaker wrote: > I'm actually going to roll back my thoughts on the SNI value. Thinking > about this more I think it does actually make sense to revert to using > the actual host name here. > > In the initial design of the TLS-SNI challenge the XXX.acme.invalid > value was used as a way to allow servers to dynamically serve both > regular and validation traffic. Since we would be using ALPN here we no > longer need a special SNI value in order to differentiate validation > traffic from regular traffic so this token value is no longer needed. > > If we change that I think we can also remove the need to compute a pair > of SAN values for the cert contents. The original purpose of this was to > prevent a 'dumb' client from simply constructing a certificate on the > fly by sticking the SNI value it received into the SAN and automatically > allowing validation of anything that hit it. If we switch to using the > host name in the SNI then this is no longer necessary as the token value > is no longer present in the request. > > If we make these changes I think the challenge would be different enough > that at that point it should probably be given a completely new name in > order to differentiate it from the original TLS-SNI challenges. I'd > suggest the incredibly imaginative TLS-ALPN (or tls-alpn-01). > > On 01/11/2018 04:49 PM, Roland Bracewell Shoemaker wrote: >> This seems like a silver bullet for the problems we’ve been seeing. Given >> that blindly responding to an unknown ALPN value would be an RFC violation >> this seems safe (although, hey, who knows what servers/cloud providers >> actually do). Definitely interested in the results of the scan. There could >> still be some argument about ‘misuse’ of the SNI extension but unless we >> have a concrete reason to the host name being validated I’m not sure I’m >> convinced we should. >> >> Does anyone have any objections/spot any major issues with doing this? >> >>> On Jan 11, 2018, at 2:41 PM, Jonathan Rudenberg >>> wrote: >>> >>> As many of you are probably aware, Frans Rosén of Detectify discovered a >>> method of exploiting many shared hosting providers to obtain unauthorized >>> certificates using the ACME TLS-SNI-01/02 challenge types[0]. Let’s Encrypt >>> is in the process of removing support for these challenge types[1]. >>> >>> Obviously this is not ideal, as the TLS-SNI challenge is useful in a >>> variety of use cases. The good news is that TLS-SNI-02 appears to be >>> fixable. >>> >>> In order to get the ball rolling on a fixed version (aka TLS-SNI-03), >>> here’s a straw proposal, based on something originally publicly suggested >>> by Ryan Sleevi[2]: >>> >>> Start with the TLS-SNI-02 challenge specification, and add the requirement >>> that the ACME server MUST send an ALPN extension in the ClientHello with a >>> single “acme” protocol name, and the ACME server MUST confirm that the >>> ServerHello also includes an ALPN extension with a single “acme” protocol >>> name. >>> >>> The only concern I’ve seen about this is the theoretical possibility that >>> servers might just repeat back the ALPN extension with the same protocol >>> name, which I believe we can remedy by doing a scan of the Alexa Top 1M (or >>> similar) to see if this behavior exists in the wild. >>> >>> Jonathan >>> >>> [0] >>> https://community.letsencrypt.org/t/2018-01-09-issue-with-tls-sni-01-and-shared-hosting-infrastructure/49996 >>> [1] >>> https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188 >>> [2] >>> https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg08984.html >>> ___ >>> 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] Fixing the TLS-SNI challenge type
On Thu, Jan 11, 2018 at 04:49:45PM -0800, Roland Bracewell Shoemaker wrote: > This seems like a silver bullet for the problems we’ve been seeing. Given > that blindly responding to an unknown ALPN value would be an RFC violation > this seems safe (although, hey, who knows what servers/cloud providers > actually do). Definitely interested in the results of the scan. There could > still be some argument about ‘misuse’ of the SNI extension but unless we have > a concrete reason to the host name being validated I’m not sure I’m convinced > we should. > > Does anyone have any objections/spot any major issues with doing this? I don't have any objections at this stage, but one thing to bear in mind is what will be required to set the ALPN values from various places. There's some support for using it to negotiatie HTTP/2 in Apache 2.4.17+ and Nginx (apparently?) 1.9.5. Even if it's settable from their config files, we'll still need to migrate a lot of Certbot Apache and Nginx plugin users over to HTTP-x Challenge types. And though this is unlikely we should think hard about any ways that malicious actors might be able to set these values :) Also CC'ing Stefan Eissing to get an opinion on the impact on built-in Apache ACME support... > > > On Jan 11, 2018, at 2:41 PM, Jonathan Rudenberg > > wrote: > > > > As many of you are probably aware, Frans Rosén of Detectify discovered a > > method of exploiting many shared hosting providers to obtain unauthorized > > certificates using the ACME TLS-SNI-01/02 challenge types[0]. Let’s Encrypt > > is in the process of removing support for these challenge types[1]. > > > > Obviously this is not ideal, as the TLS-SNI challenge is useful in a > > variety of use cases. The good news is that TLS-SNI-02 appears to be > > fixable. > > > > In order to get the ball rolling on a fixed version (aka TLS-SNI-03), > > here’s a straw proposal, based on something originally publicly suggested > > by Ryan Sleevi[2]: > > > > Start with the TLS-SNI-02 challenge specification, and add the requirement > > that the ACME server MUST send an ALPN extension in the ClientHello with a > > single “acme” protocol name, and the ACME server MUST confirm that the > > ServerHello also includes an ALPN extension with a single “acme” protocol > > name. > > > > The only concern I’ve seen about this is the theoretical possibility that > > servers might just repeat back the ALPN extension with the same protocol > > name, which I believe we can remedy by doing a scan of the Alexa Top 1M (or > > similar) to see if this behavior exists in the wild. > > > > Jonathan > > > > [0] > > https://community.letsencrypt.org/t/2018-01-09-issue-with-tls-sni-01-and-shared-hosting-infrastructure/49996 > > [1] > > https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188 > > [2] > > https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg08984.html > > ___ > > 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 -- Peter Eckersleyp...@eff.org Chief Computer Scientist Tel +1 415 436 9333 x131 Electronic Frontier FoundationFax +1 415 436 9993 ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Fixing the TLS-SNI challenge type
I'm actually going to roll back my thoughts on the SNI value. Thinking about this more I think it does actually make sense to revert to using the actual host name here. In the initial design of the TLS-SNI challenge the XXX.acme.invalid value was used as a way to allow servers to dynamically serve both regular and validation traffic. Since we would be using ALPN here we no longer need a special SNI value in order to differentiate validation traffic from regular traffic so this token value is no longer needed. If we change that I think we can also remove the need to compute a pair of SAN values for the cert contents. The original purpose of this was to prevent a 'dumb' client from simply constructing a certificate on the fly by sticking the SNI value it received into the SAN and automatically allowing validation of anything that hit it. If we switch to using the host name in the SNI then this is no longer necessary as the token value is no longer present in the request. If we make these changes I think the challenge would be different enough that at that point it should probably be given a completely new name in order to differentiate it from the original TLS-SNI challenges. I'd suggest the incredibly imaginative TLS-ALPN (or tls-alpn-01). On 01/11/2018 04:49 PM, Roland Bracewell Shoemaker wrote: > This seems like a silver bullet for the problems we’ve been seeing. Given > that blindly responding to an unknown ALPN value would be an RFC violation > this seems safe (although, hey, who knows what servers/cloud providers > actually do). Definitely interested in the results of the scan. There could > still be some argument about ‘misuse’ of the SNI extension but unless we have > a concrete reason to the host name being validated I’m not sure I’m convinced > we should. > > Does anyone have any objections/spot any major issues with doing this? > >> On Jan 11, 2018, at 2:41 PM, Jonathan Rudenberg >> wrote: >> >> As many of you are probably aware, Frans Rosén of Detectify discovered a >> method of exploiting many shared hosting providers to obtain unauthorized >> certificates using the ACME TLS-SNI-01/02 challenge types[0]. Let’s Encrypt >> is in the process of removing support for these challenge types[1]. >> >> Obviously this is not ideal, as the TLS-SNI challenge is useful in a variety >> of use cases. The good news is that TLS-SNI-02 appears to be fixable. >> >> In order to get the ball rolling on a fixed version (aka TLS-SNI-03), here’s >> a straw proposal, based on something originally publicly suggested by Ryan >> Sleevi[2]: >> >> Start with the TLS-SNI-02 challenge specification, and add the requirement >> that the ACME server MUST send an ALPN extension in the ClientHello with a >> single “acme” protocol name, and the ACME server MUST confirm that the >> ServerHello also includes an ALPN extension with a single “acme” protocol >> name. >> >> The only concern I’ve seen about this is the theoretical possibility that >> servers might just repeat back the ALPN extension with the same protocol >> name, which I believe we can remedy by doing a scan of the Alexa Top 1M (or >> similar) to see if this behavior exists in the wild. >> >> Jonathan >> >> [0] >> https://community.letsencrypt.org/t/2018-01-09-issue-with-tls-sni-01-and-shared-hosting-infrastructure/49996 >> [1] >> https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188 >> [2] >> https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg08984.html >> ___ >> 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] Fixing the TLS-SNI challenge type
> On Jan 11, 2018, at 19:49, Roland Bracewell Shoemaker > wrote: > > This seems like a silver bullet for the problems we’ve been seeing. Given > that blindly responding to an unknown ALPN value would be an RFC violation > this seems safe (although, hey, who knows what servers/cloud providers > actually do). Definitely interested in the results of the scan. I’ve completed[0] a scan of the Alexa Top 1M list, and no servers repeated back the unknown ALPN protocol of “acme” that I used[1]. I also opened a PR that adds this change to the spec: https://github.com/ietf-wg-acme/acme/pull/389 Jonathan [0] https://storage.googleapis.com/titanous-acme/alpn_scan.csv.gz [1] https://gist.github.com/titanous/8daa24ed3375f3c690950e8a97c7527d ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Fixing the TLS-SNI challenge type
This seems like a silver bullet for the problems we’ve been seeing. Given that blindly responding to an unknown ALPN value would be an RFC violation this seems safe (although, hey, who knows what servers/cloud providers actually do). Definitely interested in the results of the scan. There could still be some argument about ‘misuse’ of the SNI extension but unless we have a concrete reason to the host name being validated I’m not sure I’m convinced we should. Does anyone have any objections/spot any major issues with doing this? > On Jan 11, 2018, at 2:41 PM, Jonathan Rudenberg wrote: > > As many of you are probably aware, Frans Rosén of Detectify discovered a > method of exploiting many shared hosting providers to obtain unauthorized > certificates using the ACME TLS-SNI-01/02 challenge types[0]. Let’s Encrypt > is in the process of removing support for these challenge types[1]. > > Obviously this is not ideal, as the TLS-SNI challenge is useful in a variety > of use cases. The good news is that TLS-SNI-02 appears to be fixable. > > In order to get the ball rolling on a fixed version (aka TLS-SNI-03), here’s > a straw proposal, based on something originally publicly suggested by Ryan > Sleevi[2]: > > Start with the TLS-SNI-02 challenge specification, and add the requirement > that the ACME server MUST send an ALPN extension in the ClientHello with a > single “acme” protocol name, and the ACME server MUST confirm that the > ServerHello also includes an ALPN extension with a single “acme” protocol > name. > > The only concern I’ve seen about this is the theoretical possibility that > servers might just repeat back the ALPN extension with the same protocol > name, which I believe we can remedy by doing a scan of the Alexa Top 1M (or > similar) to see if this behavior exists in the wild. > > Jonathan > > [0] > https://community.letsencrypt.org/t/2018-01-09-issue-with-tls-sni-01-and-shared-hosting-infrastructure/49996 > [1] > https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188 > [2] > https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg08984.html > ___ > 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] Challenge "errors" -> "error"
> On Jan 8, 2018, at 13:37, Jacob Hoffman-Andrews wrote: > > In the course of testing Let's Encrypt's ACME v2 endpoint, we realized > that the latest draft specifies "errors" as a plural array on challenges > (vs singular "error" for earlier drafts implemented by Boulder and > others). However, the ACME spec now also has subproblems as a way to > express plural errors (mainly on new-order and finalize). > > This means we have two different ways to express multiple errors: One > for API requests, and one for validation responses. I propose to > simplify the spec by using subproblems consistently in both places: > https://github.com/ietf-wg-acme/acme/pull/388 This change makes sense to me. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] Fixing the TLS-SNI challenge type
As many of you are probably aware, Frans Rosén of Detectify discovered a method of exploiting many shared hosting providers to obtain unauthorized certificates using the ACME TLS-SNI-01/02 challenge types[0]. Let’s Encrypt is in the process of removing support for these challenge types[1]. Obviously this is not ideal, as the TLS-SNI challenge is useful in a variety of use cases. The good news is that TLS-SNI-02 appears to be fixable. In order to get the ball rolling on a fixed version (aka TLS-SNI-03), here’s a straw proposal, based on something originally publicly suggested by Ryan Sleevi[2]: Start with the TLS-SNI-02 challenge specification, and add the requirement that the ACME server MUST send an ALPN extension in the ClientHello with a single “acme” protocol name, and the ACME server MUST confirm that the ServerHello also includes an ALPN extension with a single “acme” protocol name. The only concern I’ve seen about this is the theoretical possibility that servers might just repeat back the ALPN extension with the same protocol name, which I believe we can remedy by doing a scan of the Alexa Top 1M (or similar) to see if this behavior exists in the wild. Jonathan [0] https://community.letsencrypt.org/t/2018-01-09-issue-with-tls-sni-01-and-shared-hosting-infrastructure/49996 [1] https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188 [2] https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg08984.html ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Which key used in external account binding
On Thu, Jan 11, 2018 at 22:24:04 +0100, Richard Koerber wrote: > > Your typical workflow, as I understand the specs, could be: > > > > * Register an account with your CA, e.g. register on their website, using > > username + password. > > * On their website click the "generate ACME key". > > * Website displays a key_id (e.g. your username) and a random MAC. > > * You create an asymmetric ACME account keypair (e.g. RSA or ECC). > > * You create a JWS using your username + MAC. > > * You call the newAccount endpoint using your new asymmetric keypair. > > Payload includes the JWS from previous step. > > * For all subsequent operations you use your asymmetric acme account key > > pair. You can forget about your MAC. > > What is the role of the "kid" field in the protected header, when using > external account binding? > > According to the specs, the "kid" field usually contains the account URL. > > But what is it when the account is bound externally? Does the "kid" field > contain the key identifier from CA (the same that was used in the > externalAccountBinding subfield)? Or is it still the account URL? Assuming you've created your account with externalAccountBinding, then you received a new account URL from the ACME server. You need to use that URL as the "kid" for all requests. signature.asc Description: PGP signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Which key used in external account binding
> Your typical workflow, as I understand the specs, could be: > > * Register an account with your CA, e.g. register on their website, using > username + password. > * On their website click the "generate ACME key". > * Website displays a key_id (e.g. your username) and a random MAC. > * You create an asymmetric ACME account keypair (e.g. RSA or ECC). > * You create a JWS using your username + MAC. > * You call the newAccount endpoint using your new asymmetric keypair. > Payload includes the JWS from previous step. > * For all subsequent operations you use your asymmetric acme account key > pair. You can forget about your MAC. What is the role of the "kid" field in the protected header, when using external account binding? According to the specs, the "kid" field usually contains the account URL. But what is it when the account is bound externally? Does the "kid" field contain the key identifier from CA (the same that was used in the externalAccountBinding subfield)? Or is it still the account URL? Regards Richard Körber ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Guessable URLs and unprotected orders lists
2018-01-11 20:36 GMT+01:00 Ilari Liusvaara : > On Thu, Jan 11, 2018 at 08:23:26PM +0100, Sophie Herold wrote: > > Hi, > > > > challenge tokens "MUST have at least 128 bits of entropy", at the same > > time it seems trivial to guess order and authorization URLs like the > > ones used in the examples. It seems natural, that URLs MUST be generated > > with the same amount of entropy. But I couldn't find that in the draft. > > > > > > For account objects, GET request are not allowed: > > > >Servers SHOULD NOT respond to GET requests for account resources as > >these requests are not authenticated. > > > > This suggests that all non-expiring URLs should be protected in this > > way. At least for orders lists, this protection is missing. > > > > The token entropy requirement is to render those tokens unguessable > before the validation request is received. This is to protect against > careless servers. The token is not actually secret after it has been > generated. > I don't think it is for careless servers, the token is provided in the request, so any server can respond with it. Rather it's required to fulfill the CA/Browser Forum rules. Regards, Niklas > Now, in some approved CA validation methods, the tokens actually are > secret, but none of those is used in ACME. > > > -Ilari > > ___ > 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] Undoing challenge fulfilling actions
On Tue, Jan 09, 2018 at 10:27:05 +0100, Sophie Herold wrote: > On 07/01/18 19:53, Jörn Heissler wrote: > > why SHOULD a client undo any actions regardless if an authorization > > failed or if the certificate was issued, etc.? > > What bad might happen when a file or DNS record is *not* removed? > > I don't have any experiences with DNS servers serving large zone files. > However, if ACME records aren't deleted, they may quickly become the > majority of the records. I imagine, that this could be relevant in the > long run. Assuming that ACME will be used by a considerable proportion > of domains in the future, it might be wise to take measures to curb this > bloat with a SHOULD? Hi, neither do I. My largest zone file was no more than a few Hundred records. I wouldn't care if my DNS server hosts a total of 3000 or 5000 records. This might add a few Hundred kilobytes of memory usage, so what. Large providers with DNS servers for Millions of domains might either charge their users per record (and earn more money if users keep the records) or if they manage ACME themselves they could remove the records when no longer needed. Whenever I update my zone, the slave servers need to pick up the change. This adds load too. Or in the case of e.g. AWS route53, it takes several seconds to do any change. And for every change a log entry is generated and stored in CloudTrail. I'm not familiar with DNSSEC. When you add a new record, I assume you need to re-sign your zone. Is the same true when you remove a record? So there is a chance that removing records will free up a some storage. But surely there is network + computational overhead at the same time. We're using rfc2119 terminology here. I don't see enough justification why records SHOULD be removed. There are good reasons for and reasons against doing it. I think that "MAY" fits a lot better here. Cheers Jörn signature.asc Description: PGP signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Guessable URLs and unprotected orders lists
On Thu, Jan 11, 2018 at 08:23:26PM +0100, Sophie Herold wrote: > Hi, > > challenge tokens "MUST have at least 128 bits of entropy", at the same > time it seems trivial to guess order and authorization URLs like the > ones used in the examples. It seems natural, that URLs MUST be generated > with the same amount of entropy. But I couldn't find that in the draft. > > > For account objects, GET request are not allowed: > >Servers SHOULD NOT respond to GET requests for account resources as >these requests are not authenticated. > > This suggests that all non-expiring URLs should be protected in this > way. At least for orders lists, this protection is missing. > The token entropy requirement is to render those tokens unguessable before the validation request is received. This is to protect against careless servers. The token is not actually secret after it has been generated. Now, in some approved CA validation methods, the tokens actually are secret, but none of those is used in ACME. -Ilari ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] Guessable URLs and unprotected orders lists
Hi, challenge tokens "MUST have at least 128 bits of entropy", at the same time it seems trivial to guess order and authorization URLs like the ones used in the examples. It seems natural, that URLs MUST be generated with the same amount of entropy. But I couldn't find that in the draft. For account objects, GET request are not allowed: Servers SHOULD NOT respond to GET requests for account resources as these requests are not authenticated. This suggests that all non-expiring URLs should be protected in this way. At least for orders lists, this protection is missing. Best, Sophie ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Which key used in external account binding
On Thu, Jan 11, 2018 at 16:11:39 +0100, Robert Kästel wrote: > Is external account binding supposed to always use the MAC key and external > CA kid for signing subsequent requests? > Or is the client supposed to generate a new account key pair that gets > associated with the external CA kid after external account binding, and > uses that to sign subsequent requests? The latter one. Your typical workflow, as I understand the specs, could be: * Register an account with your CA, e.g. register on their website, using username + password. * On their website click the "generate ACME key". * Website displays a key_id (e.g. your username) and a random MAC. * You create an asymmetric ACME account keypair (e.g. RSA or ECC). * You create a JWS using your username + MAC. * You call the newAccount endpoint using your new asymmetric keypair. Payload includes the JWS from previous step. * For all subsequent operations you use your asymmetric acme account key pair. You can forget about your MAC. signature.asc Description: PGP signature ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] Which key used in external account binding
Hello! Is external account binding supposed to always use the MAC key and external CA kid for signing subsequent requests? Or is the client supposed to generate a new account key pair that gets associated with the external CA kid after external account binding, and uses that to sign subsequent requests? regards, Robert Kästel ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
