Subject: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

From: Alexey Melnikov <[email-masked]>
Date: Wed, 29 Aug 2018 04:14:35 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-acme-acme-14: No Objection

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/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for this very important document. I would like to switch to "Yes",
but please first review and respond to my comments:

First mentions of JSON and HTTPS need references.

6.4.1.  Replay-Nonce

   The "Replay-Nonce" header field includes a server-generated value
   that the server can use to detect unauthorized replay in future
   client requests.  The server MUST generate the value provided in
   Replay-Nonce in such a way that they are unique to each message, with
   high probability.  For instance, it is acceptable to generate Replay-
   Nonces randomly.

   The value of the Replay-Nonce field MUST be an octet string encoded
   according to the base64url encoding described in Section 2 of
   [RFC7515].  Clients MUST ignore invalid Replay-Nonce values.  The
   ABNF [RFC5234] for the Replay-Nonce header field follows:

     base64url = [A-Z] / [a-z] / [0-9] / "-" / "_"

This is not correct ABNF. Change range syntax in Section 3.4 of RFC 5234

     Replay-Nonce = *base64url

You allow for empty nonce here. Should this be "1*base64url"?

Please add normative references for Retry-After and Link header fields.

In Section 6.6:

  | unsupportedIdentifier   | Identifier is not supported, but may be |
   |                         | in future

Do you mean "identifier type", not identifier?

   This list is not exhaustive.  The server MAY return errors whose
   "type" field is set to a URI other than those defined above.  Servers
   MUST NOT use the ACME URN namespace Section 9.6 for errors other than
   the standard types.

I think this text is misleading, as you create a registry for these.
I suggest you rephrase and add a reference to the registry.

In 7.1.1:

   caaIdentities (optional, array of string):  Each string MUST be a
      lowercase hostname which the ACME server recognizes as referring

Is hostname fully qualified? U-label IDNA domains not allowed here? Please
clarify.

      to itself for the purposes of CAA record validation as defined in
      [RFC6844].  This allows clients to determine the correct issuer
      domain name to use when configuring CAA records.

Example in 7.1.1 (or maybe even earlier): You probably should say that some
header fields are omitted here.

In 7.1.2:

   contact (optional, array of string):  An array of URLs that the

Which URI schemes are allowed (or at least expected) here?

      server can use to contact the client for issues related to this
      account.  For example, the server may wish to notify the client
      about server-initiated revocation or certificate expiration.

In 7.4:

   Clients SHOULD NOT make any assumptions about the sort order of
   "identifiers" or "authorizations" elements in the returned order
   object.

Why is this a SHOULD NOT and not a MUST NOT?

(Similar text in other sections!)

7.4.2.  Downloading the Certificate

   GET /acme/cert/asdf HTTP/1.1
   Host: example.com
   Accept: application/pkix-cert

I think your example is wrong, as Accept value needs to match
application/pem-certificate-chain returned below:

   HTTP/1.1 200 OK
   Content-Type: application/pem-certificate-chain
   Link: <https://example.com/acme/some-directory>;rel="index"

   -----BEGIN CERTIFICATE-----
   [End-entity certificate contents]
   -----END CERTIFICATE-----
   -----BEGIN CERTIFICATE-----
   [Issuer certificate contents]
   -----END CERTIFICATE-----
   -----BEGIN CERTIFICATE-----
   [Other certificate contents]
   -----END CERTIFICATE-----

In 8.3:

   The server SHOULD follow redirects when dereferencing the URL.

Why only a SHOULD?

9.1.  MIME Type: application/pem-certificate-chain

   The "Media Types" registry should be updated with the following
   additional value:

   MIME media type name: application

   MIME subtype name: pem-certificate-chain

   Required parameters: None

   Optional parameters: None

   Encoding considerations: None

This value has to be one of "7bit", "8bit", "binary" or "framed". I think this
should be "7bit", as PEM is ASCII.

   Security considerations: Carries a cryptographic certificate and its
   associated certificate chain

