Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)
Here's another PR with further feedback: https://github.com/ietf-wg-acme/acme/pull/453 Replies in-line below. > Perhaps dropping the "to clients" would remove the reading that > there is nonce/client tracking without losing any significant information, > but this seems to fall under editorial discretion, so it's all yours. I think that's a reasonable change if it will reduce confusion. Done. > How about "It is also used, with some media types, from certificate > resources [...]"? Works for me. Done. > And my intent was to suggest that there is a new paragraph for "alternate", > maybe: >> The "alternate" link relation is used when a CA can provide multiple >> distinct certification chains (e.g., chaining to different root CA >> certificates) for a provided certificate. I don't think this is needed. Section 7.4.2 "Downloading the Certificate" says almost the same thing when describing the "alternate" relation. I think this is the location in-document where the information is most relevant. > Ah. This table is slightly cramped, so it may not be worth a change, but > even "order's certificate" (and the matching "order's authorizations") > might help. Ok, changed to the possessive forms. > Mostly I just want the document to be clear and consistent about whether > exactly one successful challenge suffices to authorize, and exactly one > unsuccessful challenge suffices to fail authorization Ok. I think this has been made clear in #447. One authorization is sufficient to authorize. One failed challenge fails the authorization/order. > I was expecting something like '''a stub account object optionally containing the > "contact", "termsOfServiceAgreed", "onlyReturnExisting", and > "externalAccountBinding" fields.''' I understand now, thanks! Updated to say "and optionally the "onlyReturnExisting" and "externalAccountBinding" fields". I think that will cover this. > If "termsOfService" is present in the directory, is the client required to > agree to the terms before service is provided? The text, to me, seems to > allow a server to use this field to provide some optional additional > documentation without requiring clients to agree to it. I don't think the text suggests that. Section 7.3 "Account Creation" says: > If the server wishes to present the client with terms under which the > ACME service is to be used, it MUST indicate the URL where such terms > can be accessed in the "termsOfService" subfield of the "meta" field > in the directory object, and the server MUST reject new-account > requests that do not have the "termsOfServiceAgreed" field set to > "true". So if termsOfService is present you MUST send termsOfServiceAgreed to be able to create an account. I don't think there is a reading of that text that would allow the server to provide additional documentation without requiring client agreement. > I think it would help to say '''MUST ignore any updates to [...], the > "status" field (except as allowed by Section 7.3.7), or any other [...]''' Good suggestion. Done. > It seems that they would then be removed from the listing on page 46 (of > the -14)? I think the best fix here is to remove "valid" from "After a valid request to finalize has been issued". I've made this change. > This would be § 4.4.2 of RFC 8446 Thanks. Added a ref to RFC 8446. > Well now I'm really confused. If I look at the example exchanges for the HTTP challenge. Apologies. I forgot that the HTTP-01 challenge type does send the token in the request by way of the request path. I removed the language that says it "expresses a domain holder's authorization". > In particular, right now I think that the text about "participating in the > creation" is inaccurate. Rephrased to say that the entropy requirement only prevents guessing the token and removed text about "participating in the creation". Thanks. On Sun, Sep 16, 2018 at 6:29 PM Benjamin Kaduk wrote: > On Sun, Sep 16, 2018 at 10:42:26PM +0200, Felix Fontein wrote: > > Hi, > > > > > > > > > >[...] Secondly, the entropy requirement > > > > > > > >prevents ACME clients from implementing a "naive" > > > > > > > > validation server that automatically replies to challenges > > > > > > > > without participating in the creation of the initial > > > > > > > > authorization request. > > > > > > > > > > > > > > > > IMPORTANT: I'm not sure I see how this applies to the HTTP > > > > > > > > mechanism -- couldn't you write a script to reply > > > > > > > > to .well-known/acme-challenge/ with . > > > > > > > thumbprint> for a fixed key thumbprint? The validation > > > > > > > > thumbprint> server would ned to > > > > > > > > know about the ACME account in question, but not about any > > > > > > > > individual authorization request. > > > > > > > > > > > > > > It would also need to know the value, which is not > > > > > > > provided in the validation request specifically to avoid > > > > > > > this. > > > > > > > > > > > > As I said above, "[w]ell now I'm
Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)
On Sun, Sep 16, 2018 at 10:42:26PM +0200, Felix Fontein wrote: > Hi, > > > > > > > >[...] Secondly, the entropy requirement > > > > > > >prevents ACME clients from implementing a "naive" > > > > > > > validation server that automatically replies to challenges > > > > > > > without participating in the creation of the initial > > > > > > > authorization request. > > > > > > > > > > > > > > IMPORTANT: I'm not sure I see how this applies to the HTTP > > > > > > > mechanism -- couldn't you write a script to reply > > > > > > > to .well-known/acme-challenge/ with . > > > > > > thumbprint> for a fixed key thumbprint? The validation > > > > > > > thumbprint> server would ned to > > > > > > > know about the ACME account in question, but not about any > > > > > > > individual authorization request. > > > > > > > > > > > > It would also need to know the value, which is not > > > > > > provided in the validation request specifically to avoid > > > > > > this. > > > > > > > > > > As I said above, "[w]ell now I'm really confused." In the > > > > > example HTTP challenge exchange (duplicated here): > > > > > > > > > > GET > > > > > /.well-known/acme-challenge/LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0 > > > > > Host: example.org > > > > > > > > > > HTTP/1.1 200 OK > > > > > Content-Type: application/octet-stream > > > > > > > > > > LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9fm21mqTI > > > > > > > > > > Doesn't the path in the GET include the ? > > > > > > > > Yes, and some people are already using this to add a generic > > > > authorization replier (which needs the thumbprint of the account > > > > key). For example, the acme.sh client supports this "stateless > > > > mode" (as it is called there): > > > > https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode > > > > > > Okay, that matches up with my understanding and maybe un-confuses > > > me. > > > > > > But does this state of affairs nullify the text in the -14 about: > > > > > >[...] the entropy requirement > > >prevents ACME clients from implementing a "naive" validation > > > server that automatically replies to challenges without > > > participating in the creation of the initial authorization request. > > > > > > ? > > > > Also, if we wanted to prevent this sort of dumb script, it seems like > > we could have the ACME server do a > > GET /.well-known/acme-challenge/ > > instead of > > GET /.well-known/acme-challenge/ > > > > and expect the un-hashed token in the response body. (Witih obvious > > questions about explicit hash agility vs. hardcoding a hash per > > challenge type.) > > That would work. However, I'm not sure whether this should really be > disallowed. I also understand the text from draft-14 as you do, but I > since this incorporates the account key hash, it doesn't validate for > challenges coming from other ACME accounts. Whether or not it should be disallowed is probably a function of the severity of the XSS risk (which I don't have a good picture of right now) -- as I attempted to note in my ballot text, the token is only created by virtue of the account key holder's explicit request, which could itself be seen as an authorizing action. The echoing of the token by the HTTP server serves to confirm possession of the domain name, more than the specific authorization, in that worldview. > Also, there has been a proposal > (https://github.com/ietf-wg-acme/acme/issues/393) to allow something > similar for DNS validation (as dns-02), which explicitly mentions this > automation. Since nobody responded that such an automation is unwanted, > my assumption is that this automation is a feature and not a bug. It > would be nice if this would be more clear from the text, though. Agreed that the text could be more clear. In particular, right now I think that the text about "participating in the creation" is inaccurate. -Benjamin ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)
Hi, > > > > > >[...] Secondly, the entropy requirement > > > > > >prevents ACME clients from implementing a "naive" > > > > > > validation server that automatically replies to challenges > > > > > > without participating in the creation of the initial > > > > > > authorization request. > > > > > > > > > > > > IMPORTANT: I'm not sure I see how this applies to the HTTP > > > > > > mechanism -- couldn't you write a script to reply > > > > > > to .well-known/acme-challenge/ with . > > > > > thumbprint> for a fixed key thumbprint? The validation > > > > > > thumbprint> server would ned to > > > > > > know about the ACME account in question, but not about any > > > > > > individual authorization request. > > > > > > > > > > It would also need to know the value, which is not > > > > > provided in the validation request specifically to avoid > > > > > this. > > > > > > > > As I said above, "[w]ell now I'm really confused." In the > > > > example HTTP challenge exchange (duplicated here): > > > > > > > > GET > > > > /.well-known/acme-challenge/LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0 > > > > Host: example.org > > > > > > > > HTTP/1.1 200 OK > > > > Content-Type: application/octet-stream > > > > > > > > LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9fm21mqTI > > > > > > > > Doesn't the path in the GET include the ? > > > > > > Yes, and some people are already using this to add a generic > > > authorization replier (which needs the thumbprint of the account > > > key). For example, the acme.sh client supports this "stateless > > > mode" (as it is called there): > > > https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode > > > > Okay, that matches up with my understanding and maybe un-confuses > > me. > > > > But does this state of affairs nullify the text in the -14 about: > > > >[...] the entropy requirement > >prevents ACME clients from implementing a "naive" validation > > server that automatically replies to challenges without > > participating in the creation of the initial authorization request. > > > > ? > > Also, if we wanted to prevent this sort of dumb script, it seems like > we could have the ACME server do a > GET /.well-known/acme-challenge/ > instead of > GET /.well-known/acme-challenge/ > > and expect the un-hashed token in the response body. (Witih obvious > questions about explicit hash agility vs. hardcoding a hash per > challenge type.) That would work. However, I'm not sure whether this should really be disallowed. I also understand the text from draft-14 as you do, but I since this incorporates the account key hash, it doesn't validate for challenges coming from other ACME accounts. Also, there has been a proposal (https://github.com/ietf-wg-acme/acme/issues/393) to allow something similar for DNS validation (as dns-02), which explicitly mentions this automation. Since nobody responded that such an automation is unwanted, my assumption is that this automation is a feature and not a bug. It would be nice if this would be more clear from the text, though. Cheers, Felix ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)
On Sun, Sep 16, 2018 at 10:41:42AM -0500, Benjamin Kaduk wrote: > On Sun, Sep 16, 2018 at 05:35:37PM +0200, Felix Fontein wrote: > > Hi, > > > > > > >[...] Secondly, the entropy requirement > > > > >prevents ACME clients from implementing a "naive" validation > > > > > server that automatically replies to challenges without > > > > > participating in the creation of the initial authorization > > > > > request. > > > > > > > > > > IMPORTANT: I'm not sure I see how this applies to the HTTP > > > > > mechanism -- couldn't you write a script to reply > > > > > to .well-known/acme-challenge/ with . > > > > > for a fixed key thumbprint? The validation server would ned to > > > > > know about the ACME account in question, but not about any > > > > > individual authorization request. > > > > > > > > It would also need to know the value, which is not provided > > > > in the validation request specifically to avoid this. > > > > > > As I said above, "[w]ell now I'm really confused." In the example > > > HTTP challenge exchange (duplicated here): > > > > > > GET > > > /.well-known/acme-challenge/LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0 > > > Host: example.org > > > > > > HTTP/1.1 200 OK > > > Content-Type: application/octet-stream > > > > > > LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9fm21mqTI > > > > > > Doesn't the path in the GET include the ? > > > > Yes, and some people are already using this to add a generic > > authorization replier (which needs the thumbprint of the account key). > > For example, the acme.sh client supports this "stateless mode" (as it > > is called there): > > https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode > > Okay, that matches up with my understanding and maybe un-confuses me. > > But does this state of affairs nullify the text in the -14 about: > >[...] the entropy requirement >prevents ACME clients from implementing a "naive" validation server >that automatically replies to challenges without participating in the >creation of the initial authorization request. > > ? Also, if we wanted to prevent this sort of dumb script, it seems like we could have the ACME server do a GET /.well-known/acme-challenge/ instead of GET /.well-known/acme-challenge/ and expect the un-hashed token in the response body. (Witih obvious questions about explicit hash agility vs. hardcoding a hash per challenge type.) -Ben ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)
On Sun, Sep 16, 2018 at 05:35:37PM +0200, Felix Fontein wrote: > Hi, > > > > >[...] Secondly, the entropy requirement > > > >prevents ACME clients from implementing a "naive" validation > > > > server that automatically replies to challenges without > > > > participating in the creation of the initial authorization > > > > request. > > > > > > > > IMPORTANT: I'm not sure I see how this applies to the HTTP > > > > mechanism -- couldn't you write a script to reply > > > > to .well-known/acme-challenge/ with . > > > > for a fixed key thumbprint? The validation server would ned to > > > > know about the ACME account in question, but not about any > > > > individual authorization request. > > > > > > It would also need to know the value, which is not provided > > > in the validation request specifically to avoid this. > > > > As I said above, "[w]ell now I'm really confused." In the example > > HTTP challenge exchange (duplicated here): > > > > GET /.well-known/acme-challenge/LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0 > > Host: example.org > > > > HTTP/1.1 200 OK > > Content-Type: application/octet-stream > > > > LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9fm21mqTI > > > > Doesn't the path in the GET include the ? > > Yes, and some people are already using this to add a generic > authorization replier (which needs the thumbprint of the account key). > For example, the acme.sh client supports this "stateless mode" (as it > is called there): > https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode Okay, that matches up with my understanding and maybe un-confuses me. But does this state of affairs nullify the text in the -14 about: [...] the entropy requirement prevents ACME clients from implementing a "naive" validation server that automatically replies to challenges without participating in the creation of the initial authorization request. ? -Benjamin > (There currently is also a discussion in the Let's Encrypt community > forum about this, see > https://community.letsencrypt.org/t/xss-via-acme-implementations/72295; > this is because some implementations do not restrict the allowed input > and thus allow XSS attacks, as described here: > https://labs.detectify.com/2018/09/04/xss-using-quirky-implementations-of-acme-http-01/) > > Cheers, > Felix > > ___ > 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] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)
Hi, > > >[...] Secondly, the entropy requirement > > >prevents ACME clients from implementing a "naive" validation > > > server that automatically replies to challenges without > > > participating in the creation of the initial authorization > > > request. > > > > > > IMPORTANT: I'm not sure I see how this applies to the HTTP > > > mechanism -- couldn't you write a script to reply > > > to .well-known/acme-challenge/ with . > > > for a fixed key thumbprint? The validation server would ned to > > > know about the ACME account in question, but not about any > > > individual authorization request. > > > > It would also need to know the value, which is not provided > > in the validation request specifically to avoid this. > > As I said above, "[w]ell now I'm really confused." In the example > HTTP challenge exchange (duplicated here): > > GET /.well-known/acme-challenge/LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0 > Host: example.org > > HTTP/1.1 200 OK > Content-Type: application/octet-stream > > LoqXcYV8q5ONbJQxbmR7SCTNo3tiAXDfowyjxAjEuX0.9jg46WB3rR_AHD-EBXdN7cBkH1WOu0tA3M9fm21mqTI > > Doesn't the path in the GET include the ? Yes, and some people are already using this to add a generic authorization replier (which needs the thumbprint of the account key). For example, the acme.sh client supports this "stateless mode" (as it is called there): https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode (There currently is also a discussion in the Let's Encrypt community forum about this, see https://community.letsencrypt.org/t/xss-via-acme-implementations/72295; this is because some implementations do not restrict the allowed input and thus allow XSS attacks, as described here: https://labs.detectify.com/2018/09/04/xss-using-quirky-implementations-of-acme-http-01/) Cheers, Felix ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)
On Fri, Sep 14, 2018 at 03:59:07PM -0400, Daniel McCarney wrote: > > My co-author Daniel McCarney is working on the COMMENT comments. > > I've addressed most of the "COMMENT" feedback in the following PR: > https://github.com/ietf-wg-acme/acme/pull/451 > > Further replies inline below. As a note, I'm a bit starved for time. Because > I don't have a usecase for account key binding and have not implemented it > I defer to others in the WG for comments related to section 7.3.5. > > > It's probably worth going over the examples and checking whether nonce > > values are repeated in ways that are inconsistent with expected usage. > For > > example, I see these three values appearing multiple times (but I did not > > cross-check if a nonce returned in the Replay-Nonce response header was > > then used in a JWS header attribute): > > 2 K60BWPrMQG9SDxBDS_xtSw > > 3 IXVHDyxIRGcTE0VSblhPzw > > 4 JHb54aT_KTXBWQOzGYkt9A > > Good idea. I did a pass to check for inconsistencies. > > > Different types of certificates reflect different kinds of CA > > verification of information about the certificate subject. "Domain > > Validation" (DV) certificates are by far the most common type. The > > only validation the CA is required to perform in the DV issuance > > process is to verify that the requester has effective control of the > > domain. > > > > Can we get an (informative) ref for the "required"/requirements? > > Done. > > > W3C.CR-cors-2013-0129 shows up as "outdated" when I follow the link. > > Thanks. Seems like we should use W3C.CR-cors-20140116 instead. Fixed. > > > IMPORTANT: The JSON Web Signature and Encryption Algorithms registry does > > not appear to include an explicit indicator of whether an algorithm is > > MAC-based; do we need to include text on how to make such a determination? > > Unfortunate. I added text saying the "Alogrithm Description" should not > mention > MAC/HMAC. Please suggest alternative text if you don't like mine. This is fine. It's kind of a shame that there isn't a more explicit field in the registry, since there are lots of consumers that have to do this sort of check (and exploits against some JWT libraries that failed to do so...) > > For servers following the "SHOULD ... string equality check" and for > > requests where the equality check fails, does that fall into the "MUST > > reject the request as unauthorized" bucket? > > Yes. Clarified. > > > In order to protect ACME resources from any possible replay attacks, > > ACME requests have a mandatory anti-replay mechanism. > > > > We don't seem to actually define what an "ACME request" is that I can see. > > From context, this requirement only applies to JWS POST bodies, and not > to, > > say, newNonce, but I wonder if some clarification would be useful. > > Sure, fixed to "ACME POST requests have a ...". > > > IMPORTANT: How tightly are these nonces scoped? Are they only good on a > > specific TLS connection? Bound to an account key pair? Globally valid? > > (This is not a DISCUSS point because AFAICT there is no loss in security > if > > the nonce space is global to the server.) > > It should be left to the server to accept/reject and the client to retry as > described. I don't think the specification should prescribe the way > nonces are scoped by the server operator. Okay, so as far as the spec is concerned they have global scope. I asked because (on my first read) some of the text almost implied that the server was tracking which clients it issued which nonces to. I don't get much of that sense on a reread, though; probably it was at the start of § 6.4 when the server is "maintaining a list of nonces that it has issued to clients". Perhaps dropping the "to clients" would remove the reading that there is nonce/client tracking without losing any significant information, but this seems to fall under editorial discretion, so it's all yours. > > IMPORTANT: Providing an accountDoesNotExist error type probably means we > > need to give guidance that the server should choose account URLs in a > > non-guessable way, to avoid account enumeration attacks. > > I think this is covered in https://github.com/ietf-wg-acme/acme/pull/445 I think my concerns in this space have been entirely subsumed by Adam's DISCUSS, yes. > >[...] Servers > >MUST NOT use the ACME URN namespace Section 9.6 for errors other than > >the standard types. > > > > "standard" as determined by inclusion in this document, or in the IANA > registry? > > Alexey raised this as well and a fix is included in PR > https://github.com/ietf-wg-acme/acme/pull/442 > > > The "up" link relation for going from certificate to chain seems to only > be > > needed for alternate content types that can only represent a single > > certificate. (Also, the "alternate" link relation is used to provide > > alternate certifciation chains.) Could this text be made more clear? > > I'm not sure I understand the part that isn't
Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)
> My co-author Daniel McCarney is working on the COMMENT comments. I've addressed most of the "COMMENT" feedback in the following PR: https://github.com/ietf-wg-acme/acme/pull/451 Further replies inline below. As a note, I'm a bit starved for time. Because I don't have a usecase for account key binding and have not implemented it I defer to others in the WG for comments related to section 7.3.5. > It's probably worth going over the examples and checking whether nonce > values are repeated in ways that are inconsistent with expected usage. For > example, I see these three values appearing multiple times (but I did not > cross-check if a nonce returned in the Replay-Nonce response header was > then used in a JWS header attribute): > 2 K60BWPrMQG9SDxBDS_xtSw > 3 IXVHDyxIRGcTE0VSblhPzw > 4 JHb54aT_KTXBWQOzGYkt9A Good idea. I did a pass to check for inconsistencies. > Different types of certificates reflect different kinds of CA > verification of information about the certificate subject. "Domain > Validation" (DV) certificates are by far the most common type. The > only validation the CA is required to perform in the DV issuance > process is to verify that the requester has effective control of the > domain. > > Can we get an (informative) ref for the "required"/requirements? Done. > W3C.CR-cors-2013-0129 shows up as "outdated" when I follow the link. Thanks. Seems like we should use W3C.CR-cors-20140116 instead. Fixed. > IMPORTANT: The JSON Web Signature and Encryption Algorithms registry does > not appear to include an explicit indicator of whether an algorithm is > MAC-based; do we need to include text on how to make such a determination? Unfortunate. I added text saying the "Alogrithm Description" should not mention MAC/HMAC. Please suggest alternative text if you don't like mine. > For servers following the "SHOULD ... string equality check" and for > requests where the equality check fails, does that fall into the "MUST > reject the request as unauthorized" bucket? Yes. Clarified. > In order to protect ACME resources from any possible replay attacks, > ACME requests have a mandatory anti-replay mechanism. > > We don't seem to actually define what an "ACME request" is that I can see. > >From context, this requirement only applies to JWS POST bodies, and not to, > say, newNonce, but I wonder if some clarification would be useful. Sure, fixed to "ACME POST requests have a ...". > IMPORTANT: How tightly are these nonces scoped? Are they only good on a > specific TLS connection? Bound to an account key pair? Globally valid? > (This is not a DISCUSS point because AFAICT there is no loss in security if > the nonce space is global to the server.) It should be left to the server to accept/reject and the client to retry as described. I don't think the specification should prescribe the way nonces are scoped by the server operator. > IMPORTANT: Providing an accountDoesNotExist error type probably means we > need to give guidance that the server should choose account URLs in a > non-guessable way, to avoid account enumeration attacks. I think this is covered in https://github.com/ietf-wg-acme/acme/pull/445 >[...] Servers >MUST NOT use the ACME URN namespace Section 9.6 for errors other than >the standard types. > > "standard" as determined by inclusion in this document, or in the IANA registry? Alexey raised this as well and a fix is included in PR https://github.com/ietf-wg-acme/acme/pull/442 > The "up" link relation for going from certificate to chain seems to only be > needed for alternate content types that can only represent a single > certificate. (Also, the "alternate" link relation is used to provide > alternate certifciation chains.) Could this text be made more clear? I'm not sure I understand the part that isn't clear. Do you have a suggested edit? > Presumably this is just my confusion, but what does "GET order certificate" mean? It means sending a GET request to the URL found in the Certificate field of a valid status Order resource. > [...] It is a JSON >object, whose field names are drawn from the following table and >whose values are the corresponding URLs. > > Er, from the IANA registry, right? Fixed. > The following metadata items are defined, all of which are OPTIONAL: > Maybe also refer to the registry? Fixed. > IMPORTANT: I'm unclear if the "contact" is supposed to be a "talk to a > human" thing or not. If there are supposed to be different URLs that are > used for different purposes, wouldn't more metadata be needed about them? > So it seems most likely that this is indeed "talk to a human", in which > case that might be worth mentioning. (Are these always going to be > mailto:?) The text says the contact is for "contacting the client for issues related to this account". I don't think it matters whether it be for talking to a human or not. They are not always going to be mailto:, that is clarified in
Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)
On Fri, Aug 31, 2018 at 01:46:24PM -0400, Richard Barnes wrote:
> On Fri, Aug 31, 2018 at 1:39 PM Benjamin Kaduk wrote:
>
> > On Fri, Aug 31, 2018 at 12:32:08PM -0400, Richard Barnes wrote:
> > >
> > > > Do you want to mention that the caaIdentities element gives a leaf cert
> > > > some control over the trust anchors that are used, in the security
> > > > considerations? (This is a serious question; I am leaning towards it
> > being
> > > > worth doing, but it would not be very hard to convince me otherwise.)
> > > >
> > >
> > > I'm not sure what you mean by "caaIdentities element gives a leaf cert
> > some
> > > control over the trust anchors that are used". Who is controlling whose
> > > use of trust anchors, and how?
> >
> > The scenario I had in mind, which may be completely bogus, was that you
> > have a CDN/whatever in front of the ACME server; that CDN's EE cert could
> > in principle be signed by a different CA hierarchy than the ACME server is
> > doing issuance for. So you have a TLS cert from CA XYZ that is the
> > authentication on a statement "use CAA value for CA ABC". If the
> > ACME
> > client and its friends then go off and installs as their CAA record
> > with a large TTL, when the client goes to ask for a cert, ABC goes and
> > checks the CAA record and says "nothing doing". If ABC caches for the full
> > TTL, the client might have to find a different CA (perhaps one that does
> > not use an actively harmful CDN to front its operations, heh). This seems
> > to only differ from the case of a CDN just dropping traffic on the floor or
> > the other DoS vectors available to it, by virtue of the long TTL on the CAA
> > record -- even after ABC decides that this CDN is evil and switches, that
> > bogus CAA record is still valid. Maybe it's better to say that the CDN's
> > EE cert is controlling which trust anchor is *not* used [for issuing
> > certificates for the client's domain] than to say it controls which trust
> > anchor is used.
> >
>
> I agree that the TTL is the only issue here, and I don't think even that's
> an issue. RFC 6844 already requires CAs to be self-reliant and do their
> own recursing ("Data cached by third parties MUST NOT be relied on"), so
> they won't be stuck behind someone else's cache. And it seems like CAs
> have an incentive to get fresh data, since if they don't issue because of a
> bad cached CAA record, they're losing business.
>
> So I don't think there's anything to resolve here.
If you think that the CA will be willing to ignore its local cache and
re-fetch, I'm okay with dropping this topic.
-Benjamin
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)
On Fri, Aug 31, 2018 at 1:39 PM Benjamin Kaduk wrote:
> On Fri, Aug 31, 2018 at 12:32:08PM -0400, Richard Barnes wrote:
> > I've started a PR for your DISCUSS comments here:
> >
> > https://github.com/ietf-wg-acme/acme/pull/447
> >
> > Right now, there are the following major edits there:
> >
> > - Added some text to the Security Considerations that clarifies that the
> > only protection we provide against an ACME MitM is that we prevent it
> from
> > getting improper authorization. We don't prevent it from doing downgrade
> > attacks or DoS.
> >
> > - Added an explicit statement that there are no restrictions on the use
> of
> > 0-RTT
> >
> > - Clarified what contents are expected in the "challenges" array
> >
> > Some more comments inline below. Comments addressed by PR / overcome by
> > events trimmed.
> >
> >
> > On Thu, Aug 30, 2018 at 8:06 PM Benjamin Kaduk wrote:
> >
> > > > > Section 7.1.1 discusses how the server can include a caaIdentities
> > > element
> > > > > in its directory metadata; does this (or anything else) need to be
> > > > > integrity protected by anything stronger than the Web PKI cert
> > > > > authenticating the HTTPS connection? It seems that a bogus
> > > caaIdentities
> > > > > value could lead to an unfortunate DoS in some cases.
> > > > >
> > > >
> > > > I don't know what you would consider stronger than a WebPKI cert.
> You
> > > > could use a secondary key that isn't provided to the CDN and do JWS
> in
> > > the
> > > > server-to-client direction. But that would require clients to
> configure
> > > a
> > > > public key as well as a URL, and you would have to figure out
> whether you
> > > > wanted caching or anti-replay and build the corresponding addenda to
> JWS.
> > > > All in all, a lot of complexity for marginal benefit, especially this
> > > late
> > > > in the game.
> > >
> > > Yeah, it's clearly a lot of complexity for marginal benefit (since the
> DoS
> > > would likely be easy to notice and recover from) and late in the game.
> > > Though the CA does already have a key that the client trusts...
> > >
> >
> > I guess it's true that the CA could present a key certified by its
> trusted
> > root, say in the directory object. But that just turns the complexity
> knob
> > even higher :)
>
> Yup. And having the trusted root directly sign a statement of CAA
> identifiers is probably right out for many reasons, including X.509
> constraints and it being a bad idea operationally to pull out your offline
> key to do something this mundane.
>
> >
> >
> > > Do you want to mention that the caaIdentities element gives a leaf cert
> > > some control over the trust anchors that are used, in the security
> > > considerations? (This is a serious question; I am leaning towards it
> being
> > > worth doing, but it would not be very hard to convince me otherwise.)
> > >
> >
> > I'm not sure what you mean by "caaIdentities element gives a leaf cert
> some
> > control over the trust anchors that are used". Who is controlling whose
> > use of trust anchors, and how?
>
> The scenario I had in mind, which may be completely bogus, was that you
> have a CDN/whatever in front of the ACME server; that CDN's EE cert could
> in principle be signed by a different CA hierarchy than the ACME server is
> doing issuance for. So you have a TLS cert from CA XYZ that is the
> authentication on a statement "use CAA value for CA ABC". If the
> ACME
> client and its friends then go off and installs as their CAA record
> with a large TTL, when the client goes to ask for a cert, ABC goes and
> checks the CAA record and says "nothing doing". If ABC caches for the full
> TTL, the client might have to find a different CA (perhaps one that does
> not use an actively harmful CDN to front its operations, heh). This seems
> to only differ from the case of a CDN just dropping traffic on the floor or
> the other DoS vectors available to it, by virtue of the long TTL on the CAA
> record -- even after ABC decides that this CDN is evil and switches, that
> bogus CAA record is still valid. Maybe it's better to say that the CDN's
> EE cert is controlling which trust anchor is *not* used [for issuing
> certificates for the client's domain] than to say it controls which trust
> anchor is used.
>
I agree that the TTL is the only issue here, and I don't think even that's
an issue. RFC 6844 already requires CAs to be self-reliant and do their
own recursing ("Data cached by third parties MUST NOT be relied on"), so
they won't be stuck behind someone else's cache. And it seems like CAs
have an incentive to get fresh data, since if they don't issue because of a
bad cached CAA record, they're losing business.
So I don't think there's anything to resolve here.
--Richard
>
> -Benjamin
>
>
> >
> >
> >
> >
> > On Thu, Aug 30, 2018 at 8:06 PM Benjamin Kaduk wrote:
> >
> > > On Wed, Aug 29, 2018 at 09:10:06PM -0400, Richard Barnes wrote:
> > > > Hi Ben,
> > > >
> > > > Thanks for the detailed review.
Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)
I've started a PR for your DISCUSS comments here: https://github.com/ietf-wg-acme/acme/pull/447 Right now, there are the following major edits there: - Added some text to the Security Considerations that clarifies that the only protection we provide against an ACME MitM is that we prevent it from getting improper authorization. We don't prevent it from doing downgrade attacks or DoS. - Added an explicit statement that there are no restrictions on the use of 0-RTT - Clarified what contents are expected in the "challenges" array Some more comments inline below. Comments addressed by PR / overcome by events trimmed. On Thu, Aug 30, 2018 at 8:06 PM Benjamin Kaduk wrote: > > > Section 7.1.1 discusses how the server can include a caaIdentities > element > > > in its directory metadata; does this (or anything else) need to be > > > integrity protected by anything stronger than the Web PKI cert > > > authenticating the HTTPS connection? It seems that a bogus > caaIdentities > > > value could lead to an unfortunate DoS in some cases. > > > > > > > I don't know what you would consider stronger than a WebPKI cert. You > > could use a secondary key that isn't provided to the CDN and do JWS in > the > > server-to-client direction. But that would require clients to configure > a > > public key as well as a URL, and you would have to figure out whether you > > wanted caching or anti-replay and build the corresponding addenda to JWS. > > All in all, a lot of complexity for marginal benefit, especially this > late > > in the game. > > Yeah, it's clearly a lot of complexity for marginal benefit (since the DoS > would likely be easy to notice and recover from) and late in the game. > Though the CA does already have a key that the client trusts... > I guess it's true that the CA could present a key certified by its trusted root, say in the directory object. But that just turns the complexity knob even higher :) > Do you want to mention that the caaIdentities element gives a leaf cert > some control over the trust anchors that are used, in the security > considerations? (This is a serious question; I am leaning towards it being > worth doing, but it would not be very hard to convince me otherwise.) > I'm not sure what you mean by "caaIdentities element gives a leaf cert some control over the trust anchors that are used". Who is controlling whose use of trust anchors, and how? On Thu, Aug 30, 2018 at 8:06 PM Benjamin Kaduk wrote: > On Wed, Aug 29, 2018 at 09:10:06PM -0400, Richard Barnes wrote: > > Hi Ben, > > > > Thanks for the detailed review. Responses to the DISCUSS comments > inline. > > My co-author Daniel McCarney is working on the COMMENT comments. > > > > --Richard > > > > On Wed, Aug 29, 2018 at 2:53 PM Benjamin Kaduk wrote: > > > > > > > > It looks like the server returns an unauthenticated > "badSignatureAlgorithm" > > > error when the client sends a JWS using an unsupported signature > algorithm > > > (Section 6.2). What prevents an active attacker from performing a > > > downgrade attack on the signature algorithm used? > > > > > > > HTTPS, and the minimum requirements established in this document. We can > > add some comments to the Security Considerations if you want. > > It's probably worth some security considerations text. > (BTW, I was more picky than usual for this doc, since apparently TLS MitM > capabilities are explicitly in the threat model via the > "CDN-in-front-of-ACME-server" case. So in some sense that is implying that > the web PKI is not quite good enough for that channel.) > > > > > > > > Similarly, since we include in the threat model a potentially hostile > > > CDN/MitM between the ACME client and ACME server, can that attacker > strip a > > > success response and replace it with a badNonce error, causing the > client > > > to retry (and thus duplicate the request processing on the server)? > > > > > > > In the spectrum of DoS attacks the CDN could wage against the server, > this > > seems pretty lame. The CDN could also just stop forwarding requests. > > > > In other words, I don't really think the > > (incomplete sentence) > But yes, I was thinking about this some more after I balloted and it did > end up seeming likely innocuous by comparison. It's still good to have > people more familiar with the document than me think about the > possibilities, though -- it seems like most things the client would be > trying to do are relatively idempotent (that is, new challenge tokens and > such could be generated, but that's easy to recover from unless the CDN is > blocking lots of stuff, in which case nothing works anyway), but maybe I > missed something. > > > > > > I am not an ART AD, but there is not yet an internationalization > > > directorate, and seeing statements like "inputs for digest computations > > > MUST be encoded using the UTF-8 character set" (Section 5) without > > > additional discussion of normalization and/or what the canonical form > for > >
Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)
On Wed, Aug 29, 2018 at 09:10:06PM -0400, Richard Barnes wrote: > Hi Ben, > > Thanks for the detailed review. Responses to the DISCUSS comments inline. > My co-author Daniel McCarney is working on the COMMENT comments. > > --Richard > > On Wed, Aug 29, 2018 at 2:53 PM Benjamin Kaduk wrote: > > > > > It looks like the server returns an unauthenticated "badSignatureAlgorithm" > > error when the client sends a JWS using an unsupported signature algorithm > > (Section 6.2). What prevents an active attacker from performing a > > downgrade attack on the signature algorithm used? > > > > HTTPS, and the minimum requirements established in this document. We can > add some comments to the Security Considerations if you want. It's probably worth some security considerations text. (BTW, I was more picky than usual for this doc, since apparently TLS MitM capabilities are explicitly in the threat model via the "CDN-in-front-of-ACME-server" case. So in some sense that is implying that the web PKI is not quite good enough for that channel.) > > > > Similarly, since we include in the threat model a potentially hostile > > CDN/MitM between the ACME client and ACME server, can that attacker strip a > > success response and replace it with a badNonce error, causing the client > > to retry (and thus duplicate the request processing on the server)? > > > > In the spectrum of DoS attacks the CDN could wage against the server, this > seems pretty lame. The CDN could also just stop forwarding requests. > > In other words, I don't really think the (incomplete sentence) But yes, I was thinking about this some more after I balloted and it did end up seeming likely innocuous by comparison. It's still good to have people more familiar with the document than me think about the possibilities, though -- it seems like most things the client would be trying to do are relatively idempotent (that is, new challenge tokens and such could be generated, but that's easy to recover from unless the CDN is blocking lots of stuff, in which case nothing works anyway), but maybe I missed something. > > > I am not an ART AD, but there is not yet an internationalization > > directorate, and seeing statements like "inputs for digest computations > > MUST be encoded using the UTF-8 character set" (Section 5) without > > additional discussion of normalization and/or what the canonical form for > > the digest input is makes me nervous. Has sufficient internationalization > > review been performed to ensure that there are no latent issues in this > > space? > > > > Two of the three ART ADs have already signed off, so we have that going for > us :) > > The only place we have human-readable text is in the problem documents, so > at that level, the i18n considerations are handled by that spec. Other > than that, everything is ASCII, so saying "UTF-8" is just a fancy way of > saying, "don't send extra zero bytes". [this thread forked] > > > > Section 6.1 has text discussing TLS 1.3's 0-RTT mode. If this text is > > intended to be a profile that defines/allows the use of TLS 1.3 0-RTT data > > for the ACME protocol, I think you need to be more specific and say > > something like "MAY allow clients to send early data (0-RTT); there are no > > ACME-specific restrictions on which types of requests are permitted in > > 0-RTT", since the runtime configuration is just 0-RTT yes/no, and the > > protocol spec is in charge of saying which PDUs are allowed or not. > > > > The risk for HTTPS with 0-RTT is replay of requests. The text already > notes that that is not an issue for ACME requests because they have their > own anti-replay protection. There are no restrictions on which PDUs are > allowed. What further specificity do you need? I would like it to be explicitly stated that there are no restrictions on which PDUs are allowed. If it helps, I'm trying to make a distinction between "you can negotiate 0-RTT in the TLS handshake" and "this is what you can put in early data"; in my mind, an application profile should explicitly cover the latter. > > > > Section 6.2 notes that servers MUST NOT respond to GET requests for > > sensitvie resources. Why are account resources the only sensitive ones? > > Are authorizations not sensitive? Or are those considered to fall under > > the umbrella of "account resources" (Section 7.1 seems pretty clear that > > they do not)? > > > > That sentence has an overly prescriptive tone. Obviously it's up to the > CA's policy what it considers sensitive. (Some especially profligate CA > that's not subject to GDPR might be OK publishing its account objects.) > Happy to dial it back to something like "For example, most CAs will likely > consider account resources to be sensitive." I think this is basically going to be subsumed/rendered OBE by Adam's DISCUSS; please let me know if you think there is more to talk about here. > > > > Section 7.1.1 discusses how the server can include a caaIdentities
Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)
Hi all, On Thu, Aug 30, 2018, at 2:58 AM, Ben Campbell wrote: > > >> On Aug 29, 2018, at 8:10 PM, Richard Barnes wrote: >> >> >>> I am not an ART AD, but there is not yet an internationalization >>> directorate, and seeing statements like "inputs for digest >>> computations>>> MUST be encoded using the UTF-8 character set" (Section 5) >>> without >>> additional discussion of normalization and/or what the canonical >>> form for>>> the digest input is makes me nervous. Has sufficient >>> internationalization>>> review been performed to ensure that there are no >>> latent issues >>> in this>>> space? >> >> Two of the three ART ADs have already signed off, so we have that >> going for us :)>> >> The only place we have human-readable text is in the problem >> documents, so at that level, the i18n considerations are handled by >> that spec. Other than that, everything is ASCII, so saying "UTF-8" >> is just a fancy way of saying, "don't send extra zero bytes".>> > > I am an ART AD, for what it’s worth :-) > > I didn’t sweat this because of the exact reason mentioned; that is, > this seems mostly not intended to be read by humans.Agreed. And JSON should be encoded in UTF-8, so stating that explicitly is a good thing. > On a related note, I did note some heartburn about the reference to > RFC 3492 for IDNA, but for the purposes of ACME I suspect that’s the > right thing to do. OTOH, Alexey is more of an expert on IDNA than I > am. Alexey? RFC 3492 defines Punicode, i.e. how to encode U-labels in ASCII to produce A-labels. This particular encoding hasn't changed between IDNA2003 and IDNA2008, so I think referencing it is Ok. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)
> On Aug 29, 2018, at 8:10 PM, Richard Barnes wrote: > > > I am not an ART AD, but there is not yet an internationalization > directorate, and seeing statements like "inputs for digest computations > MUST be encoded using the UTF-8 character set" (Section 5) without > additional discussion of normalization and/or what the canonical form for > the digest input is makes me nervous. Has sufficient internationalization > review been performed to ensure that there are no latent issues in this > space? > > Two of the three ART ADs have already signed off, so we have that going for > us :) > > The only place we have human-readable text is in the problem documents, so at > that level, the i18n considerations are handled by that spec. Other than > that, everything is ASCII, so saying "UTF-8" is just a fancy way of saying, > "don't send extra zero bytes". > I am an ART AD, for what it’s worth :-) I didn’t sweat this because of the exact reason mentioned; that is, this seems mostly not intended to be read by humans. On a related note, I did note some heartburn about the reference to RFC 3492 for IDNA, but for the purposes of ACME I suspect that’s the right thing to do. OTOH, Alexey is more of an expert on IDNA than I am. Alexey? Ben. signature.asc Description: Message signed with OpenPGP ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)
Hi Ben,
Thanks for the detailed review. Responses to the DISCUSS comments inline.
My co-author Daniel McCarney is working on the COMMENT comments.
--Richard
On Wed, Aug 29, 2018 at 2:53 PM Benjamin Kaduk wrote:
>
> It looks like the server returns an unauthenticated "badSignatureAlgorithm"
> error when the client sends a JWS using an unsupported signature algorithm
> (Section 6.2). What prevents an active attacker from performing a
> downgrade attack on the signature algorithm used?
>
HTTPS, and the minimum requirements established in this document. We can
add some comments to the Security Considerations if you want.
> Similarly, since we include in the threat model a potentially hostile
> CDN/MitM between the ACME client and ACME server, can that attacker strip a
> success response and replace it with a badNonce error, causing the client
> to retry (and thus duplicate the request processing on the server)?
>
In the spectrum of DoS attacks the CDN could wage against the server, this
seems pretty lame. The CDN could also just stop forwarding requests.
In other words, I don't really think the
> I am not an ART AD, but there is not yet an internationalization
> directorate, and seeing statements like "inputs for digest computations
> MUST be encoded using the UTF-8 character set" (Section 5) without
> additional discussion of normalization and/or what the canonical form for
> the digest input is makes me nervous. Has sufficient internationalization
> review been performed to ensure that there are no latent issues in this
> space?
>
Two of the three ART ADs have already signed off, so we have that going for
us :)
The only place we have human-readable text is in the problem documents, so
at that level, the i18n considerations are handled by that spec. Other
than that, everything is ASCII, so saying "UTF-8" is just a fancy way of
saying, "don't send extra zero bytes".
> Section 6.1 has text discussing TLS 1.3's 0-RTT mode. If this text is
> intended to be a profile that defines/allows the use of TLS 1.3 0-RTT data
> for the ACME protocol, I think you need to be more specific and say
> something like "MAY allow clients to send early data (0-RTT); there are no
> ACME-specific restrictions on which types of requests are permitted in
> 0-RTT", since the runtime configuration is just 0-RTT yes/no, and the
> protocol spec is in charge of saying which PDUs are allowed or not.
>
The risk for HTTPS with 0-RTT is replay of requests. The text already
notes that that is not an issue for ACME requests because they have their
own anti-replay protection. There are no restrictions on which PDUs are
allowed. What further specificity do you need?
> Section 6.2 notes that servers MUST NOT respond to GET requests for
> sensitvie resources. Why are account resources the only sensitive ones?
> Are authorizations not sensitive? Or are those considered to fall under
> the umbrella of "account resources" (Section 7.1 seems pretty clear that
> they do not)?
>
That sentence has an overly prescriptive tone. Obviously it's up to the
CA's policy what it considers sensitive. (Some especially profligate CA
that's not subject to GDPR might be OK publishing its account objects.)
Happy to dial it back to something like "For example, most CAs will likely
consider account resources to be sensitive."
> Section 7.1.1 discusses how the server can include a caaIdentities element
> in its directory metadata; does this (or anything else) need to be
> integrity protected by anything stronger than the Web PKI cert
> authenticating the HTTPS connection? It seems that a bogus caaIdentities
> value could lead to an unfortunate DoS in some cases.
>
I don't know what you would consider stronger than a WebPKI cert. You
could use a secondary key that isn't provided to the CDN and do JWS in the
server-to-client direction. But that would require clients to configure a
public key as well as a URL, and you would have to figure out whether you
wanted caching or anti-replay and build the corresponding addenda to JWS.
All in all, a lot of complexity for marginal benefit, especially this late
in the game.
> I am also a bit uncertain if the document is internally consistent about
> whether one challenge verification suffices or there can be cases when
> multiple challenge verifications are required for a successful
> authorization. I attmpted to note relevant snippets of the text in my
> comments on Section 7.1.4.
>
The document is clear that (1) any one challenge is sufficient for a given
authorization ("the server should consider any one of the challenges
sufficient to make the authorization valid") and (2) the server may provide
multiple authorizations in the order object if it requires multiple
different validations.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
