Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

Richard Barnes <rlb@ipv.sx> Thu, 30 August 2018 01:10 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91BC130ED6 for <acme@ietfa.amsl.com>; Wed, 29 Aug 2018 18:10:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7T3mP0UAjuYi for <acme@ietfa.amsl.com>; Wed, 29 Aug 2018 18:10:29 -0700 (PDT)
Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B362130EEF for <acme@ietf.org>; Wed, 29 Aug 2018 18:10:21 -0700 (PDT)
Received: by mail-oi0-x22b.google.com with SMTP id b15-v6so12548265oib.10 for <acme@ietf.org>; Wed, 29 Aug 2018 18:10:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kgqAqHGQTaS4mMoQ7DvHTDnD8O0afKgQ0BZ4UPi/y0c=; b=k4aJQxW2Qr6aT3vUPGaaUoTDKFMIb/uyXrZ5KK7FTZ/yldxroNBdDCXVULfHiCB/rQ mob75hMPRiMY9Sp0TnBsgkN0CYZ+yiilGmBp5mKVUQn352+CYLr9o+TvQOzqt1t4szLx 5H+Wik7PKmQmYrrVIB89e+f/tDxW7DCWJnX1zi6WI6fA7GvzQmUtd7t2RV2qCcO4zWCb zwVDSG5gdbgX9ymlZt3I1Nn+skkcS6MII1dXzRJl5JripkwkKxBbobu6Wsr+qIbcKFHR w2nFVxXq7OPgXUlFZD2l9MxNuXrQwrAiSlfIMFJEkpwBeQ7/Ip1PflKTZXLnk3Xrds9z ErRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kgqAqHGQTaS4mMoQ7DvHTDnD8O0afKgQ0BZ4UPi/y0c=; b=W7hzKBU6qbBhTjT+9mZCEq11+mYUeAarMcSN+xNd2JXgScXv6RHGOUyMnJgL/dxtad Gwp5NBSSzDoxAj6u3T4BIT3Hz++O7rPazjLXHcG8tIG9VoMGSTKmZGFgksMZ6F0j4XCa 2alnkz7hBOoWDXZ6aN55Dtm1FrRtrQzyuI8FJUH3nh75Q2mHwDrKSm9UFD26Un3W2jCp UlapvizWRJuw2R0w5ajjB+9iUbjIYOoKpafZQ1gAR1h506o3h3XkC34gXcBD3Z4/EwpY Y+a9sgtMArK1Ntt1bH2QXarIAwg6aWggKjVnuaQ+kIlB6+HKQCXRbqBO2DA6HszAP0rv q8sQ==
X-Gm-Message-State: APzg51C4p9Zx+DMEiXgcCoX+RWlhKfwc2Yn6lcU7H4VjOWkt+bLezDRz jI5/sOymwXEwdRXDLLpQI6s1SYPekp1Bibkt3O2tAg==
X-Google-Smtp-Source: ANB0Vdb67eMtRip4G37/5j+urVLkBLG+hknv5IUtpdekFC9Pme+/QJnhrIeOboiZbaT6ZENPGWPPCtxH7MOClUlsNwM=
X-Received: by 2002:aca:6b87:: with SMTP id g129-v6mr367889oic.88.1535591420718; Wed, 29 Aug 2018 18:10:20 -0700 (PDT)
MIME-Version: 1.0
References: <153556883241.14872.599302420878484743.idtracker@ietfa.amsl.com>
In-Reply-To: <153556883241.14872.599302420878484743.idtracker@ietfa.amsl.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Wed, 29 Aug 2018 21:10:06 -0400
Message-ID: <CAL02cgQoC1YAA1wjftoFSMBfm7Vi4KUXUQW633GZ5tM9VMMrmg@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, draft-ietf-acme-acme@ietf.org, Yoav Nir <ynir.ietf@gmail.com>, "<acme-chairs@ietf.org>" <acme-chairs@ietf.org>, IETF ACME <acme@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002702f705749cbd62"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/kTNBYxMZuLMUhPw4_mo2ENkEsGg>
Subject: Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Aug 2018 01:10:31 -0000

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 <kaduk@mit.edu> 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.