Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)
On Mon, Sep 24, 2018 at 11:54:42AM -0400, Daniel McCarney wrote: > Here's another PR with further feedback: > https://github.com/ietf-wg-acme/acme/pull/453 > > Replies in-line below. Also in-line. > > 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. I was only suggesting it because this part felt like an introduction that was enumerating an exhaustive list of usage of the "link" header field. If that's not the intent, then my comment is not relevant and should be ignored. > > 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. >From what I remember of it going by, I agree that it's clear now. > > 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. It should (though my understanding was that all four were optional, so there would be no need to use the word "optionally" twice). > > 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 read it as "if the server requires X, it does Y. If the server doesn't require X, we don't specify anything.", and security reviewers generally try to avoid dangling edge cases. Explicitly saying that "when the termsOfService subfield is present, the client MUST indicate agreement before service can be provided" (or similar) would resolve the alleged edge case. > > 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. Ah, that sounds good -- thanks. > > 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". Sounds good; sorry for spending so much time on this point, which is in the grand scheme of things quite minor. > > In particular, right now I think that the text about "participating in the > > creation" is inaccurate. > > Rephrased to say that the entropy requirement only preven
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
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 7.
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 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. -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. 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 tex
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. Respons
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 ele
Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)
On Wed, Aug 29, 2018 at 08:58:59PM -0500, 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. I also didn't expect any issues, but felt the need to explicitly check :) (BTW, what are the digest computations that are referred to? I was not sure on first read.) I think that we've discussed this point enough, and will reply to the other ones on a different fork of the thread. -Benjamin > 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. ___ 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 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
[Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-acme-acme-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ -- DISCUSS: -- This is a great thing to have, and I intend to eventually ballot Yes, but I do have some questions that may require further discussion before this document is approved. 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? 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)? 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? 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. 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)? 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 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. I also have some important substantive comments in the section-by-section COMMENTS, since they would not in and of themselves block publication. -- COMMENT: -- This document was quite easy to read -- thank you for the clear prose and document structure! It did leave me with some questions as to whether there are missing clarifications, though, so there are a pile of notes in the section-by-section comments below. It seems natural to feel some unease when the concept of automated certificate issuance like this comes up. As far as I can tell, though, the only substantive difference between this flow and the flow it's replacing is that this one qualitatively feels like it weakens the "know your customer" aspect for the CA -- with current/legacy methods registering for an account can be slow and involves real-world information. Such can be spoofed/forged, of course, but ACME seems to be weakening some aspect by automating it. Given the spoofability, though, this weakening does not seem to be a particular concern with the document. I was going to suggest mentioning the potential for future work in doing time-delayed or periodic revalidation or other schemes to look at the stability of the way that identifiers/challenges were validated, but I see that discussion has already happened. 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 Re