I suggest you add text saying that this media type doesn't include active
content.

   Interoperability considerations: None

   Published specification: draft-ietf-acme-acme [[ RFC EDITOR: Please
   replace draft-ietf-acme-acme above with the RFC number assigned to
   this ]]

   Applications which use this media type: Any MIME-compliant transport

This text is not actually useful for Media Type reviewers or users.
You should say "ACME client and servers" or something like this. Giving more
examples of use would be a plus.

You are also missing some fields from the registration template. In particular,
who is the Change Controller? (IETF or IESG)

9.6.  URN Sub-namespace for ACME (urn:ietf:params:acme)

   Repository:  URL-TBD

Who needs to fix this value?

9.7.1.  Fields in Account Objects

   o  Field type: The type of value to be provided, e.g., string,
      boolean, array of string

Here and in all similar registries: I think you should insert "JSON" before
"type" to make it clear that types are only restricted to JSON type choices.

9.7.8.  Validation Methods

   Template:

   o  Identifier Type: The type of identifier that this method applies
      to

I think you should add "or a special keyword RESERVED", as otherwise the table
below might be confusing.

   o  ACME: "Y" if the validation method corresponds to an ACME
      challenge type; "N" otherwise.

I think this could have been clearer, as it is not obvious when "N" can be
used. For example you use "N" for "RESERVED" values.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 29 Aug 2018 11:03:23 -0400

Hi Alexey,

Thanks for the comments.  A couple of replies are below; resulting edits
are in this PR:

https://github.com/ietf-wg-acme/acme/pull/442

--Richard

> https://datatracker.ietf.org/doc/draft-ietf-acme-acme/

I've updated to try to fix this, but your review on the PR would be
appreciated.

> You allow for empty nonce here. Should this be "1*base64url"?

Done.

These already have normative references at their first appearance:

https://tools.ietf.org/html/draft-ietf-acme-acme-14#section-6.5

Do you think those references are incorrect?

> Do you mean "identifier type", not identifier?

Done.

> I suggest you rephrase and add a reference to the registry.

Clarified that the MUST NOT means "don't use unregistered values"

> Is hostname fully qualified? U-label IDNA domains not allowed here? Please

These are only provided for matching against CAA records (RFC 6844), so the
simplest thing is to just require that they be equal.  In practice, that
means ASCII-names.

> header fields are omitted here.

I think that is clear enough from context.

> Which URI schemes are allowed (or at least expected) here?

Basically, servers must support "mailto", and may support others; they can
specify their requirements in an error message.

https://tools.ietf.org/html/draft-ietf-acme-acme-14#section-7.3

The WG discussed this and decided not to have more negotiation here.  See,
e.g.:

https://mailarchive.ietf.org/arch/msg/acme/TW8sbspUIGDGbIldaqWW0k9jKYo

> Why is this a SHOULD NOT and not a MUST NOT?

Done.

I don't see "sort order" anywhere else, or other relevant usage of
"order".  Do you have other places in mind?

> application/pem-certificate-chain returned below:

Done.

>    The server SHOULD follow redirects when dereferencing the URL.

Some server operators wanted to have the option to require that the
validation work on the first request.

> should be "7bit", as PEM is ASCII.

Done.

> I suggest you add text saying that this media type doesn't include active

Done.

> examples of use would be a plus.

Done.

> Who needs to fix this value?

There's a request to the RFC editor below.

> "type" to make it clear that types are only restricted to JSON type

It's a JSON object.  If you define a non-JSON type, you're gonna have a bad
time.

> used. For example you use "N" for "RESERVED" values.

Clarified that for non-ACME values, the identifier type is "N/A".

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 29 Aug 2018 16:26:26 +0100

Hi Richard,

On 29/08/2018 16:03, Richard Barnes wrote:
> Hi Alexey,
>
> Thanks for the comments.  A couple of replies are below; resulting 
> edits are in this PR:
>

