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

[Daniel McCarney <[e-mail]>]

>
> > 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 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 <[e-mail]
> wrote:

> 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:
>
> https://github.com/ietf-wg-acme/acme/pull/442
>
>
> I deleted comments where we are in agreement. More comments below:
>
>
> --Richard
>
>
> On Wed, Aug 29, 2018 at 7:14 AM Alexey Melnikov <[e-mail]>
> wrote:
>
>> 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
>>
>
> I've updated to try to fix this, but your review on the PR would be
> appreciated.
>
> 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.
>
>
>
>
>> Please add normative references for Retry-After and Link header fields.
>>
>
> 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?
>
>
> 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
>>
>> 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.
>
> 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
>
> The WG discussed this and decided not to have more negotiation here.  See,
> e.g.:
>
> https://mailarchive.ietf.org/arch/msg/acme/TW8sbspUIGDGbIldaqWW0k9jKYo
>
> That is fine.
>
>
>
>
>> (Similar text in other sections!)
>>
>
> I don't see "sort order" anywhere else, or other relevant usage of
> "order".  Do you have other places in mind?
>
> This might have existed in earlier versions. I will double check.
>
>
>
> In 8.3:
>>
>>    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
>>
>> Who needs to fix this value?
>>
>
> There's a request to the RFC editor below.
>
>
> Ok.
>
>
>
>> 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.
>>
>
> 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.
>
>
>