I deleted comments where we are in agreement. More comments below:

>
> --Richard
>
>
> On Wed, Aug 29, 2018 at 7:14 AM Alexey Melnikov 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Please refer to
>     https://www.ietf.org/iesg/statement/discuss-criteria.html

The correct form is (I didn't check if you usxe correct hex values):

base64url = (%x40-5A) / (%x61-7A) / (%x30-39) / "-" / "_"

(I.e., don't include "%x" after "-" and don't have spaces before or 
after "-".) BTW, you can use "BAP"on tools.ietf.org to verify ABNF.

> Do you think those references are incorrect?

I was reading out of order, so this is fine. But a new nit: "header" --> 
"header field". ("Header" is a collection of all HTTP header fields 
present in a request or response).

> Basically, servers must support "mailto", and may support others; they 
> can specify their requirements in an error message.

You don't mention "mailto:" till later and you don't even mention 
"tel:". I appreciate that you don't want to have an exhaustive list 
here, but I think you should still provide a bit more guidance.

> The WG discussed this and decided not to have more negotiation here.  
> See, e.g.:
>

That is fine.

> "order".  Do you have other places in mind?

This might have existed in earlier versions. I will double check.

> validation work on the first request.

I think SHOULD basically makes redirects non interoperable. I think a 
bit more text explaining why SHOULD or change this to MUST. Also, if 
there are some security issues related to redirects, adding a pointer 
here would be good.

> There's a request to the RFC editor below.

Ok.

> It's a JSON object.  If you define a non-JSON type, you're gonna have 
> a bad time.

Maybe I am dealing with too much CBOR/CDDL recently, which allows for 
more types.

---

From: Daniel McCarney <[email-masked]>
Date: Wed, 29 Aug 2018 12:07:21 -0400

> bit more text explaining why SHOULD or change this to MUST. Also, if there
> are some security issues related to redirects, adding a pointer here would
> be good.
>

I'm slightly adverse to changing this to a MUST. There's been some recent
discussion[0] on redirects in domain validation by the CA/Browser Forum
validation working group that makes it pretty clear there isn't a universal
agreement on how CA's should handle redirects. While I disagree with the
proposals to ban following redirects outright there is a possibility that
consensus goes that direction and a MUST for processing redirects in ACME
could be problematic.

Unfortunately I think this is a case where some CAs will decide following
redirects in certain conditions is acceptable and where other CAs will
decide to never follow a redirect and ACME shouldn't prescribe CA policy.

I understand that this makes provisioning a challenge response such that it
will be inter-operable with all ACME CAs more difficult but there are a
number of ways I expect this would be challenging beyond support for
redirects (e.g. one CA may heed the recommendation to use DNSSEC and one
may not. A challenge response provisioned behind a domain with an invalid
DNSSEC configuration would not interoperate).

[0] - https://cabforum.org/pipermail/validation/2018-August/000990.html

On Wed, Aug 29, 2018 at 11:26 AM, Alexey Melnikov <[email-masked]

> (I.e., don't include "%x" after "-" and don't have spaces before or after
> "-".) BTW, you can use "BAP"on tools.ietf.org to verify ABNF.
>
>
>
>
> "header field". ("Header" is a collection of all HTTP header fields present
> in a request or response).
>
>
>
>
>> In 7.1.2:
>>
> You don't mention "mailto:" till later and you don't even mention "tel:".
> I appreciate that you don't want to have an exhaustive list here, but I
> think you should still provide a bit more guidance.
>
> I think SHOULD basically makes redirects non interoperable. I think a bit
> more text explaining why SHOULD or change this to MUST. Also, if there are
> some security issues related to redirects, adding a pointer here would be
> good.
>
> It's a JSON object.  If you define a non-JSON type, you're gonna have a
> bad time.
>
>
> Maybe I am dealing with too much CBOR/CDDL recently, which allows for more
> types.
>
>
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 29 Aug 2018 12:31:42 -0400

Updated the PR.  Trimmed below.

Done.

> in a request or response).
Did a scan through, and I think I hit all of these.  LMK if you see others.

> think you should still provide a bit more guidance.
Added a forward pointer to the guidance below.  If you have other things
you'd like to recommend, please send text.

> some security issues related to redirects, adding a pointer here would be
Fair point.  I've changed to MUST for now; let's see if anyone objects on
the mailing list.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 29 Aug 2018 16:55:09 +0000

I read the link you posted, thanks.

As long as we’re not breaking the HTTP spec, I agree that SHOULD seems to get the most interop.  As long as we’re getting signed reponses back, I don’t think it matters much where the redirect sends you.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 29 Aug 2018 13:09:59 -0400

I noticed that we already had some text in the security considerations
about redirects, so I reverted to SHOULD and added a forward pointer.

> More limited forms of delegation can also lead to an unintended
> party gaining the ability to successfully complete a validation
> transaction. For example, suppose an ACME server follows HTTP
> redirects in HTTP validation and a website operator provisions a
> catch-all redirect rule that redirects requests for unknown
> resources to a different domain. Then the target of the redirect
> could use that to get a certificate through HTTP validation since
> the validation path will not be known to the primary server.

https://github.com/ietf-wg-acme/acme/pull/442/files#diff-8430e2aa241beb4ac49b252db20d4ee8R2492

Alexey: Can you live with this solution?  There is some residual interop
risk, but (1) that's kind of unavoidable given the uncertainty here, and
(2) redirects are an easy-ish thing to debug and adapt if there's a
mismatch.  And at least the reasoning is pretty well documented now.

--Richard

On Wed, Aug 29, 2018 at 12:55 PM Salz, Rich <[email-masked]> wrote:

> As long as we’re not breaking the HTTP spec, I agree that SHOULD seems to
> get the most interop.  As long as we’re getting signed reponses back, I
> don’t think it matters much where the redirect sends you.
>
>
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 29 Aug 2018 15:44:40 -0500

> As long as we’re not breaking the HTTP spec, I agree that SHOULD seems to get the most interop.  As long as we’re getting signed reponses back, I don’t think it matters much where the redirect send…

Maybe I just missed it, but are we getting a signed response back?  I
thought it was just the plaintext key authorization.

-Benjamin

---

From: Alan Doherty <[email-masked]>
Date: Thu, 30 Aug 2018 00:03:09 +0100

At 17:07 29/08/2018  Wednesday, Daniel McCarney wrote:
>>Â I think SHOULD basically makes redirects non interoperable. I think a bit more text explaining why SHOULD or change this to MUST. Also, if there are some security issues related to redirects, adding a pointer here would be good.
>
>
>I'm slightly adverse to changing this to a MUST. There's been some recent discussion[0] on redirects in domain validation by the CA/Browser Forum validation working group that makes it pretty clear there isn't a universal agreement on how CA's should handle redirects. While I disagree with the proposals to ban following redirects outright 

I would hate if they ever do (as getting dumb devices to redirect http://whatever/.well-known/acme-callenge/* to smarter http server(running the acme client) and http://whatever/* to https://whatever/  for normal users

is a lot easier than getting them redeveloped to serve custom content (challenge response) or run native acme-client

(as all my dumb devices needing certs currently do with some tweaking, then acme-client just uploads/reconfigs new cert when done)

>there is a possibility that consensus goes that direction and a MUST for processing redirects in ACME could be problematic.
>
>Unfortunately I think this is a case where some CAs will decide following redirects in certain conditions is acceptable and where other CAs will decide to never follow a redirect and ACME shouldn't prescribe CA policy.Â 
>
>I understand that this makes provisioning a challenge response such that it will be inter-operable with all ACME CAs more difficult but there are a number of ways I expect this would be challenging beyond support for redirects (e.g. one CA may heed the recommendation to use DNSSEC and one may not. A challenge response provisioned behind a domain with an invalid DNSSEC configuration would not interoperate).
>
>
>[0] -Â <https://cabforum.org/pipermail/validation/2018-August/000990.html>https://cabforum.org/pipermail/validation/2018-August/000990.html
>
>On Wed, Aug 29, 2018 at 11:26 AM, Alexey Melnikov <<mailto:[email-masked]>[email-masked]> wrote:
>
>Hi Richard,
>>Thanks for the comments.Â  A couple of replies are below; resulting edits are in this PR:
>>
>><https://github.com/ietf-wg-acme/acme/pull/442>https://github.com/ietf-wg-acme/acme/pull/442
>
>
>>On Wed, Aug 29, 2018 at 7:14 AM Alexey Melnikov <<mailto:[email-masked]>[email-masked]> wrote:
>>Please refer to <https://www.ietf.org/iesg/statement/discuss-criteria.html>https://www.ietf.org/iesg/statement/discuss-criteria.html
>><https://datatracker.ietf.org/doc/draft-ietf-acme-acme/>https://datatracker.ietf.org/doc/draft-ietf-acme-acme/
>>
>>
>>
>>6.4.1.Â  Replay-Nonce
>>Â  Â The "Replay-Nonce" header field includes a server-generated value
>>Â  Â that the server can use to detect unauthorized replay in future
>>Â  Â client requests.Â  The server MUST generate the value provided in
>>Â  Â Replay-Nonce in such a way that they are unique to each message, with
>>Â  Â high probability.Â  For instance, it is acceptable to generate Replay-
>>Â  Â Nonces randomly.
>>
>>Â  Â The value of the Replay-Nonce field MUST be an octet string encoded
>>Â  Â according to the base64url encoding described in Section 2 of
>>Â  Â [RFC7515].Â  Clients MUST ignore invalid Replay-Nonce values.Â  The
>>Â  Â ABNF [RFC5234] for the Replay-Nonce header field follows:
>>
>>Â  Â  Â base64url = [A-Z] / [a-z] / [0-9] / "-" / "_"
>>
>>I've updated to try to fix this, but your review on the PR would be appreciated.
>
>(I.e., don't include "%x" after "-" and don't have spaces before or after "-".) BTW, you can use "BAP"on <http://tools.ietf.org>tools.ietf.org to verify ABNF.
>
>
>>Â 
>><https://tools.ietf.org/html/draft-ietf-acme-acme-14#section-6.5>https://tools.ietf.org/html/draft-ietf-acme-acme-14#section-6.5
>>
>I was reading out of order, so this is fine. But a new nit: "header" --> "header field". ("Header" is a collection of all HTTP header fields present in a request or response).
>
>
>>Â 
>>In 7.1.2:
>>
>>Â  Â contact (optional, array of string):Â  An array of URLs that the
>>
>>Basically, servers must support "mailto", and may support others; they can specify their requirements in an error message.
>
>You don't mention "mailto:" till later and you don't even mention "tel:". I appreciate that you don't want to have an exhaustive list here, but I think you should still provide a bit more guidance.
>><https://tools.ietf.org/html/draft-ietf-acme-acme-14#section-7.3>https://tools.ietf.org/html/draft-ietf-acme-acme-14#section-7.3
>>
>>The WG discussed this and decided not to have more negotiation here.Â  See, e.g.:
>>
>><https://mailarchive.ietf.org/arch/msg/acme/TW8sbspUIGDGbIldaqWW0k9jKYo>https://mailarchive.ietf.org/arch/msg/acme/TW8sbspUIGDGbIldaqWW0k9jKYo
>
>That is fine.
>
>
>>Â  
>>I don't see "sort order" anywhere else, or other relevant usage of "order".Â  Do you have other places in mind?
>
>Â  
>>Â  Â The server SHOULD follow redirects when dereferencing the URL.
>>
>>Why only a SHOULD?
>>
>>
>>Some server operators wanted to have the option to require that the validation work on the first request.
>
>
>I think SHOULD basically makes redirects non interoperable. I think a bit more text explaining why SHOULD or change this to MUST. Also, if there are some security issues related to redirects, adding a pointer here would be good.
>
>>9.6.Â  URN Sub-namespace for ACME (urn:ietf:params:acme)
>>
>>Â  Â Repository:Â  URL-TBD
>>
>>Â 
>>9.7.1.Â  Fields in Account Objects
>>
>>Â  Â oÂ  Field type: The type of value to be provided, e.g., string,
>>Â  Â  Â  boolean, array of string
>>
>>It's a JSON object.Â  If you define a non-JSON type, you're gonna have a bad time.
>
>
>Maybe I am dealing with too much CBOR/CDDL recently, which allows for more types.
>
>
>
>_______________________________________________
>Acme mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/acme

---

From: "Manger, James" <[email-masked]>
Date: Thu, 30 Aug 2018 02:41:29 +0000

> base64url = (%x40-5A) / (%x61-7A) / (%x30-39) / "-" / "_"

“A” is %x41 (not %x40)

--
James Manger

---

From: Tim Hollebeek <[email-masked]>
Date: Thu, 30 Aug 2018 06:11:34 +0000

For what it’s worth, there’s a discussion going on in the validation working group right now about how redirects should be handled.  The most likely outcome is either pretty severe restrictions around redirects, or completely disallowing them.  

In the interest of openness, CAs were asked to disclose their current redirect behavior as a basis for a discussion about what the requirements should be.  Two CAs have done so.  Others are strongly encouraged to do so.

There is no explicit text allowing them, so it could be argued that the BRs currently don’t allow following redirects.  On the other hand, redirects are part of HTTP, so the argument can also be made that “retrieving a web page” can involve arbitrary redirects, including potentially things like meta refresh and javascript.  The fact that such a diverse range of interpretations are possible is something we’d love to fix.

In particular, non-HTTP redirects that involve parsing page content introduce a great deal of complexity and risk into the validation process, and I’d like to clarify that that definitely isn’t allowed.

Redirects to a location outside of the domain being validated are viewed with particular suspicion by many, including me.  Redirects within the same domain seem less problematic, and indeed useful for handling large numbers of domains.  Though it’s not clear this solves a use case that is not already handled by the ability to validate and Authorization Domain Name and use it for subdomains.

The main reason to allow redirects within a domain is if there is a unilateral redirect from example.com to www.example.com <http://www.example.com> , which is of course incredibly common.  It seems one should be able to validate example.com using that redirect.

At least one large CA supports the “no redirects at all” position.

-Tim

From: Acme <[email-masked]> On Behalf Of Richard Barnes
Sent: Wednesday, August 29, 2018 7:10 PM
To: Salz, Rich <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>; [email-masked]; IETF ACME <[email-masked]>; Daniel McCarney <[email-masked]>; Yoav Nir <[email-masked]>; The IESG <[email-masked]>; <[email-masked]> <[email-masked]>; Alexey Melnikov <[email-masked]>
Subject: Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

I noticed that we already had some text in the security considerations about redirects, so I reverted to SHOULD and added a forward pointer.

Alexey: Can you live with this solution?  There is some residual interop risk, but (1) that's kind of unavoidable given the uncertainty here, and (2) redirects are an easy-ish thing to debug and adapt if there's a mismatch.  And at least the reasoning is pretty well documented now.

--Richard

On Wed, Aug 29, 2018 at 12:55 PM Salz, Rich <[email-masked] <mailto:[email-masked]> > wrote:

---

From: Tim Hollebeek <[email-masked]>
Date: Thu, 30 Aug 2018 12:06:35 +0000

Trimming recipients due to moderation.

-Tim

From: Tim Hollebeek 
Sent: Thursday, August 30, 2018 8:12 AM
To: 'Richard Barnes' <[email-masked]>; Salz, Rich <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>; [email-masked]; IETF ACME <[email-masked]>; Daniel McCarney <[email-masked]>; Yoav Nir <[email-masked]>; The IESG <[email-masked]>; <[email-masked]> <[email-masked]>; Alexey Melnikov <[email-masked]>
Subject: RE: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

-Tim

From: Acme <[email-masked] <mailto:[email-masked]> > On Behalf Of Richard Barnes
Sent: Wednesday, August 29, 2018 7:10 PM
To: Salz, Rich <[email-masked] <mailto:[email-masked]> >
Cc: Alexey Melnikov <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; IETF ACME <[email-masked] <mailto:[email-masked]> >; Daniel McCarney <[email-masked] <mailto:[email-masked]> >; Yoav Nir <[email-masked] <mailto:[email-masked]> >; The IESG <[email-masked] <mailto:[email-masked]> >; <[email-masked] <mailto:[email-masked]> > <[email-masked] <mailto:[email-masked]> >; Alexey Melnikov <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Thu, 30 Aug 2018 08:20:44 -0400

Thanks, James.  Fixed in the PR.

---

From: Corey Bonnell <[email-masked]>
Date: Thu, 30 Aug 2018 13:01:42 +0000

Hello,
I just wanted to point out that RFC 5234 defines a core set of production rules in Appendix B (https://tools.ietf.org/html/rfc5234#appendix-B) that define commonly used rules such as “DIGIT”, “ALPHA”, etc. Using them would make the base64url rule clearer:

base64url = ALPHA / DIGIT / “-“ / “_”

Thanks,
Corey

From: Acme <[email-masked]> on behalf of Richard Barnes <[email-masked]>
Date: Thursday, August 30, 2018 at 8:21 AM
To: "Manger, James H" <[email-masked]>
Cc: IETF ACME <[email-masked]>
Subject: Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

“A” is %x41 (not %x40)

--
James Manger

---

From: Richard Barnes <[email-masked]>
Date: Thu, 30 Aug 2018 09:46:42 -0400

Thanks, Corey.  Updated the PR.

On Thu, Aug 30, 2018 at 9:01 AM Corey Bonnell <[email-masked]>
wrote:

> Hello,
>
> I just wanted to point out that RFC 5234 defines a core set of production
> rules in Appendix B (https://tools.ietf.org/html/rfc5234#appendix-B) that
> define commonly used rules such as “DIGIT”, “ALPHA”, etc. Using them would
> make the base64url rule clearer:
>
>
>
> *From: *Acme <[email-masked]> on behalf of Richard Barnes
> <[email-masked]>
> *Date: *Thursday, August 30, 2018 at 8:21 AM
> *To: *"Manger, James H" <[email-masked]>
> *Cc: *IETF ACME <[email-masked]>
> *Subject: *Re: [Acme] Alexey Melnikov's No Objection on
> draft-ietf-acme-acme-14: (with COMMENT)
>
>
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 30 Aug 2018 21:28:00 +0300

On Thu, Aug 30, 2018 at 12:06:35PM +0000, Tim Hollebeek wrote:

> In the interest of openness, CAs were asked to disclose their
> current redirect behavior as a basis for a discussion about what
> the requirements should be.  Two CAs have done so.  Others are
> strongly encouraged to do so.

AFAIK, Let's Encrypt follows most HTTP-level (HTTP 3xx) redirects.
Including between TLDs (e.g. example.com -> foo.example is valid
and followed). However, port can not be specified and numeric IP
addresses can not be used. Of schemes, only http:// and https:// are
allowed.

I do not know all the specifics, including the precise list of status
codes (I would presume 301, 302, 303, 307 and 308) or the recursion
limit (I would presume it is at least 5).

The Let's Encrypt integration guide (aimed at big provoders that
want to get certificates on behalf of their customers) specifically
mentions redirects as a way to handle validation with multi-server
farms.

> There is no explicit text allowing them, so it could be argued that
> the BRs currently don’t allow following redirects.  On the other
> hand, redirects are part of HTTP, so the argument can also be made
> that “retrieving a web page” can involve arbitrary redirects,
> including potentially things like meta refresh and javascript.  The
> fact that such a diverse range of interpretations are possible is
> something we’d love to fix.

Even if following redirects are interpretted to be part of HTTP, that
only applies to 301 (and its alias 308), 302 (with its alias 307) and
303 redirects (and potential future ones). Not to any content-side
redirects from browser world.

The behavior of curl (a very widely-used non-browser HTTP client) is
to not follow any redirects by default. It does have option to
follow 3xx redirects (the 301 and 302 handling is buggy, but the bugs
are not relevant here and there exists further options to fix that).
It can not follow non-3xx "redirects" under any circumstancs.

> In particular, non-HTTP redirects that involve parsing page content
> introduce a great deal of complexity and risk into the validation
> process, and I’d like to clarify that that definitely isn’t allowed.

In general, it is good idea to be very picky about validation page
content (like ACME HTTP-01 is). This makes exploiting bad redirects
harder (especially non-injective ones, which are ocassionally seen).

Based on my (most probably wrong) reading of method 6, CAs can use
substring match for the required content. Which would make exploiting
some kinds of bad redirects for misvalidation much easier.

(That is not the only problem with method 6, it also contains language
(on ADN) very similar to very troublesome language in methods 9 and
10.)

> Redirects to a location outside of the domain being validated are
> viewed with particular suspicion by many, including me.  Redirects
> within the same domain seem less problematic, and indeed useful for
> handling large numbers of domains.  Though it’s not clear this solves
> a use case that is not already handled by the ability to validate
> and Authorization Domain Name and use it for subdomains.

The name to get a certificate for can be delegated user name (e.g.,
via CNAME), and in that case, the hoster can not use any related name.

Also, ACME does not let one specify what ADN to use in case there are
multiple possibilities for ADN to use in given validation.

Now, any reverse proxy (including Apache and Nginx) has a facility to
essentially perform invisble redirects on the server side (where the
server forwards the query to somewhere else and sends back the
response). I do not know to what degree one could replace redirects
used for validation in multi-server environments with such facilities.
However, I am aware of one security protocol, where one has to be able
to use such facility if one delegates, as configuration needs to be
consistent, and redirects are banned entierely.

> The main reason to allow redirects within a domain is if there is a
> unilateral redirect from example.com to www.example.com
> <http://www.example.com> , which is of course incredibly common.  It
> seems one should be able to validate example.com using that redirect.

I have no data on potentially exploitable redirects on-domain versus
off-domain, but I can say that even some http://foo.example to
https://foo.example redirects are exploitable (especially with
substring matching, but sometimes even without that).

The following two types of redirects seem practicularly troublesome:

- Redirect is from above validation directory (usually via global
  redirect of any resource on name). http:// to https:// redirects
  and redirects from example.com to www.example.com are usually of
  this kind. In contrast, redirects specific to validation directory
  are very probably secure.
- Redirects that are not injective (multiple source URLs map to the
  same target URL.). These are invariably from above validation
  directory redirects.

Then I saw somebody argue that redirecting .well-known globally
is misconfiguration. And indeed, that place is grab-bag of different
things, some of which prohibit redirects, some which leave things
implicit and some that explicitly follow redirects.

-Ilari

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 30 Aug 2018 14:49:35 -0400

> implicit and some that explicitly follow redirects.

I'm not sure why either of these are particularly troublesome, given the
requirements, and giving the use of either the Random Value (which must be
random) or it being bound to the request.

Is the issue here one of redirects, or the (as practiced by CAs)
distinction between "the presence of" versus "the contents shall be".

That is, if the CA/Browser Forum required that the contents be explicit
(and/or with a mime-type requirement), does that resolve the matter with
redirects? (I ask, because that's one of the already identified structural
weaknesses of 3.2.2.4.6)