Re: [Acme] scope in dns-account-01 and dns-02 challenge

[Jacob Hoffman-Andrews]

Ilari, you've posted some useful extrapolations on how domain scopes could
work. I'm proposing to get rid of domain scopes. :D To get us on the same
page, would you mind posting some of the specific use cases you're
envisioning where domain scopes would be used in an ACME environment? My
existing belief is that domain scopes are only useful when validation is
non-automated, but I could be wrong here.

On Thu, Mar 21, 2024 at 3:26 AM Ilari Liusvaara 
wrote:

> On Wed, Mar 20, 2024 at 08:57:11PM -0400, Amir Omidi wrote:
> > I do think that this draft can do a better job describing the scope. I
> > think we should make it more explicit for the client to understand which
> > one will be used. I feel like splitting this challenge into three (and
> > potentially more, as extra scopes may or may not be added into the
> future)
> > might be a little too noisy.
> >
> > What do you think about a `scope` field in the authorization resource the
> > server sends creates/communicates with the client? Clients opting into
> > dns02, or dns-account-01 will use this to know exactly what scope the
> > server is expecting from them for their ACME order.
>
> The problem with this is that there might be multiple valid scopes, not
> just a single valid scope. And clients often have only one that will
> work, the rest will fail (often in rather bad ways).
>
> The obvious scope is is host/wildcard on the target name. However, if
> CA allows domain scope, thee will be N+1 more, where N is the maximum
> allowed strip (might be 0, might be more).
>
> In another mail, I proposed:
>
> - If CA allows domain scope, it sends maximum allowed strip in the
>   challenge. Otherwise only host/wildcard scope is allowed.
> - If client selects domain scope, it sends strip used in the POST to
>   the challenge URL. Otherwise host/wildcard scope is selected.
>
>
>
>
> -Ilari
>
> ___
> 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] scope in dns-account-01 and dns-02 challenge

[Jacob Hoffman-Andrews]

On Wed, Mar 20, 2024 at 5:57 PM Amir Omidi  wrote:

> I feel like splitting this challenge into three (and potentially more, as
> extra scopes may or may not be added into the future) might be a little too
> noisy.
>

Combined with my other proposals, we only wind up with two total challenge
types: `dns-account-host-01` and `dns-account-wildcard-01`. I propose to
get rid of domain scopes and the `dns-02` challenge type.

What do you think about a `scope` field in the authorization resource the
> server sends creates/communicates with the client? Clients opting into
> dns02, or dns-account-01 will use this to know exactly what scope the
> server is expecting from them for their ACME order.
>

This works, and is closest to your intention with the current draft, where
the server decides the appropriate scope and the client has to abide by it.
I do think it will be more annoying to pull into the BRs, since they will
have to have language that says "This challenge type may be used to issue
for wildcard domains if the ACME server sent `"scope": "wildcard"`."
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] expiry in dns-account-01

[Jacob Hoffman-Andrews]

The latest dns-account-01 draft (
https://datatracker.ietf.org/doc/html/draft-ietf-acme-scoped-dns-challenges-00)
incorporates recommendations from the dnsop domain control verification
draft (
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-03
).

The dnsop draft says:

> Providers MUST provide clear instructions on when a validation record can
be removed. These instructions SHOULD be encoded in the RDATA via
comma-separated ASCII key-value pairs [RFC1464], using the key "expiry" to
hold a time after which it is safe to remove the validation record.

But the ACME draft doesn't specify that. I think it should! The specified
expiry should be the expiry of the pending authorization object. After that
point, the challenge will never be validated and the record can be removed.

This brings up a separate question: Should subscribers be able to specify
what maximum lifetime they want for the validated authorization? For
instance some subscribers might want to never reuse authorizations.
Currently they can achieve that by deactivating authorizations after
issuance, but it could be more convenient to do it preemptively. One option
would be to encode it in the TXT record. But if we specify such a thing I
think we'd want it to work for any challenge type, probably by making it
part of the challenge POST. So, out of scope for this draft, I think.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] scope in dns-account-01 and dns-02 challenge

[Jacob Hoffman-Andrews]

Seo Suchan said:
> Would it be illegal to server probe both scope and pass if there is
intended token?

This is a possibility, but it's inefficient and I think it's likely to lead
to implementation bugs. Better to be clear and explicit on both sides.

Amir Omidi said:
> My intention that I should probably clarify in the draft is that the
server picks based on the Authorization object

Yep, I figured the intention was something like this. We could call this
"Server and client follow the same algorithm to arrive at the same scope."
Also a valid approach! But I think we get benefits from not having that
algorithm, even as simple as it is. For instance, the BRs say of some
methods:

> Once the FQDN has been validated using this method, the CA MAY also issue
Certificates for other FQDNs that end with all the Domain Labels of the
validated FQDN. This method is suitable for validating Wildcard Domain
Names.

If host-scoped, wildcard-scoped, and domain-scoped challenges were separate
types, it would be straightforward to adapt this language to the new
challenge types.

Ilaria Ilusvaara said:
> The client also needs to know the acceptable domains, and needs to select
the domain to use.

The domain to use is part of the authorization object: the identifier value
(https://datatracker.ietf.org/doc/html/rfc8555#section-7.1.4). It is chosen
by the server.

I think what you're getting at is that the client might feel like "I
requested a new-order for www.example.com, and the server created an
authorization object with an identifier value of www.example.com. But I
really wish the server would have created an authorization object with an
identifier value of example.com, and I would complete domain-scoped DNS
challenge." This would allow the full expressiveness permitted by BRs
3.2.2.4.7 DNS Change, which has the "MAY also issue Certificates for other
FQDNs that end with all the Domain Labels of the validated FQDN" language.

I'd actually like to go the other direction: What if we only specify
host-scoped and wildcard-scoped validations? Domain-scoped validations make
sense when validations are very manual and time consuming, and you are
trying to strictly minimize them. But ACME tries to make validations easy
and quick, so it doesn't matter if you have to do more of them. There are
still important use case for wildcard certificates, but I think there is
less need for domain-scoped validations in ACME.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] scope in dns-account-01 and dns-02 challenge

[Jacob Hoffman-Andrews]

Thanks, authors, for the updates in
https://datatracker.ietf.org/doc/html/draft-ietf-acme-scoped-dns-challenges-00
.

Adding a "scope" (host, wildcard, or subdomain) to the DNS record name is
great. Reading the draft, I think it doesn't specify how the scope for a
given challenge is decided and communicated. Three ideas:

1. Server picks, and tells the client.

The challenge object contains a "scope" field. The client verifies that the
indicated scope is one of "host", "wildcard", or "subdomain", and is less
than the maximal scope the client is willing to validate for. For instance,
a client might be configured to only accept "host" scope.

2. Client picks.

When the client POSTs to the challenge URL, instead of sending the empty
object {}, it sends {"scope": "host"}, {"scope": "wildcard"}, or {"scope":
"domain"}. The server verifies that the request scope is sufficient for the
authorization object (i.e. "wildcard" or above for an authorization object
that can be used to issue for a wildcard name), then performs the
validation.

3. Server offers options via challenge types

We explode out the challenge types from two to six:

dns-host-02
dns-wildcard-02
dns-domain-02
dns-account-host-01
dns-account-wildcard-01
dns-account-domain-01

The server populates the authorization object with only those challenge
types that are acceptable. For instance, if the authorization object can be
used to issue for a wildcard name, the server would not offer dns-host-02
or dns-account-host-01.

I like this option the best because it provides cleaner separation, and
uses the design of ACME nicely: servers offer appropriate challenges, and
clients pick the challenge that works best for them. Also it allows for
clean implementation in the BRs: they could specify by name which challenge
types are allowed to issue for wildcards.

Of course, it feels messy to define so many challenge types. Perhaps we
could eliminate the dns-02 family? The idea being that clients and servers
that wish to adopt the modern best practices from
https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/,
they can also adopt the account-scoping features of the dns-account-01
family, which are not burdensome.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [Technical Errata Reported] RFC8555 (6950)

[Jacob Hoffman-Andrews]

Deb, I agree with your analysis: I find the existing text sufficient.

Conversely, I worry that specifying entropy in terms of "generating X 
characters from the base64url alphabet" is likely to go wrong, with people 
handcrafting random selection algorithms. The spec does try to allow for 
multiple implementations, but as an FYI what we do in Boulder is generate 32 
random _bytes_ and then encode them into base64url:

https://github.com/letsencrypt/boulder/blob/c1f7de06e9f82fb6b7a599795fe7e37209733d9f/core/util.go#L62-L75

Lloyd, for general interest, this spec aimed to be compatible with the Baseline 
Requirements of the time (though now the direction has flipped, and the BRs 
normatively reference this spec). But the BRs still say:

https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-v2.0.1.pdf
> Random Value: A value specified by a CA to the Applicant that exhibits at 
> least 112 bits of entropy.

And that definition is still used in the non-ACME validation methods.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [Technical Errata Reported] RFC8555 (6843)

[Jacob Hoffman-Andrews]

Yep, still accurate. Thanks!
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [Technical Errata Reported] RFC8555 (6364)

[Jacob Hoffman-Andrews]

Agreed.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [Technical Errata Reported] RFC8555 (5861)

[Jacob Hoffman-Andrews]

> That’s fair. The text should probably state something along the lines of

 >

> “If the server has an existing authorization for the identifier, depending on 
> server policy, the server may return a 200 (OK) response with the existing 
> authorization URL in the Location header field and the existing JSON 
> authorization object in the body.”

This sounds good to me. Thanks for the update.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [Technical Errata Reported] RFC8555 (6103)

[Jacob Hoffman-Andrews]

Yeah, editorial seems right to me.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [Technical Errata Reported] RFC8555 (6317)

[Jacob Hoffman-Andrews]

I think this is "hold for update." It would specify a change to how servers 
operate in practice today.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [Editorial Errata Reported] RFC8555 (6104)

[Jacob Hoffman-Andrews]

This is about indenting and I suspect email display clients are eating the 
leading spaces. Here's what it looks like with underscores:

Old:

​___submit another order containing only the eight identifiers not listed
​___in the problem document.

HTTP/1.1 403 Forbidden
Content-Type: application/problem+json
Link: ;rel="index"

New:

​___submit another order containing only the eight identifiers not listed
​___in the problem document.

​___HTTP/1.1 403 Forbidden
​___Content-Type: application/problem+json
​___Link: ;rel="index"

In other words, the HTTP response block is incorrectly outdented. The report is 
correct, but also I suspect any revision will involve a fresh editing pass that 
would catch indentation errors. Happy to accept or reject the errata.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [Technical Errata Reported] RFC8555 (5861)

[Jacob Hoffman-Andrews]

This overspecifies things. When someone requests to create a new authorization 
object (or requests to create a new order object that would necessitate 
creation of new authorization objects), it is up to server policy whether to 
reuse an existing authorization or not. For instance a server might have a 
policy of never reusing authorization objects (that is, doing validation from 
scratch every time), or it might have a policy of reusing only pending 
authorization objects, or only ones created in the last N hours or days.

So I think we should not accept this errata as it stands.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [Technical Errata Reported] RFC8555 (6843)

[Jacob Hoffman-Andrews]

I agree with James' reading. The intent was to allow HTTP->HTTPS redirects 
during validation, and that is common practice today. The errata makes the 
language a little clearer around that, so I vote "hold for document update."

From: James Kasten 
Sent: Wednesday, February 9, 2022 7:25 AM
To: Benjamin Kaduk 
Cc: Richard Barnes ; Jacob Hoffman-Andrews ; Daniel 
McCarney ; Roman Danyliw ; deco...@nsa.gov 
; debcool...@gmail.com ; Yoav Nir 
; IETF ACME ; RFC Errata System 

Subject: Re: [Technical Errata Reported] RFC8555 (6843)

Hi Ben,

Thanks for the response.

Following redirects for the http-01 challenge is already recommended by the 
RFC's Section 8.3<https://datatracker.ietf.org/doc/html/rfc8555#section-8.3>.
```
The server SHOULD follow redirects when dereferencing the URL.
Clients might use redirects, for example, so that the response can be
provided by a centralized certificate management server.  See
Section 10.2<https://datatracker.ietf.org/doc/html/rfc8555#section-10.2> for 
security considerations related to redirects.
```

Section 10.4<https://datatracker.ietf.org/doc/html/rfc8555#section-10.4> also 
contains an additional warning or emphasis regarding redirects with SSRF, so I 
included a generic reference to both for completeness.
```
However, if the attacker first sets the domain to one
they control, then they can send the server an HTTP redirect (e.g., a
302 response) which will cause the server to query an arbitrary URL.
...
```

I believe this errata resolves ambiguity in the current text. Popular ACME CAs 
and clients are relying upon "http-01" challenge redirects from HTTP to HTTPS 
today. As an author who is familiar with the origin of this text, my intent was 
for it to read as "must be initiated" rather than "must be completed" over 
HTTP. I am happy to hear others' thoughts. I do believe deviating from this 
interpretation is extremely harmful for the HTTPS ecosystem which I can 
elaborate on if desired.

Best,
James

On Tue, Feb 8, 2022 at 10:54 PM Benjamin Kaduk 
mailto:ka...@mit.edu>> wrote:
Is there particular guidance from Section 10 that you had in mind to
justify the following of the redirect?

In light of the role of errata reports as indicating errors in the
specification at the time it was published, I think the processing options
here are either "hold for document update" or "rejected".

-Ben

On Tue, Feb 08, 2022 at 12:23:23PM -0800, RFC Errata System wrote:
> The following errata report has been submitted for RFC8555,
> "Automatic Certificate Management Environment (ACME)".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6843
>
> --
> Type: Technical
> Reported by: James Kasten mailto:jdkas...@umich.edu>>
>
> Section: 8.3
>
> Original Text
> -
> Because many web servers
> allocate a default HTTPS virtual host to a particular low-privilege
> tenant user in a subtle and non-intuitive manner, the challenge must
> be completed over HTTP, not HTTPS.
>
>
> Corrected Text
> --
> Because many web servers
> allocate a default HTTPS virtual host to a particular low-privilege
> tenant user in a subtle and non-intuitive manner, the challenge must
> be initiated over HTTP, not HTTPS.
>
> Notes
> -
> Completing the entire http-01 challenge over HTTP is unnecessary. The threat 
> of default HTTPS virtual hosts is remediated by "initiating" the http-01 
> challenge over HTTP. Validation servers which redirect from HTTP to HTTPS 
> should be permitted following the rest of the guidance within Section 10, 
> Security Considerations.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC8555 (draft-ietf-acme-acme-18)
> --
> Title   : Automatic Certificate Management Environment (ACME)
> Publication Date: March 2019
> Author(s)   : R. Barnes, J. Hoffman-Andrews, D. McCarney, J. Kasten
> Category: PROPOSED STANDARD
> Source  : Automated Certificate Management Environment
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Long-lived certificates, but frequently renewed certificates

[Jacob Hoffman-Andrews]

Roland Shoemaker sent a proposal a while back for ACME Renewal Info (ARI)
with the goal of solving both "impending revocation" and "expressing
suggested renewal times."
https://mailarchive.ietf.org/arch/msg/acme/b-RddSX8TdGYvO3f9c7Lzg6I2I4/. We
at Let's Encrypt hope to develop this idea further and implement it soon.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Conflicting requirements for retrieving an ACME account that is already bound to an external account

[Jacob Hoffman-Andrews]

I think this is the key bit:

>   - Since the server has not verified the binding, its response 'MUST NOT
reflect the "externalAccountBinding" field in the resulting account object'.

I understand "reflect" to mean "echo what the client sent." So I think it's
acceptable for the server to ignore the externalAccountBind field / not
re-verify it, and return an account object whose externalAccountBinding
field is set based on the contents of the CA's database.

> 1. A client should be permitted to omit "externalAccountBinding" from a
newAccount request when retrieving an existing account from a server that
requires external account binding.  (External account binding is a one-time
operation; as soon as an ACME account and an external account are bound
once, they're bound forever).
> 2. When a client does provide "externalAccountBinding" in a newAccount
request to retrieve an existing account from a server that requires
external account binding, the server should be required to verify that
binding and ensure that it links to the exact same external account to
which the ACME account is already bound.

I think an errata is not needed to make forward progress, but if you want
to do an errata for 1, I'd support it. I'm not enthusiastic about 2.

In general I think providing the option to look up an account by key was a
mistake. Clients already have to store one piece of state (the account
key), and asking them to store a second piece of state (the account URL) is
not onerous. Particularly in the case where the client is storing both an
account key and an external account binding, I think it's reasonable to ask
that the client store the account URL rather than add additional complexity
to the account-lookup part of the standard.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] dns-01 challenge limitations

[Jacob Hoffman-Andrews]

Here are a couple of other useful resources on addressing this problem on
the client side. Essentially, you can run your own nameserver dedicated to
answering challenges, and delegate to it with CNAMEs.

https://github.com/joohoi/acme-dns
https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation

To the question of whether Let's Encrypt would implement a new DNS-related
challenge: We're potentially interested, but as Ryan Sleevi mentioned, it
would have to be specified in detail, either in an I-D or elsewhere. It
would then need to be accepted by root programs, possibly via the
CA/Browser Forum, since that's a convenient place to get agreement among
root programs.

That's a fair amount of work, and when I last proposed a similar change in
2018 it looked like there was significant opposition:

https://mailarchive.ietf.org/arch/msg/acme/6_j3fecaxIgwNTpJ3693U_n0Kec/
https://mailarchive.ietf.org/arch/msg/acme/rIV6jrETVXO2EmoG_tmRitDL0tA/

So, right now Let's Encrypt isn't prioritizing the work to advocate for
changes here, but hearing from subscribers that have trouble with the
current DNS challenges definitely helps inform our thinking.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME subdomains

[Jacob Hoffman-Andrews]

I haven't followed the "ACME for subdomains" conversation closely, but the
base semantics of ACME are designed such that they can express "all of"
semantics AND "one of" semantics. For a given Order, a client has to fulfil
*all* the Authorizations; for a given Authorization, a client has to
fulfil *one
of* the Challenges.

To take advantage of this, you would need to define a new challenge type
that expresses validating a parent domain. For instance "dns-parent-01." It
would contain the name of the parent domain as a field.

If a server has the policy that validating control of either
foo.bar.example.com or example.com is sufficient to issue for
foo.bar.example.com, it would respond to newOrder requests for
foo.bar.example.com by creating an Order with one Authorization (for
foo.bar.example.com), and that Order would have two Challenges: "dns-01"
and "dns-parent-01" (with a parent domain of "example.com"). The client
could then choose which challenge to attempt.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [Technical Errata Reported] RFC8555 (5732)

[Jacob Hoffman-Andrews]

On 8/23/19 2:02 PM, erica wrote:
Hi, Erica from Certbot here. I'd love to see this get verified -- it 
seems impossible to implement the "retrying challenges" section as the 
spec currently stands.


As an author, I think this erratum should be approved.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Benjamin Kaduk's Yes on draft-ietf-acme-tls-alpn-06: (with COMMENT)

[Jacob Hoffman-Andrews]

On 9/30/19 6:07 PM, Benjamin Kaduk via Datatracker wrote:

the provider.  When the TLS SNI challenge was designed it was assumed
that a user would only be able to respond to TLS traffic via SNI for
domain names they controlled (i.e. if User A registered Host A and
User B registered Host B with a service provider that User A wouldn't
be able to respond to SNI traffic for Host B).  This turns out not to
be a security property provided by a number of large service
providers.  [...]

Perhaps I'm misremembering, but I don't think this characterizes exactly
the situation that led to the TLS SNI challenge being deemed
irredeemable: the issues arise when User B *has not yet* registered Host
B, and either the registration validation at the provider was lax or
User A could connive to get into the default-SNI handler.  The *attack*
was possible even when User B has registered Host B, because the
validation used a subdomain, as we discuss below, but here we are
talking about the SNI routing, which needed to be for an unregistered
(or not-validly-registered) name.
Here's the original post for reference: 
https://labs.detectify.com/2018/01/12/how-i-exploited-acme-tls-sni-01-issuing-lets-encrypt-ssl-certs-for-any-domain-using-shared-hosting/.


It actually doesn't matter whether User B has registered Host B, and it 
has nothing to do with the default-SNI handler. That was a different 
vulnerability, mainly in the "http-01" nee "simpleHttp" challenge: 
https://github.com/ietf-wg-acme/acme/pull/7/files.


Also, TLS-SNI-01 validation did not use a subdomain; it used a 
constructed name ending in ".acme.invalid".


The issue resulted from allowing someone to upload certificates to a 
hosting provider for "foo.acme.invalid" without validating their control 
of "foo.acme.invalid"'s DNS. It also happened to be the case that 
someone could in certain circumstances upload certificates for "real" 
domains they don't control, like "example.com", but that wasn't relevant 
for ACME.


Roland, since we've gotten similar feedback twice, it seems worthwhile 
to update Appendix A to directly link Frans Rosen's excellent blog post, 
and to specifically call out that this is different than the "default 
VHost" issue that led ACME to mandate that the "http-01" challenge use 
HTTP instead of HTTPS.


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Warren Kumari's Discuss on draft-ietf-acme-ip-07: (with DISCUSS and COMMENT)

[Jacob Hoffman-Andrews]

It's important to note that automated validation of IP addresses for 
certificates is already a part of the Web PKI, but is not standardized. 
This protocol will standardize it, which I believe will make  overall 
validation of IP addresses more secure, within the threat model that 
Roland described.


We could attempt to ban automated validation of IP address certificates, 
or ban IP address certificates entirely, but that wanders into the realm 
of policy rather than standards, and would be better suited to browser 
root programs IMO.


Overall, given the tradeoffs, I think it is better to have a 
standardized method of IP address validation than to have none.


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] http-01 and jws thumbnail

[Jacob Hoffman-Andrews]

At 11:55 16/07/2019  Tuesday, Stefan Eissing wrote:

A user of my Apache ACME client asked about a feature where the security 
implications are not clear to me:

- he has several server instances that may receive the CA's http-01 challenge 
request. He therefore would like all servers to answer to all challenges like the 
solution proposed by acme.sh: 


server {

  location ~ ^/\.well-known/acme-challenge/([-_a-zA-Z0-9]+)$ {
default_type text/plain;
return 200 "$1.6fXAG9VyG0IahirPEU2ZerUtItW2DHzDzD9wZaEKpqd";
  }

which sends the thumbnail back to anyone asking. Is this an example to follow? 
It feels very open...
I can't find anything terribly wrong with it. The two most important 
things are (a) it binds to the account key fingerprint, so it doesn't 
let some other person get a certificate for you, and (b) it filters by a 
narrow set of valid characters, which prevents this from being an XSS 
vector 
(https://labs.detectify.com/2018/09/04/xss-using-quirky-implementations-of-acme-http-01/).


Still, it seems like other clients get along fine with a stateful mode, 
which narrows the realm of possible unforeseen problems with this approach.


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] .well-known for dns challenges

[Jacob Hoffman-Andrews]

This seems like a clever idea! As Ted said, .well-known probably isn't 
the right directory for it. If you put something in .well-known, that 
suggests you plan to standardize it and register it with IANA.


I'll also note that you may have a bootstrapping problem: Assuming that 
you verify certificates on those polling requests to your web server, 
this solution won't work before you've actually issued your first 
certificate. Similarly, if there's every a problem that results in your 
live certificate expiring, this process would fail.


It's also worth noting that Let's Encrypt requires DNS challenges for 
wildcards because they demonstrate more control over the domain 
namespace, and are less vulnerable to temporary hacks of the web server. 
You fully control the namespace, so you definitely have the ability to 
delegate that control in any way you see fit. Just keep in mind that 
this allows someone with temporary access to your nameserver to get a 
more powerful wildcard certificate than they otherwise would be able to.


If you wanted to add some more security, you could narrow the scope of 
accepted certificates on the polling connection to your web host, or 
(even better) have some file-level signing of the fetched JSON. Since 
you control both sides, an HMAC (rather than a public key signature) 
would suffice.


Lastly, have you seen acme-dns? This might be another way to accomplish 
the same thing, and has the advantage that more people are using it and 
therefore more likely to find bugs. https://github.com/joohoi/acme-dns


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Agenda for IETF 105

[Jacob Hoffman-Andrews]

Roland's out this week, so I'm answering for him. He'll be back in time 
for IETF 105 and I assume he'll be able to dial in but haven't confirmed 
yet.


On 7/11/19 12:50 PM, Yoav Nir wrote:
draft-ietf-acme-tls-alpn seems to be stalled for months. We’ve had a 
change of AD and a new AD review ([1]). Can allocating meeting time 
help with progressing this?
Yes, I think a little meeting time would be useful to help move this 
forward.
draft-ietf-acme-ip is waiting for an AD write-up and to progress it. 
Unless Roland feels differently, I don’t think there’s much to spend 
agenda time on.

I agree we don't need agenda time for this.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [Technical Errata Reported] RFC8555 (5771)

[Jacob Hoffman-Andrews]

I'm in favor of this change in spirit, but it's pretty substantive and 
will actually do the wrong thing with some existing deployments. For 
instance, https://acme-v02.api.letsencrypt.org/directory currently has:


Cache-Control: max-age=0, no-cache, no-store

Which under this language would require clients to refetch the directory 
before every request. Definitely Let's Encrypt should fix that, but 
given that RFCs are meant to reflect "rough consensus and running code," 
I'm reluctant to make such a potentially breaking change to running code 
in an errata. I also feel a little uneasy at adding a MUST that is 
currently violated by every implementation that exists.


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [Editorial Errata Reported] RFC8555 (5735)

[Jacob Hoffman-Andrews]

I believe this should be verified.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [Technical Errata Reported] RFC8555 (5729)

[Jacob Hoffman-Andrews]

I believe this should be verified.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [Editorial Errata Reported] RFC8555 (5734)

[Jacob Hoffman-Andrews]

I believe this should be verified.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [Editorial Errata Reported] RFC8555 (5733)

[Jacob Hoffman-Andrews]

I believe this should be verified.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] RFC 8555 on Automatic Certificate Management Environment (ACME)

[Jacob Hoffman-Andrews]

Yes, big thanks! This was a huge group effort over many years, and I'm 
very grateful to everyone who has contributed to it.


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

[Jacob Hoffman-Andrews]

Pushed some more changes.

On 10/10/2018 02:06 PM, Jacob Hoffman-Andrews wrote:
Updated to include Orders and Authorizations in the example as you 
requested. https://github.com/ietf-wg-acme/acme/pull/463/files


On 10/09/2018 04:49 PM, Jacob Hoffman-Andrews wrote:


I'll revise this to include examples from the other URLs. One of my 
goals is to switch away from the "counting accounts" or "counting 
authzs" examples (which I think we can't effectively mitigate) to 
more specific examples of correlations. However, I think I can make 
that point with examples from across all the different resource types.



On 10/09/2018 12:27 PM, Richard Barnes wrote:

Thanks for the PR.

My only issue is with the changes in there that slim down the 
example.  ISTM that we should be encouraging unguessable URLs as 
widely as possible; guessable URLs should be a justified exception 
(as you noted in your description of what LE does).


If you could slim this down to just killing the "Capability URL" 
reference, I would be +1


On Tue, Oct 9, 2018 at 3:20 PM Jacob Hoffman-Andrews <mailto:j...@eff.org>> wrote:


On 10/09/2018 11:53 AM, Jacob Hoffman-Andrews wrote:
> Also, I would add a caveat that this type of URL design is only
> necessary for properties that the CA considers secret. For
instance,
> Let's Encrypt does not consider its number of accounts secret,
and
> assigns serially incrementing IDs to account URLs.
>
> I'll send a PR later today tweaking this section.

Here's a PR improving the correlations section of security
concerns:
https://github.com/ietf-wg-acme/acme/pull/463

___
Acme mailing list
Acme@ietf.org <mailto:Acme@ietf.org>
https://www.ietf.org/mailman/listinfo/acme





___
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


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

[Jacob Hoffman-Andrews]

Updated to include Orders and Authorizations in the example as you 
requested. https://github.com/ietf-wg-acme/acme/pull/463/files


On 10/09/2018 04:49 PM, Jacob Hoffman-Andrews wrote:


I'll revise this to include examples from the other URLs. One of my 
goals is to switch away from the "counting accounts" or "counting 
authzs" examples (which I think we can't effectively mitigate) to more 
specific examples of correlations. However, I think I can make that 
point with examples from across all the different resource types.



On 10/09/2018 12:27 PM, Richard Barnes wrote:

Thanks for the PR.

My only issue is with the changes in there that slim down the 
example.  ISTM that we should be encouraging unguessable URLs as 
widely as possible; guessable URLs should be a justified exception 
(as you noted in your description of what LE does).


If you could slim this down to just killing the "Capability URL" 
reference, I would be +1


On Tue, Oct 9, 2018 at 3:20 PM Jacob Hoffman-Andrews <mailto:j...@eff.org>> wrote:


On 10/09/2018 11:53 AM, Jacob Hoffman-Andrews wrote:
> Also, I would add a caveat that this type of URL design is only
> necessary for properties that the CA considers secret. For
instance,
> Let's Encrypt does not consider its number of accounts secret, and
> assigns serially incrementing IDs to account URLs.
>
> I'll send a PR later today tweaking this section.

Here's a PR improving the correlations section of security concerns:
https://github.com/ietf-wg-acme/acme/pull/463

___
Acme mailing list
Acme@ietf.org <mailto:Acme@ietf.org>
https://www.ietf.org/mailman/listinfo/acme





___
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] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

[Jacob Hoffman-Andrews]

I'll revise this to include examples from the other URLs. One of my 
goals is to switch away from the "counting accounts" or "counting 
authzs" examples (which I think we can't effectively mitigate) to more 
specific examples of correlations. However, I think I can make that 
point with examples from across all the different resource types.



On 10/09/2018 12:27 PM, Richard Barnes wrote:

Thanks for the PR.

My only issue is with the changes in there that slim down the 
example.  ISTM that we should be encouraging unguessable URLs as 
widely as possible; guessable URLs should be a justified exception (as 
you noted in your description of what LE does).


If you could slim this down to just killing the "Capability URL" 
reference, I would be +1


On Tue, Oct 9, 2018 at 3:20 PM Jacob Hoffman-Andrews <mailto:j...@eff.org>> wrote:


On 10/09/2018 11:53 AM, Jacob Hoffman-Andrews wrote:
> Also, I would add a caveat that this type of URL design is only
> necessary for properties that the CA considers secret. For
instance,
> Let's Encrypt does not consider its number of accounts secret, and
> assigns serially incrementing IDs to account URLs.
>
> I'll send a PR later today tweaking this section.

Here's a PR improving the correlations section of security concerns:
https://github.com/ietf-wg-acme/acme/pull/463

___
Acme mailing list
Acme@ietf.org <mailto: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] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

[Jacob Hoffman-Andrews]

On 10/09/2018 03:28 PM, Diego R. Lopez wrote:


If I understood this compromise proposal, that implies to put STAR out 
of play… Or am I missing something?


Not at all, it just means that STAR needs to define a new field on the 
Order resource that specifies a polling URL for frequently-updating 
certificates. This is probably a good thing anyhow, since the semantics 
of STAR are different than the normal semantics of baseline ACME. In 
baseline ACME, the contents of the certificate URL generally don't 
change after issuance, but in STAR, the goal is to have some URL whose 
contents are expected to change periodically to contain the most 
recently issued certificate for the relevant names.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

[Jacob Hoffman-Andrews]

On 10/09/2018 11:53 AM, Jacob Hoffman-Andrews wrote:
Also, I would add a caveat that this type of URL design is only 
necessary for properties that the CA considers secret. For instance, 
Let's Encrypt does not consider its number of accounts secret, and 
assigns serially incrementing IDs to account URLs.


I'll send a PR later today tweaking this section.


Here's a PR improving the correlations section of security concerns: 
https://github.com/ietf-wg-acme/acme/pull/463


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

[Jacob Hoffman-Andrews]

On 10/09/2018 07:45 AM, Richard Barnes wrote:
1. Remove GET for certificates.  I think this is a mistake, but I can 
grant that it's clunky as-is, and it will be straightforward to re-add 
it later if it's needed.


Great.

2. Keep the security considerations about capability URLs and the 
randomized examples.  Those are needed for the correlation concerns 
regardless of GET.


Ah, I had missed this. The relevant text:

> In order to avoid leaking these correlations, servers SHOULD assign
> capability URLs for dynamically-created resources
> {{?W3C.WD-capability-urls-20140218}}.  These URLs incorporate large
> unpredictable components to prevent third parties from guessing
> them.  These URLs SHOULD NOT have a structure that would enable a
> third party to infer correlations between resources.

This is not really the correct use of the term "capability URL," since 
knowledge of a URL doesn't grant access to a resource. I would instead 
just say "URLs with unpredictable components" (as the second sentence uses).


Also, I would add a caveat that this type of URL design is only 
necessary for properties that the CA considers secret. For instance, 
Let's Encrypt does not consider its number of accounts secret, and 
assigns serially incrementing IDs to account URLs.


I'll send a PR later today tweaking this section. I'll also review #460 
in more detail. In principle I'm not opposed to randomizing some of the 
entity URLs where it helps demonstrate the concepts from the security 
considerations section.


That said, I'd just like to reiterate: Capability URLs are *bad*. The 
second sentence in https://www.w3.org/TR/capability-urls/ is:


"There are times when this is useful, for example one-shot password 
reset URLs, but overuse can be problematic as URLs cannot generally be 
kept secret."


I hope no one walks away from this conversation thinking "I'd like to 
incorporate capability URLs into my next project!"


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] FW: [ietf-wg-acme/acme] Add a meta flag to indicate when GET requests for certificates are allowed (#462)

[Jacob Hoffman-Andrews]

> https://github.com/ietf-wg-acme/acme/pull/462 
 



I'm opposed to this change. It's better for STAR to just extend the 
Order object with a new "gettableCert" URL field. Less complex.


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Allow get for certificates?

[Jacob Hoffman-Andrews]

The POST-as-GET mess started because Adam Roach pointed out that the 
"orders" URL (listing all of an accounts orders), in some non-WebPKI 
contexts, could expose information that shouldn't be exposed.


There are two possible fixes for this:

The narrow fix -- Remove "orders." No one implements it, and this is the 
least disruptive option to a mature spec.


The broad fix -- Recognize that the problem with "orders" is merely a 
symptom of the fact that we designed a protocol that needlessly couples 
HTTP semantics (GET vs POST) with security properties (authenticated vs 
authenticated). Make structural changes to the protocol so we can simply 
authenticate everything and not have to decide, for each request, 
whether it should be authenticated or not.



I'm not excited to implement the broad fix: It's a significant 
disruption to an already-stable ecosystem. However, I'm willing to push 
through that disruption and do the work, if we wind up with a 
significantly better protocol - one that is consistent about how it 
authenticates everything. I'd also be happy to implement the narrow fix 
- it's zero work.


However, I can't accept a halfway fix. It's all of the work, with none 
of the benefit. For the same reason that certificates are safe to GET, 
so are authzs, challenges, and individual order URLs. Why would we go 
through the significant hassle of changing those, but not certificates?


On 10/06/2018 02:27 PM, Richard Barnes wrote:

I'm not hard set against this change, I just don't see much benefit.

Allowing GETs for certificate URLs is so low-risk that we weren't 
going to access-control it at all until a couple weeks ago.  Now it's 
so high-risk that we need to REQUIRE authentication?  That's 
"REQUIRED" in the RFC 2119 sense, since higher up in the section, it 
says that servers MUST return 405 if they get a GET, except as allowed 
in that section.


There are reasonable use cases for GETs.  STAR is one, but you could 
imagine non-auto-renewed cases as well.  There's no security reason to 
cut off those GETs, so I don't understand what value we're conserving 
here.  The PR says that having GETs complicates the security analysis, 
but this is not some inner part of the protocol, it's the output.


The only argument that seems at all cogent here is that we don't have 
any up-front signaling for whether a server supports GET or not, just 
the error code.  So clients have to guess.  Maybe that's enough to 
motivate removing it for now; a later doc could come along and say 
"allow GETs and signal it with this field in the meta object".  But if 
we do that, we should be clear that we're removing GET to keep the 
protocol flow clean, not for any security reason.


--Richard



On Sat, Oct 6, 2018 at 12:53 PM Eric Rescorla > wrote:


Speaking as Area Director: there is no process problem with this
reference. Of course, it's a WG decision whether it's advisable.

-Ekr


On Sat, Oct 6, 2018 at 8:31 AM Salz, Rich mailto:rs...@akamai.com>> wrote:

In order to address an issue raised during IESG review,
unauthenticated GET for ACME server resources was changed to a
simple POST that had a signed message body, providing
authentication. Some raised the issue that they still wanted
GET for certificates, as they’re public information and that
sometimes a different process (without the account
credentials) might be involved in the deployment workflow.
STAR was mentioned as an example.

There is now concern about calling out STAR, as it is still a
WG draft and the full extent of its requirements are not known.

If you have anything else to add to this discussion, please do
so now.

diff --git a/draft-ietf-acme-acme.md b/draft-ietf-acme-acme.md

index 26f..f1ca93f 100644

--- a/draft-ietf-acme-acme.md

+++ b/draft-ietf-acme-acme.md

@@ -463,17 +463,6 @@ resources (see {{resources}}), in
addition to POST-as-GET requests

for these resources. This enables clients to bootstrap into the

ACME authentication system.

-The server MAY allow GET requests for certificate resources in

-order to allow certificates to be fetched by a lower-privileged

-process, e.g., the web server that will use the referenced

-certificate chain. (See {{?I-D.ietf-acme-star}} for more advanced

-cases.)  A server that allows GET requests for certificate
resources

-can still provide a degree of access control by assigning them

-capability URLs {{?W3C.WD-capability-urls-20140218}}.

-As above, if the server does not allow GET requests for a given

-resource, it MUST return an error with status code 405
"Method Not

-Allowed" and type "malformed".

-

## Request URL Integrity

 It is common in deployment for the entity terminat

Re: [Acme] Backing-out capability URLs from the spec (added in #445)

[Jacob Hoffman-Andrews]

Here's my proposal that removes the STAR special-casing in ACME, making 
certificate URLs behave the same way as all other fetchable resources: 
https://github.com/ietf-wg-acme/acme/pull/459.


Sticking STAR concerns into the ACME draft so late in ACME development 
is only going to cause issues. At the point, we need to be locking 
things down and removing unused features, not introducing new fiddly 
bits for the sake of drafts that can easily be implemented as an 
extension to the main draft.


On 10/05/2018 03:55 PM, Jacob Hoffman-Andrews wrote:

>The removed language is a non-normative statement of fact

You can't introduce a new authentication method in post-Last Call 
revisions, and claim they are non-significant simply because they are 
not formally normative.


> It seems like you're trying to get rid of a better option to 
maintain the appearance architectural purity.


Nope, this is not a matter of architectural purity. Capability URLs 
are a strictly weaker authentication method than the JWS-based POSTs 
used everywhere in the protocol. If you read the doc 
(https://www.w3.org/TR/capability-urls/), it's all about the risks 
involved and how they should only be used as a last resort. The 
language we had up to draft 13 made this very explicit: GETs are not 
authenticated.


It seems like this was introduced in response to the STAR group 
requesting that final certificates be made GETtable. This was a pretty 
tenuous claim anyhow: If most ACME servers require POST for 
certificates, STAR-shaped clients won't be able to interoperate with 
them. So if you feel like STAR needs some special way to authenticate 
GETs, with lower security requirements than ACME, let's punt that to 
the STAR spec. Certificate GETs in ACME can be a MUST POST like 
everything else, and STAR can declare a "gettable certificate" extension.



___
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] Backing-out capability URLs from the spec (added in #445)

[Jacob Hoffman-Andrews]

>The removed language is a non-normative statement of fact

You can't introduce a new authentication method in post-Last Call 
revisions, and claim they are non-significant simply because they are 
not formally normative.


> It seems like you're trying to get rid of a better option to maintain 
the appearance architectural purity.


Nope, this is not a matter of architectural purity. Capability URLs are 
a strictly weaker authentication method than the JWS-based POSTs used 
everywhere in the protocol. If you read the doc 
(https://www.w3.org/TR/capability-urls/), it's all about the risks 
involved and how they should only be used as a last resort. The language 
we had up to draft 13 made this very explicit: GETs are not authenticated.


It seems like this was introduced in response to the STAR group 
requesting that final certificates be made GETtable. This was a pretty 
tenuous claim anyhow: If most ACME servers require POST for 
certificates, STAR-shaped clients won't be able to interoperate with 
them. So if you feel like STAR needs some special way to authenticate 
GETs, with lower security requirements than ACME, let's punt that to the 
STAR spec. Certificate GETs in ACME can be a MUST POST like everything 
else, and STAR can declare a "gettable certificate" extension.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Backing-out capability URLs from the spec (added in #445)

[Jacob Hoffman-Andrews]

In the rounds of reviews on 
https://github.com/ietf-wg-acme/acme/pull/445, I missed an addition: the 
suggestion to use capability URLs for access control on certificate 
URLs. We should definitely not introduce this into the spec: ACME has 
one authentication model, based on JWS signing. We shouldn't introduce 
another, weaker authentication model. I pointed this out way back in 
2015: 
https://github.com/letsencrypt/acme-spec/pull/48#issuecomment-70169712.


At the time, the WG decision was to split resources into sensitive ones 
(authenticated) and non-sensitive ones (unauthenticated). The recent 
round of POST-as-GET changes consolidates things so nearly everything is 
authenticated. I don't think there's a strong case to introduce a new, 
halfway level of authentication based on capability URLs. If we want 
certificates to be authenticated, let's authenticate them the same way 
as everything else, and let the STAR group define an extension for 
unauthenticated URLs. Here's my PR backing out the change: 
https://github.com/ietf-wg-acme/acme/pull/457


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] POST-as-GET payload contents

[Jacob Hoffman-Andrews]

On 09/05/2018 12:39 PM, Richard Barnes wrote:

Using the same notation, I'm:

1) ""
2) "urn:ietf:params:acme:get"
99) "{}"


Given that, I'm willing to compromise on "". I think the experience we 
had of almost implementing bugs with that approach was informative, but 
isn't decisive.


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] POST-as-GET payload contents

[Jacob Hoffman-Andrews]

On 09/05/2018 08:33 AM, Richard Barnes wrote:
1. A field in the protected header ("urn:ietf:params:acme:get": true) 
with a requirement that the payload be "{}"
2. A field in the payload ({"get": true}) a requirement that if that 
field be there, then there are no other fields present


I dislike both of these options as adding complexity. My preference 
order is:


1) "{}"
2) ""
99) "urn:ietf:params:acme:get"

> I'm still uncomfortable with {}, though, because it risks colliding 
with other POST uses.


The only current use it conflicts with is POSTing to challenges to 
trigger their validation. We can fix that two ways:


 - Define challenges as non-pollable: Poll authorizations instead, 
since they contain the challenges. This was something I'd proposed 
previously, in the spirit of "there should just be one way to do 
things." Right now, some clients poll authorizations and some poll 
challenges. There's no benefit to one way or the other, it's just a 
random implementer choice that sometimes exposes different code paths.


 - Define multiple POSTs to challenges as idempotent. That is, the 
first time you POST a "{}" body to a challenge it triggers validation, 
and subsequently it acts as a GET.


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME breaking change: Most GETs become POSTs

[Jacob Hoffman-Andrews]

On 08/31/2018 03:08 PM, Richard Barnes wrote:
ISSUE 1. Should we do POST-as-GET at all, vs. keeping GET and doing 
the privacy analysis?

Agreed we're solved on this.
ISSUE 2: How should we signal that POST-as-GET request is different 
from other POST requests?

Started a separate thread on this.
ISSUE 3: Should servers be required to allow GET requests for 
certificate URLs?
I'm not convinced this is absolutely necessary for the STAR use case, 
and I'm still not thrilled about carving out exceptions, but I'm okay 
leaving this as a MAY GET in the interests of landing the change.
ISSUE 4: How should we address the risk that an attacker can discover 
URLs by probing for Unauthorized vs. Not Found?


There seemed to be agreement on the list that this should be addressed 
with some guidance to servers on how to assign URLs.  I have just 
added some text to the PR for this.

This seems like a good plan to me.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] POST-as-GET payload contents

[Jacob Hoffman-Andrews]

New day, new thread for a specific issue I'd like to nail down quickly.

ISSUE 2: How should we signal that POST-as-GET request is different 
from other POST requests?


The current PR signals this by sending a JWS with an empty 
(zero-octet) payload, instead of a JSON object.  Jacob and Daniel 
suggested that we should instead use the payload being an empty JSON 
object as the signal.  An earlier draft PR used a field in the 
protected header.


In short, this question is about whether POST-as-GETs should have:

"payload": ""

or

"payload": "{}"


When implementing the first one (empty payload), Daniel and I each 
separately implemented a different bug that would have also accepted:


"payload": null

This may be quirk of Go's handling of byte arrays, but it may turn out 
to be a common pattern in JSON libraries. The downside, if a server 
implementer landed a bug like that, would be that clients might get away 
with generating the invalid "null" form, leading to interoperability 
problems.


There's also potential for client bugs that produce an empty payload 
simply due to an uninitialized field, rather than due to a POST-as-GET. 
This would produce confusing errors relating to GETs rather than a 
clearer "malformed input" error.


Lastly, many clients already implement the "{}" form as a way to GET an 
account, so expanding the use of "{}" minimizes disruption.


My preference is still for "{}" over "", but I am also willing to be 
convinced in the interests of landing this change speedily and keeping 
forward momentum.


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME breaking change: Most GETs become POSTs

[Jacob Hoffman-Andrews]

On 08/31/2018 01:51 PM, Adam Roach wrote:
The baseline problem here is that the original analysis that determined 
that orders, authorizations, challenges, and certificates were "not 
sensitive" was incorrect. These are all potentially sensitive from a 
privacy perspective. Perhaps not in isolation, but the problem here is 
correlation, not isolation.


What do you think about the question of preventing correlation of the 
existence of URLs? Do you think that's in-scope, or should we only 
prevent correlation of the contents?


Here's another example of a URL scheme where revealing existence would 
reveal some correlation data:


/account/100/certificate/example.com
/account/201/certificate/example.net
/account/100/certificate/secret.example.com

Personally, I think it will be intractable to hide the 
existence/non-existence of URLs, and we should just mention it as a risk 
in the security considerations section. That leads me to the conclusion 
that it's fine to return Unauthorized for resources that exist, by the 
client does not own.


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME breaking change: Most GETs become POSTs

[Jacob Hoffman-Andrews]

On 08/31/2018 12:30 PM, Jacob Hoffman-Andrews wrote:

/account/100/certificate/3438
/account/201/certificate/3439
/account/100/certificate/3440*


Here's an issue that came up during code review: When you POST-as-GET to 
a resource you don't own, should you get Not Found or Unauthorized? The 
quick answer is Not Found. If we return Unauthorized, that still allows 
potentially enumerating the existence of certificates URLs, which 
depending on URL schemes might reveal the grouping of certificates by 
account id.


However, if we choose Not Found, that implies we're trying to hide the 
existence of certain resources, which means checking for those resources 
has to be timing-safe, a very high bar. We wind up hiding one foot-gun 
(URL enumeration) under another foot-gun (timing attacks).


Alternately, we could consider URL enumeration out of scope, and say 
"POST-as-GET is only intended to protect the contents of resources, not 
their existence or relationship to each other."


That winds up leaving us pretty close to being back at draft-14: Since 
POST-as-GET protects resource bodies, and the currently-specified 
resources are already broken down into sensitive (account) and not 
(orders, authorizations, challenges, certificates), we could just as 
well leave the non-sensitive resources as regular GETs. We might make a 
change to define POST-as-GET as a broader mechanism, to be used by 
default by future extensions that define new resource types.


Alternately, we might say that even though orders, authorizations, 
challenges, and certificates are all non-sensitive, we should require 
POST-as-GET across the board for all ACME requests, because it will 
simplify security analysis.


What do you all think? Should enumeration of the existence of URLs be 
considered in-scope?


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME breaking change: Most GETs become POSTs

[Jacob Hoffman-Andrews]

On 08/31/2018 07:25 AM, Richard Barnes wrote:
The problem with using POST-as-GET for certificate resources, as 
Felipe I think pointed out, is that the thing that downloads the 
certificate URL is often not an ACME player, doesn't have an account, 
etc.  It's a web server or something. (cf. the STAR drafts.)  What I'm 
saying is that it's painful to make them integrate with ACME and we 
don't get any benefit.
AFAIK, no current ACME client hands off certificate URLs to 
less-privileged processes.


Keeping GETs for certificates undermines the goal of making the 
POST-as-GET change. Certificate resources may be constructed in 
enumerable ways, like:


/account/100/certificate/3438
/account/201/certificate/3439
/account/100/certificate/3440*

While many CAs may not consider correlation of certificates by account 
to be sensitive, our goal with this change is to eliminate a footgun for 
CAs who do consider it sensitive, by simply ensuring all requests are 
authenticated by default. Consistent authentication also has the 
potential to simplify by client and server libraries.


I think it would be a mistake to carve out this exception in the main 
ACME spec for use cases that are still speculative. Instead, if there is 
a use case that truly requires unauthenticated certificate retrieval, it 
should be defined as an extension or an optional feature.


In short, I think certificates should be POST-as-GET just like the other 
resources.


*Note: I'm aware that certificate serial numbers must be randomized, but 
there is no requirement that the certificate serial number be present in 
the URL.


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME breaking change: Most GETs become POSTs

[Jacob Hoffman-Andrews]

(Replying to Felipe's comment from the thread "Re: [Acme] Adam Roach's 
Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)")


On 08/30/2018 11:17 AM, Felipe Gasper wrote:
> Would it work to keep certificate fetches as plain GET?
>
> In shared hosting environments it’s common for a privileged process 
to request certificates on behalf of user accounts. This avoids having 
1,000s of ACME server registrations from a single server. While 
certificates are generally made available within seconds, theoretically 
the delay between request and issuance could be much longer (e.g., for 
OV/EV), such that it might be prudent for that privileged process to 
give the order ID to the user and have the user poll for the 
certificate, e.g., via cron.


This use case makes sense, but I think it is not critical enough to 
carve out an exception from the "GETs become POSTs" plan. If the ACME 
implementation structures certificate fetches such that they are 
enumerable, you would wind up again with the same sort of correlation 
problem Adam brought up. You could make the certificate URLs 
unpredictable, but then you've introduced a notion of capability 
URLs[1], which breaks the notion of having a single authentication 
system for ACME.


It seems just as possible for the unprivileged process to do the polling 
for the certificate, and once it's ready, make it available on the 
filesystem for the unprivileged user.


[1] https://www.w3.org/TR/capability-urls/

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] ACME breaking change: Most GETs become POSTs

[Jacob Hoffman-Andrews]

ACME currently has unauthenticated GETs for some resources. This was 
originally discussed in January 2015[1]. We decided to put all sensitive 
data in the account resource and consider all GET resources public, with 
a slant towards transparency.


Adam Roach recently pointed out in his Area Director review that even 
when the contents of GET URLs aren’t sensitive, their correlation may 
be. For instance, some CAs might consider the grouping of certificates 
by account to be sensitive.


Richard Barnes proposes[2] to change all GETs to POSTs (except directory 
and new-nonce). This will be a breaking change. Clients that were 
compatible with previous drafts, informally called ACMEv1 and ACMEv2, 
will not be compatible with a draft that mandates POSTs everywhere. It 
will be a painful change, since the ecosystem just started switching to 
ACMEv2, which looked to be near-final.


I think this is the right path forwards. ACME will be a simpler, better 
protocol long-term if all requests are authenticated. However, if we’re 
taking this path we should aim to come to consensus and land the final 
spec quickly to reduce uncertainty for ACME client implementers.


[1] https://github.com/letsencrypt/acme-spec/pull/48#issuecomment-70169712
[2] https://github.com/ietf-wg-acme/acme/pull/445/files

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME Operational best practices

[Jacob Hoffman-Andrews]

On 07/14/2018 04:38 PM, Tobias Fiebig wrote:

Back when we submitted Cloud Strife [0] to NDSS, we reached out to the list on 
pushing our mitigations toward a recommendation/best practices RFC. Given that 
with the Birge-Lee paper, there is now a second attack vector, we (Kevin 
Borgolte and I, but we are open to more collaborators and already talked with 
Prateek Mittal from the BGP MitM paper [1]) would like to author a RFC on 
mitigating IP-use-after-free/IP-misuse attacks. This RFC would summarize the 
operational recommendations as well as how various other measures can (and 
cannot, CAA for example has to be configured correctly to be helpful) mitigate 
these attacks.
The main question here is opt-in vs not. Practical deployment experience 
with ACME has shown that people frequently lose all their private keys. 
For instance, they might need to rebuild a server, and forget to store a 
copy. If a mechanism like you propose were to be enabled by default for 
all hostnames, it would effectively lock out a large number of 
subscribers from being able to get a certificate at all.


Making this opt-in is more plausible. You could do this with 
CAA.However, it might make more sense to just apply a CAA accounturi 
parameter in that case.


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Handling non-conformant CAA property names in ACME-CAA

[Jacob Hoffman-Andrews]

There's a similar issue for parameters: RFC 6844 section 3 says each 
name-value pair is separated by a semicolon:


https://tools.ietf.org/html/rfc6844#section-3
>    issue  [; = ]* :  The issue property

RFC 6844 section 5.2 says each name-value pair is separated by a space:

https://tools.ietf.org/html/rfc6844#section-5.2
>    issuevalue  = space [domain] space [";" *(space parameter) space]


For 6844-bis, in the LAMPS WG, we concluded that the latter was most 
likely an error in the ABNF, and that semicolons were preferable:


https://tools.ietf.org/html/draft-ietf-lamps-rfc6844bis-00#section-5.2
>    parameters = (parameter *WSP ";" *WSP parameters) / parameter


ACME-CAA's examples use semicolons:

https://tools.ietf.org/html/draft-ietf-acme-caa-03#appendix-A
> example.com. IN CAA 0 issue "example.net; \
> account-uri=https://example.net/account/1234; \
> validation-methods=dns-01"


We resolved the hyphen question on the basis of interoperability: Some 
DNS UIs rejected setting CAA records with hyphens in property names, so 
we did the simple thing and removed them.


The semicolon question is not so easily solved. There is no unambiguous 
reading of RFC 6844, no reason to consider section 3 more normative than 
section 5.2 or vice versa.


I have one piece of interop data: While Route53 rejected hyphens in 
property names, it accepts semicolons separating name-value pairs.


My preference is for ACME-CAA to continue follow the RFC 6844bis 
interpretation. What are others' thoughts?


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Draft authors -- please send a status

[Jacob Hoffman-Andrews]

acme-acme: Pretty much done.

On 06/27/2018 12:16 PM, Daniel McCarney wrote:
I can volunteer for being the ACME-CAA document shepherd but would 
appreciate some off-list guidance on the requirements.




On Wed, Jun 27, 2018 at 2:31 PM, Salz, Rich 
> wrote:


Is anyone interested in being the document shepherd for the CAA draft?

*From: *"Salz, Rich" mailto:40akamai@dmarc.ietf.org>>
*Date: *Wednesday, June 27, 2018 at 11:57 AM
*To: *"acme@ietf.org " mailto:acme@ietf.org>>
*Subject: *[Acme] Draft authors -- please send a status

Can the authors of each draft please send a brief (one or two
sentences is fine) status to the mailing list about their drafts? 
Also indicate if you want WG time to present, talk about issues,
etc. We are scheduled to meet during the Tuesday afternoon
session, from 17:20-18:20 (last hour, after oauth).

draft-ietf-acme-acme-12

draft-ietf-acme-caa-05 Ready to move to IESG

draft-ietf-acme-email-smime-02

draft-ietf-acme-email-tls-04

draft-ietf-acme-ip-02

draft-ietf-acme-star-03

draft-ietf-acme-tls-alpn-01


___
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


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] I-D Action: draft-ietf-acme-caa-05.txt

[Jacob Hoffman-Andrews]

Thanks for the update, Hugo! Let's Encrypt's Boulder has merged a change 
updating to match this behavior, which should go out to our staging 
environment on Tuesday.


https://github.com/letsencrypt/boulder/pull/3772

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Let's Encrypt ACME-CAA validation-methods support

[Jacob Hoffman-Andrews]

Apologies for the delay on publishing the latest draft. I'll work on 
getting that out today. Thanks for the reminder!


On 05/30/2018 12:17 PM, Corey Bonnell wrote:


Hello,

This development is exciting work in regard to allowing domain owners 
to limit which validation methods they want to allow to be used for 
their domains.


Unfortunately, the validation-methods extension is not compliant with 
RFC 6844 (the CAA RFC), as parameter tags cannot contain hyphens. 
 This was originally pointed out on this mailing list in January 
(https://www.ietf.org/mail-archive/web/acme/current/msg02506.html). I 
proposed a fix to this issue (as well as fixing an ambiguity in the 
ABNF grammar in regard to parameter delimiters) on the LAMPS WG 
mailing list a few months ago 
(https://www.ietf.org/mail-archive/web/spasm/current/msg01144.html), 
but this change has not yet been incorporated into a draft of RFC 
6844-bis.


Since RFC 6844 dictates that parameters have meaning specific to the 
issuer (from section 5.1: “The semantics of issuer-parameters are 
determined by the issuer alone”), I don’t believe that issuing 
certificates for domains whose CAA record sets contain non-conformant 
parameter syntax would constitute mis-issuance. However, it may 
present difficulties in regard to tooling/automation that expect all 
parameter tags to follow RFC 6844.


Thanks,

*Corey Bonnell*

Senior Software Engineer

*Trustwave***| SMART SECURITY ON DEMAND
www.trustwave.com 

*From: *Acme  on behalf of Daniel McCarney 


*Reply-To: *"c...@letsencrypt.org" 
*Date: *Wednesday, May 30, 2018 at 1:57 PM
*To: *Hugo Landau , IETF ACME 
*Subject: *[Acme] Let's Encrypt ACME-CAA validation-methods support

Hi folks,

I'm happy to share that Let's Encrypt has deployed support for Hugo 
Landau's ACME-CAA "validation-methods" CAA record extension in the 
staging environment[0]. Community feedback/review would be most 
appreciated.


You can find more information in the associated API announcement[1].

Thanks,


- Daniel / cpu

[0] - https://letsencrypt.org/docs/staging-environment/ 



[1] - 
https://community.letsencrypt.org/t/acme-caa-validation-methods-support/63125 





___
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] I-D Action: draft-ietf-acme-ip-02.txt

[Jacob Hoffman-Andrews]

On 05/21/2018 11:55 AM, Roland Shoemaker wrote:

Ah, yup, good catch. I totally spaced we’d pulled that out.

Likely we’ll want to reference TLS-ALPN here but it kind of ends up being a 
chicken and egg scenario. If draft-ietf-acme-tls-alpn gets standardized first 
we’ll want to mention that in this document updating it’s method to accept IPs, 
if we standardize draft-ietf-acme-ip first we’ll want to mention in 
draft-ietf-acme-tls-alpn that it can work with IP identifiers.

It seems like there is more forward momentum on draft-ietf-acme-tls-alpn so I 
suspect we should just wait for that to be done to get this out the door… 
thoughts?
Let's continue to work on the IP draft with the assumption that 
something named tls-alpn will land, with the goal to land them both 
around the same time. In the unlikely event the IP draft is ready to 
finalize before tls-alpn is, we can choose then to either hold it up, or 
remove the reference to tls-alpn. I'd like to avoid coupling things as 
much as possible since that's a surefire way to slow progress.


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Question about listing authorization objects

[Jacob Hoffman-Andrews]

On 04/11/2018 03:07 PM, Zhang, Ning wrote:
>
> Excuse me if it has been discussed before.
>
>  
>
> It looks like that there is no URL defined to fetch the list of
> existing authorization objects associated with an account, especially
> for ACME servers supporting pre-authorization
>
>  
>
> Does this mean that it is up to the specific ACME server
> implementation to provide such a URL for authorization objects, in a
> similar way for the order objects?
>
The assumption is that by enumerating the order objects, you can find
all the authorization objects, though it's true that doesn't hold for
servers supporting pre-authorization. For now I'd be waiting and seeing
if (a) any servers implement pre-authorization, and (b) if they decide
to implement authorization object listing as a server-specific
extension. If so, we could standardize that in a follow-on RFC.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Comments on ACME draft

[Jacob Hoffman-Andrews]

I agree, these seem worth merging.


On 04/11/2018 01:56 PM, Richard Barnes wrote:
> Here's a quick PR implementing Tim's proposed changes.
>
> https://github.com/ietf-wg-acme/acme/pull/420
>
> Personally, these seem fine to me.  I would be in favor of merging the PR.
>
>
> On Wed, Apr 11, 2018 at 4:41 PM, Tim Hollebeek
> mailto:tim.holleb...@digicert.com>> wrote:
>
>
> I think the draft is in very good shape.
>
> Unfortunately I didn't have as much time to go through it as I
> would have
> liked, but I did find two things that are probably worth fixing:
>
> 1. "ACME clients SHOULD send a User-Agent header"
>
> I think there's no value in omitting it, so it should be changed
> to a MUST.
>
> 2. Using the same key pair for both the account key pair and the
> certificate
> key pair is a really bad idea.
>
> This should either be mentioned in the Operational Considerations,
> or banned
> outright.
>
> -Tim
>
>
> ___
> 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

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Challenge retry ambiguities

[Jacob Hoffman-Andrews]

On 03/15/2018 10:03 AM, Hugo Landau wrote:
> It suggests that a challenge should be retried automatically by the server, 
> and
> that the challenge should remain in the "processing" state for this time. It
> also states that the "invalid" state should be used after the server has given
> up. It also states that the client should be explicitly able to request
> retries.

I think the idea here is that there's a window of time during which the
challenge is in "processing" state. During that time, the server can
choose to retry on some interval, and also the client can ask for early
retries (so a client who is trying different things. So long as the
server is willing to keep trying, it wouldn't transition into "invalid"
state.

This is discussed a bit more in the recently added "Status Changes"
section:
https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html#rfc.section.7.1.6.

"Note that within the “processing” state, the server may attempt to
validate the challenge multiple times (see Section 8.2). Likewise,
client requests for retries do not cause a state change."

> This doesn't make sense. The implication is that "invalid" is a final state,
> and the challenge cannot move back to "processing" after becoming "invalid". 
> If
> a server doesn't wish to make automatic retries, it has "given up" and the
> specification thus dictates that the challenge move to "invalid", but this
> makes it impossible to retry the challenge. This precludes an implementation
> where the server e.g. only makes retries at the request of the client. For a
> server which does make retries automatically, it also means the client's
> ability to request retries ends when the server ceases to make retries
> automatically, even though this is largely an internal detail of the server 
> and
> not really an exposed aspect of the API.

I understand this reading, although that's not the intent. A server that
wanted to offer retries only upon client initiation would simply leave
the challenge in "processing" state until the challenge's authorization
expired. Essentially, the server would never "give up" until expiration
time.

> The specification doesn't say anything
> about whether a challenge becoming permanently "invalid" precludes attempting
> another challenge in the same authorization.

I think the intent of the spec is for this to be "server's choice."
Let's Encrypt treats failing any challenge as failing the whole
authorization, but in theory a different CA could do it differently.

> Retries were added in the first place because the aggregation of multiple
> authorizations into orders means quite a lot of progress in the issuance
> process may be lost by a single challenge failure.


I have to admit, even though I asked for retries to be added because I
was worried about this scenario, we have not actually implemented
retries at Let's Encrypt. Partly we reduced the resource consumption of
orders by moving CSR submission to the last step, and partly we realized
we can mitigate this problem by reusing authorizations (both pending and
valid) for subsequent orders.

Basically, I see that there's some possible refinement here, but I don't
think it will be resolved without someone implementing retries, and I
don't think we should delay finalization of the RFC to try and nail it
down. There will definitely be some corners that will be worked out as
deployment widens, and if necessary we can address those with errata and
a follow-on spec.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Certificate chains including roots

[Jacob Hoffman-Andrews]

On 03/14/2018 02:52 PM, Martin Thomson wrote:
> On Wed, Mar 14, 2018 at 9:23 PM, Jacob Hoffman-Andrews  wrote:
>> On 03/12/2018 05:25 AM, Hugo Landau wrote:
>>>   3. Clarify the specification to state that the root certificate must
>>>  not appear in the chain, and that roots must be retrieved using the
>>>  AIA URL inside the final certificate in the chain if it is needed.
>>>  This minimises the chance of clients for non-DANE applications
>>>  messing up and provides a viable method for discovery of the root
>>>  CA for applications which need it.
>> This seems fine to me.
> MUST NOT is too strong.  Advise against it in the same way that TLS
> does.  Even point to TLS.
Good point, I'd missed that the above could be normative language. I
agree we shouldn't be more restrictive than TLS on this issue.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Certificate chains including roots

[Jacob Hoffman-Andrews]

On 03/12/2018 05:25 AM, Hugo Landau wrote:
>   3. Clarify the specification to state that the root certificate must
>  not appear in the chain, and that roots must be retrieved using the
>  AIA URL inside the final certificate in the chain if it is needed.
>  This minimises the chance of clients for non-DANE applications
>  messing up and provides a viable method for discovery of the root
>  CA for applications which need it.
This seems fine to me.

To push a little more on why it's required, though: In DANE, you might
indicate a trust anchor in your records. Presumably that trust anchor
could be either a self-signed root, or an intermediate issuer
certificate, right?

The reason to prefer putting a root in DNS rather than an issuer is
generally that the root won't change as often, right? But if you're
automating DANE updates based on the returned certificate chain, why not
just use the issuer, and update the trust anchor record every time a new
certificate is issued?

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] I-D Action: draft-ietf-acme-tls-alpn-00.txt

[Jacob Hoffman-Andrews]

On 03/05/2018 04:37 PM, Tim Hollebeek wrote:
> I think we may come to regret using that trick so much.  Such schemes
> are only one software bug away from having rather profound effects
> on trust decisions and the entire ecosystem.
This is a good point, but an important mitigating factor is that these
are self-signed certificates, as compared to CT's precertificates, which
are signed by a trusted issuer but poisoned. And they are only presented
when the acme/1 ALPN is negotiated. So you'd need three software bugs,
each of which would be a game-over bug on its own:

 - ignoring a critical extension
 - trusting a self-signed certificate
 - sending acme/1 ALPN for non-validation traffic

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Example requests

[Jacob Hoffman-Andrews]

On 03/04/2018 02:17 PM, Richard Barnes wrote:

> Hey Joern,
>
> This is a probably a good thing to have.  I think that rather than
> putting these in the main spec, it might be better to have them in a
> second draft.  This is a pretty common pattern.  For example, for TLS
> 1.3, there's a "test vectors" document separate from the main spec
> [0].  There are a few documents with example "call flows" for SIP
> [1][2].  ACME is probably somewhere in the middle of those two cases.
I agree; the test vectors are a good idea, and should be part of another
document.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Specify which JWS serialization is used

[Jacob Hoffman-Andrews]

> If you have suggestions here, a PR would be welcome.  TBH, this issue
> kind of makes me want to reverse course and say "all flattened JSON",
> but I get the sense that other folks disagree?
I'd be very much in favor of "all flattened JSON." When we started ACME,
I think there was some concern that libraries might support only Compact
Serialization (https://tools.ietf.org/html/rfc7515#section-7.1). But
experience has shown that Flattened JSON Serialization
(https://tools.ietf.org/html/rfc7515#section-7.2.2) is pretty well
supported across languages.

FWIW, Let's Encrypt's ACMEv2 endpoint only supports Flattened JSON
Serialization.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Assisted DNS, freshness tokens, and BR validation methods

[Jacob Hoffman-Andrews]

[Starting a new thread for this particular fork of the conversation]

Thanks for the input, Tim! As a member of the CA/Browser Forum
Validation Working Group, and a big contributor to the BR validation
methods, your perspective on this is particularly helpful.

On 01/23/2018 08:37 AM, Tim Hollebeek wrote:
> Your proposed method defeats one of the goals of the BR domain
> control validation requirements, which is to demonstrate control
> at time of validation, not just as some previous time in the past.

For the moment, let's continue to assume that the CA fully resolves the
TXT record during validation.

I think continuing to present a delegation of the authorization label to
an authorized party (in this case the CA) does constitute demonstration
of continued control.

> That's why the existing, approved validation methods require
> random numbers to guarantee the validation is fresh and not
> based on some previous validation.

I'm sure the intent of "freshness tokens" in the BRs was discussed
extensively in the validation WG, but I don't think it made it to the
final document. If you happen to recall any thread titles, would you be
willing to link to the previous discussion?

I'm specifically interested in why you would consider this form of
automation to have a separate risk profile from HTTP-style automation.
For instance, if someone leaves software like Certbot running on a
server, with instructions to continue to request and respond to
validation from a given CA, why is that safer than leaving a particular
CNAME record in DNS?

> If control at some time in the past is sufficient, you can
> just re-use the previous validation, which is allowed in some
> circumstances(see the BRs).

This is fundamentally different from validation reuse. With validation
reuse, a CA might say "I validated that a year ago; I'll assume it's
still good." The goal of automated validation methods is to allow the CA
to actually re-check the validation data at intervals that would be
impractical with manual intervention. So for instance, under
assisted-dns-01, a CA would actually be going out to the network and
fetching DNS records with each validation.

>> Oh, and the method very similar to the propose one (static
>> CNAME as persistent authentication) is being used in the wild.
>> And due to fundamential nature of DNS, even static zone can
>> result variable results for names under the zone.
> By who?  I don't think it's possible for such a method to be
> compliant with any of the current BR methods.  If it is, we'll
> fix it.

Are you saying that the proposed assisted-dns-01 method is also
not compliant with 3.2.2.4.7 DNS Change? Why not? If you think
assisted-dns-01 is compliant, but should not be, what is your proposed fix?

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Assisted-DNS challenge type

[Jacob Hoffman-Andrews]

Inspired by a thread on Let's Encrypt's community forum
(https://community.letsencrypt.org/t/suggestion-lets-encrypt-operated-txt-only-dns-hosting-for-dns-challenges/50399/1),
I'd like to propose a new challenge type, "assisted-dns-01".

The existing DNS challenge is good for a number of reasons, but it has a
couple of key problems:
 - It's hard to automate, and many DNS providers may offer no automation
at all.
 - Automating it may mean putting DNS credentials on a web frontend,
which may increase risk.

To fix that, the CA could assist the user by providing narrowly-scoped
DNS hosting: It would serve only TXT records used in validating DNS
challenges. The CA instruct subscribers to delegate the _acme-challenge
subdomain to a subdomain of the CA's hosted DNS domain. For instance, if
a subscriber has account number 1234, the CA would say: Please deploy a
CNAME record like so:

_acme-challenge.example.com. CNAME 1234.challenges.ca.example.net.

The assisted-dns-01 challenge would then be validated like dns-01,
except: As the first step in validation, the CA would deploy the
expected TXT value at 1234.challenges.ca.example.net. Then the CA would
continue to look up "TXT _acme-challenge.example.com." In a way,
fetching final TXT record would be a formality: the CA could in theory
stop once it saw the CNAME pointed at the right location, though most
likely abiding by the terms of the BRs would require following the
formal lookup steps.

This challenge has the big advantage that subscribers only need to do a
one-time CNAME setup, and renewals can be reliably automated without
requiring that renewing systems have permission to update DNS. In
effect, the CNAME record would act like a long-term delegation
permitting the CA to issue continuously for the base domain.

The challenge object would contain a field telling the client what the
CNAME target should be. Based on this, clients can check the existing
DNS and prompt a user to add the CNAME if needed, or continue
automatically if it's already present.

Example assisted-dns-01 challenge:

{
  "type": "assisted-dns-01",
  "token": "abc123",
  "cnameTarget": "1234.challenges.ca.example.net.",
}

If people think this challenge type has merit, my proposal is that it be
part of an extension document, not part of the core ACME doc.

Credit to Joona Hoikkala, Matt Nordhoff, and forum user @_az for helping
to develop this concept.   

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Hyphens in parameter names of ACME CAA extensions

[Jacob Hoffman-Andrews]

I don't think that's been discussed before. I think it's reasonable to
adjust "account-uri" to "accounturi" and "validation-methods" to
"validationmethods" to stick with RFC6844's definitions.

On 01/18/2018 06:56 AM, Ivan Vyshnevskyi wrote:
> Hi,
>
> According to the grammar for value of the CAA issue property, that is defined 
> in
> the section 5.2 of RFC6844[1], the parameter name (there called “tag”) 
> consists
> of one or more alphanumeric characters. The most current version of
> the draft-ietf-acme-caa[2] introduces two parameter names with hyphens
> in them: “account-uri” and “validation-methods”.
>
> Was this discrepancy discussed before? Is there a plan to resolve it?
>
> Regards,
> Ivan
>
> [1]: https://tools.ietf.org/html/rfc6844#section-5.2
> [2]: https://tools.ietf.org/html/draft-ietf-acme-caa-03
>
> ___
> 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] Clarify account creation

[Jacob Hoffman-Andrews]

On 01/07/2018 03:37 PM, Jörn Heissler wrote:
> * 
> https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.html#rfc.section.7.3
>   says that when an account was created, "The server returns this
>   account object".
> 
>   Should this be the same response that a subsequent POST (empty update,
>   §7.3.3) to the account URL should yield?

Yes.

> 
>   - The example skips the "orders" key which is required (§7.1.2).

Whoops, that should be there (though dereferencing the orders URL will
get an empty list).

>   - In the example there's a "Link" header. What's that for?

It's a holdover from when almost every response had a link to the
directory. It should be removed.

> * If the account already exists, what should be returned in the body?
>   Nothing? Or the full account object?

This is answered under 7.3.1. Finding an Account URL Given a Key, but
the name probably doesn't make that clear.

> * If the account already exists and "onlyReturnExisting" was specified,
>   what should be returned in the body?

Empty body, I think. This should be added to 7.3.1.

> * What happens when the account already exists and I send e.g. different
>   "contact" addresses than there are in the existing account? Will my
>   account be updated?

Yep.

> * Should it be allowed to send "onlyReturnExisting" along with other
>   information, or should those be mutually exclusive?

I think these should be mutually exclusive. Would you send a PR with the
changes discussed above?

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Undoing challenge fulfilling actions

[Jacob Hoffman-Andrews]

> On Sun, Jan 07, 2018 at 18:40:51 +0100, Sophie Herold wrote:
>> I wonder if this paragraph has some special background:
>>
>>   If the client’s response is invalid for any reason or does not
>>   provide the server with appropriate information to validate the
>>   challenge, then the server MUST return an HTTP error. On receiving
>>   such an error, the client SHOULD undo any actions that have been
>>   taken to fulfill the challenge, e.g., removing files that have been
>>   provisioned to a web server.
>>
>> Is there a reason that undoing challenge fulfilling actions, isn't
>> mentioned for authorizations becoming final (valid or invalid) at all?
>> Why is this "rare" case of failing responses the only one covered?

Good question. I'm not aware of any special background here. Certainly
clients should client up after themselves regardless of success or failure.

On 01/07/2018 10:53 AM, Jörn Heissler wrote:
> 
> Related to this: What is the meaning of the "revoked" status of an
> authorization?
The server may choose to revoke certain authorizations, for instance if
they were validated during a registrar compromise.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Challenge "errors" -> "error"

[Jacob Hoffman-Andrews]

In the course of testing Let's Encrypt's ACME v2 endpoint, we realized
that the latest draft specifies "errors" as a plural array on challenges
(vs singular "error" for earlier drafts implemented by Boulder and
others). However, the ACME spec now also has subproblems as a way to
express plural errors (mainly on new-order and finalize).

This means we have two different ways to express multiple errors: One
for API requests, and one for validation responses. I propose to
simplify the spec by using subproblems consistently in both places:
https://github.com/ietf-wg-acme/acme/pull/388

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Challenge objects are provoking implementation mistakes

[Jacob Hoffman-Andrews]

On 12/19/2017 03:10 AM, Sophie Herold wrote:
> If the client follows the schema
> 
> 1. fulfill challenge
> 2. POST challenge URL
> 
> it is unlikely that the keyAuthorization returned by the server would be
> used to fulfill the challenge (again).
> 
> However, it should be possible to obtain a working ACME client by
> POSTing to the challenge URL first and using the keyAuthorization
> returned by the server (and possibly changed by the server) to fulfill
> the challenge afterwards. This should work since the servers challenge
> checks (DNS, HTTP, ...) are not instantaneous and even retried. In this
> case the MitM protection is bypassed by incautious client implementation.

This is a good point. The other potential issue is reliability: a client
the depends on the returned keyAuthorization rather than the one it
provided might appear to work for a while, then stop working if the
server started validating challenges more quickly.

I would support a change so that the server does not echo the
keyAuthorization. This brings up another question: Why have the client
include the keyAuthorization in the challenge POST at all? Both sides
can calculate it from scratch, the POST is essentially just "I'm ready
for validation now!" I think we originally included it because we
anticipated had other challenges where the client would be expected to
provide some secret token in the challenge response, or some proof of
control of a key, so including some payload (keyAuthorization) for the
other challenge types seemed stylistically consistent with that.
However, I don't think it's really necessary.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Discussion of draft-ietf-acme-ip

[Jacob Hoffman-Andrews]

On 12/20/2017 01:50 PM, Richard Barnes wrote:
> Do you mean draft-ietf-acme-ip?  It's already adopted; that's what the
> "draft-ietf" signifies.

Whoops, I missed that. Thanks!

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Discussion of draft-ietf-acme-ip

[Jacob Hoffman-Andrews]

On 11/16/2017 02:28 PM, Roland Bracewell Shoemaker wrote:
> The point of the draft is to provide a method for validating the control
> of IP addresses in the same way that the ACME draft does for DNS names.
> This allows ACME implementing CAs to be on an equal footing with
> existing implementations. The draft does three major things
> 
> * Adds a IP identifier type
> * Provides guidance on using http-01 and tls-sni-02 challenges for IP
> validation
> * Adds a new challenge, reverse-dns-01, which conforms with CABF B/R
> Section 3.2.2.5.
> 
> The only major objection that was previously voiced revolved around the
> lack of a policy mechanism for allowing a IP/network owner to block
> issuance and that there should be some kind of default denial required.
> It is my opinion that this draft is the wrong place for CA policy to be
> dictated and the right place to fix this problem would be in a document
> implementing an lookup mechanism for CAA records for IP addresses (see
> draft-shoemaker-caa-ip).
> 
> Any major thoughts/objections? If there are no significant hurdles I'd
> like to move towards getting this document finalized.

Any further thoughts about draft-shoemaker-caa-ip? I'd love to get it
adopted as a WG document.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [ACME][QUESTION] JWS Signature Verification Using JWK

[Jacob Hoffman-Andrews]

I think the answers to both of your questions will be found in the JWK
and JWS RFCs:

https://tools.ietf.org/html/rfc7517
https://tools.ietf.org/html/rfc7515

If you're looking for additional examples, you can look at the Boulder
source code: https://github.com/letsencrypt/boulder/, or a variety of
JOSE / JWS libraries available in the wild.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] new-authz, new-order and examples

[Jacob Hoffman-Andrews]

On 12/05/2017 03:07 PM, Sophie Herold wrote:
> Having mentioned new-authz: The definition of new-authz is now a subset
> of new-order. Is there any reason to keep the new-authz resource at all?
> Would there be any difference in using new new-order with the exact same
> query without finalizing it?

Yeah, I agree that this is a happy side-effect of making order
finalization an explicit step: there is now even less need for
preauthorization (i.e. new-authz). I strongly favor removing it. Eric, I
think you were the strongest voice in favor of adding preauthorization
to the spec when we moved to the new-order flow. Do you still feel it's
necessary? For context, you can accomplish the same thing by posting a
new-order for a single identifier, but not finalizing the order.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Camel vs. kebab-case

[Jacob Hoffman-Andrews]

Thanks for pointing this out!

On 12/01/2017 04:06 AM, Sophie Herold wrote:
> camelCase
> 
> - newKey
> - keyAuthorization
> - notBefore
> - notAfter
> 
> kebab-case
> 
> - (all directory fields)
> - terms-of-service-agreed
> - only-return-existing
> - external-account-binding

You forgot to include the field names in the directory object, which are
currently all kebab case. I think changing those to camelCase would make
it dramatically harder for clients to share code between their current
implementation and their v2 implementation. So I'm definitely opposed to
switching to camelCase.

We could in theory switch newKey and keyAuthorization to kebabs, if
that's an exhaustive list (nothing currently uses notBefore and
notAfter). However, I just finished changing one client so it can
support either the old "uri" field in challenges, or the new "url"
field, and it was a surprisingly large hassle. I'd rather not impose the
additional hassle of dual-classing more field names.

Keep in mind that while Let's Encrypt / Boulder is visible, we've heard
from a handful of other CAs who have implemented "Certbot compatible"
ACME endpoints privately. We should expect that there will be a
transition period where most clients will want to support either the
older spec version implemented by Certbot / Boulder, OR the final RFC
version.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Question about the new finalizeURL approach, and the order object format after finalizeURL

[Jacob Hoffman-Andrews]

On 11/30/2017 02:53 PM, Tim Hollebeek wrote:
> My recollection from various CA/Browser discussions is that CAs are *not*
> actually required to keep around CSRs.  Am I wrong?
I may be misremembering. I thought they were required to log proof of
the subscriber's possession of the private key, but you're right that
3.2.1 is empty. So, even more reason to not make this required!

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Question about the new finalizeURL approach, and the order object format after finalizeURL

[Jacob Hoffman-Andrews]

On 11/30/2017 02:34 PM, Richard Barnes wrote:
> As Jacob points out, CAs are already required to keep around CSRs in
> audit logs.

You missed an important nuance: CAs are not required to keep around CSRs
in an online database for live querying on the web. It is much more
expensive to store a CSR in a performant database than a rarely-accessed
log.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Question about the new finalizeURL approach, and the order object format after finalizeURL

[Jacob Hoffman-Andrews]

On 11/30/2017 12:58 PM, Logan Widick wrote:
> In the new finalizeURL approach to orders, do order objects need to
> contain a CSR after a user attempted to finalize the order, or after
> the order is finalized? Would the CA have to store the CSR after it's
> posted, or after the certificate is issued?
Good question. Previously, we expected that the CA had to store the CSR
because it would need the public key in order to issue. With
finalizeURL, we can get rid of that requirement. CAs are required to
record CSRs in their audit logs, but there is no formal requirement to
keep them in an online database. So my preference would be to remove the
"csr" field from order objects, since it doesn't serve any purpose.

Other thoughts?

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Removing OOB Challenge Type

[Jacob Hoffman-Andrews]

I agree with this change. It's a good plan to not try and pre-specify
things like OOB that aren't on anyone's roadmap, because that leaves the
space open for a better specification once someone wants to implement it.

On 11/30/2017 09:39 AM, Clint Wilson wrote:
>
> I agree with the reasoning and decision to remove this.
> While I think it's possible for this challenge type to become useful
> in the future, I don't have any justification for keeping it in in the
> meantime. As Daniel notes, it's straightforward to add it back if needed.
>
>
> On Thu, Nov 30, 2017, 10:25 AM Daniel McCarney  > wrote:
>
> > Daniel, please do not merge this until we determine WG consensus
>
> Of course :-) I don't have any merge privileges!
>
> On Thu, Nov 30, 2017 at 11:42 AM, Salz, Rich  > wrote:
>
> Does anyone disagree with Daniel’s reasoning?  If so, please
> speak up before next Friday.
>
>  
>
> Daniel, please do not merge this until we determine WG consensus.
>
>
> ___
> 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

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Landing PR#342 (proactive issuance with identifier-first)

[Jacob Hoffman-Andrews]

Hi all,

Daniel McCarney's been working on PR#342, which changes the new-order
flow to take a list of identifiers instead of a CSR, and to be finalized
with a CSR: https://github.com/ietf-wg-acme/acme/pull/342. We've had
some back-and-forth on the list about this, versus CSR-first, versus
CSR-first-and-last. There was some further discussion at IETF 100
(minutes:
https://github.com/thomas-fossati/acme-minutes/blob/master/ietf-100.md),
and we hummed to accept PR 342 over the alternatives.

If there's anyone here who couldn't make it to the meeting and would
like to raise strenuous objections, please speak up now, otherwise we'll
incorporate that change.

Thanks,
Jacob

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Returning multiple errors

[Jacob Hoffman-Andrews]

On 11/21/2017 04:06 PM, Martin Thomson wrote:
> I ask because your example highlighted two types of problems.  That
> they could be aggregated doesn't seem an necessary or innate property.
> 
> The difficulty with the sort of aggregation design you propose is that
> you need to aggregate and I don't know what the logic would be in the
> general case.  On the other hand, additional problems are easy to
> accumulate and emit.  They are also easy to consume, either by just
> doing the dumb thing and handling only the first, or by working
> through a list.
> 
> The alternative is to provide a specific type (e.g.,
> "urn:ietf:params:acme:error:multiple"), that says "there were multiple
> problems", and list the real problems in the body.  The text for the
> specific type could be more helpful - just as in your example - or
> not.

The current text allows the CA to choose whatever error type at the top
level it wants, including its own type. I think that flexibility is
fine. Is your main problem that this doesn't specify a top-level
"multiple" error type?

> list the real problems in the body

This is insufficient, because the goal is to allow clients to
programmatically remove identifiers from a request. So we need some
specific field in JSON.

We can't have a raw list, because identifiers are objects, not strings.
So we have a list of objects containing identifiers. It happens to be
handy to attach a type and a value to each.

>  additional problems are easy to accumulate and emit.

As an implementer, I find sub-problems easy and more natural than a list
of problems that gets appended to.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Returning multiple errors

[Jacob Hoffman-Andrews]

On 11/21/2017 11:48 AM, Niklas Keller wrote:
> How about "causes"?

I think this also implies more meaning than there really is. It also has
the unfortunate property of being both a plural noun and a transitive
verb, which could be confusing.

Is there a problem with sub-problems?

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Returning multiple errors

[Jacob Hoffman-Andrews]

On 11/20/2017 08:24 PM, Martin Thomson wrote:
> Is this better cast as "sub" problems, or just "additional" problems?

I think "additional" is the wrong semantic, because it implies that the
first error is hoisted to the top position, so a naive client would only
show the first error. Instead, there's a top-level generic error ("some
identifiers were rejected"), and then there are potentially multiple
errors that are part of it (_example.com, example.net).

> On Tue, Nov 21, 2017 at 10:19 AM, Jacob Hoffman-Andrews  wrote:
>> I've submitted a PR adding this to the spec:
>>
>> https://github.com/ietf-wg-acme/acme/pull/354
>>
>> commit a6cc0aedf96067e8b3aaf37662785fcf8b38dd18
>> Author: Jacob Hoffman-Andrews 
>> Date:   Mon Nov 20 15:14:29 2017 -0800
>>
>> Define sub-problems.
>>
>> diff --git a/draft-ietf-acme-acme.md b/draft-ietf-acme-acme.md
>> index a2c11ab..a9e3535 100644
>> --- a/draft-ietf-acme-acme.md
>> +++ b/draft-ietf-acme-acme.md
>> @@ -521,6 +521,53 @@ set to a URI other than those defined above.
>> Servers MUST NOT use the ACME URN
>>  namespace for errors other than the standard types.  Clients SHOULD
>> display the
>>  "detail" field of all errors.
>>
>> +### Sub-problems
>> +
>> +Sometimes a CA may need to return multiple errors to a single
>> +request. Additionally, the CA may need to attribute errors to specific
>> +identifiers.  For instance, a new-order request may contain multiple
>> +identifiers for which the CA cannot issue. In this situation, an ACME
>> +problem document MAY contain the "sub-problems" field, contains a JSON
>> +array of problem documents, each of which MAY contain an "identifier"
>> +field. If present, the "identifier" field MUST contain an ACME identifier
>> +({{iana-identifier}}). The "identifier" field MUST NOT be present at
>> +the top level in ACME problem documents. It can only be present in
>> sub-problems.
>> +Sub-problems need not all have the same type, and do not need to match
>> the top level type.
>> +
>> +ACME clients may choose to use the "identifier" field as a hint that
>> +an operation would succeed if certain identifiers were omitted. For
>> +instance, if an order contains ten DNS identifiers, and the new-order
>> +request returns a problem document with two sub-problems, referencing two
>> +of those identifiers, the ACME client may choose to submit another order
>> +containing only the eight identifiers not listed in the problem document.
>> +
>> +~
>> +HTTP/1.1 403 Forbidden
>> +Content-Type: application/problem+json
>> +
>> +{
>> +"type": "urn:ietf:params:acme:error:malformed",
>> +"detail": "Some of the identifiers requested were rejected",
>> +"sub-problems": [
>> +{
>> +"type": "urn:ietf:params:acme:error:malformed",
>> +"value": "Invalid underscore in DNS name \"_example.com\"",
>> +"identifier": {
>> +"type": "dns",
>> +"value": "_example.com"
>> +}
>> +},
>> +{
>> +"type": "urn:ietf:params:acme:error:rejectedIdentifier",
>> +"value": "This CA will not issue for \"example.net\"",
>> +"identifier": {
>> +"type": "dns",
>> +"value": "example.net"
>> +}
>> +}
>> +]
>> +}
>> +~
>>
>>  # Certificate Management
>>
>> ___
>> 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
> 

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Returning multiple errors

[Jacob Hoffman-Andrews]

I've submitted a PR adding this to the spec:

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

commit a6cc0aedf96067e8b3aaf37662785fcf8b38dd18
Author: Jacob Hoffman-Andrews 
Date:   Mon Nov 20 15:14:29 2017 -0800

Define sub-problems.

diff --git a/draft-ietf-acme-acme.md b/draft-ietf-acme-acme.md
index a2c11ab..a9e3535 100644
--- a/draft-ietf-acme-acme.md
+++ b/draft-ietf-acme-acme.md
@@ -521,6 +521,53 @@ set to a URI other than those defined above.
Servers MUST NOT use the ACME URN
 namespace for errors other than the standard types.  Clients SHOULD
display the
 "detail" field of all errors.

+### Sub-problems
+
+Sometimes a CA may need to return multiple errors to a single
+request. Additionally, the CA may need to attribute errors to specific
+identifiers.  For instance, a new-order request may contain multiple
+identifiers for which the CA cannot issue. In this situation, an ACME
+problem document MAY contain the "sub-problems" field, contains a JSON
+array of problem documents, each of which MAY contain an "identifier"
+field. If present, the "identifier" field MUST contain an ACME identifier
+({{iana-identifier}}). The "identifier" field MUST NOT be present at
+the top level in ACME problem documents. It can only be present in
sub-problems.
+Sub-problems need not all have the same type, and do not need to match
the top level type.
+
+ACME clients may choose to use the "identifier" field as a hint that
+an operation would succeed if certain identifiers were omitted. For
+instance, if an order contains ten DNS identifiers, and the new-order
+request returns a problem document with two sub-problems, referencing two
+of those identifiers, the ACME client may choose to submit another order
+containing only the eight identifiers not listed in the problem document.
+
+~
+HTTP/1.1 403 Forbidden
+Content-Type: application/problem+json
+
+{
+"type": "urn:ietf:params:acme:error:malformed",
+"detail": "Some of the identifiers requested were rejected",
+"sub-problems": [
+{
+"type": "urn:ietf:params:acme:error:malformed",
+"value": "Invalid underscore in DNS name \"_example.com\"",
+"identifier": {
+"type": "dns",
+"value": "_example.com"
+}
+},
+{
+"type": "urn:ietf:params:acme:error:rejectedIdentifier",
+"value": "This CA will not issue for \"example.net\"",
+"identifier": {
+"type": "dns",
+"value": "example.net"
+}
+}
+]
+}
+~

 # Certificate Management

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Returning multiple errors

[Jacob Hoffman-Andrews]

On 11/16/2017 12:45 AM, Martin Thomson wrote:
> I don't know what a random JSON parser would do with your stacked error codes.
I don't understand. What I'm proposing is an array of JSON objects under
the sub-problems field, which should be supported by any JSON parser.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Returning multiple errors

[Jacob Hoffman-Andrews]

On 11/15/2017 07:07 PM, Richard Barnes wrote:
> Following Daniel's lead on looking for implementation: Is this
> something LE would be implementing?
Yep, we would definitely implement this. I'll send a PR.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Returning multiple errors

[Jacob Hoffman-Andrews]

In previous versions of ACME, there was sometimes a need to return
multiple errors, broken out by domain name. For instance, when issuing a
certificate by making a new-cert request, the CA has to check CAA, which
may fail for multiple domains. Ideally, the client should not have to
guess which identifiers (domains) failed, or engage in string parsing.
So far, this hasn't been terrible because *most* errors occur during
new-authz or during validation, and so are implicitly associated with a
specific identifier.

However, in the latest spec, this problem is a lot worse. Since all
issuance starts with new-order, which can request multiple identifiers,
all attempts to issue for multiple identifiers will potentially fail for
one or more of those identifiers.

Fortunately, JSON problem details provide enough flexibility for this,
with problem-specific extensions
(https://tools.ietf.org/html/rfc7807#page-4). I propose we define a
field, "sub-problems", on all ACME problem types. This field would
contain a list of JSON problem details, each of which may contain an
identifier. So for instance, you might receive this response from a
new-order request:

{
  "type": "urn:ietf:params:acme:error:malformed",
  "detail": "Some of the identifiers requested were rejected",
  "sub-problems": [ {
    "identifier": { "value": "_example.com", "type": "dns" },
    "type": "urn:ietf:params:acme:error:malformed",
    "value": "Invalid underscore in DNS name \"_example.com\"",
  }, {
    "identifier": { "value": "example.net", "type": "dns" },
    "type": "urn:ietf:params:acme:error:malformed",
    "value": "\"example.net\" is considered a high-risk domain",
  } ]
}

That way, clients that issue for large numbers of domains may choose to
automatically retry new-order with the problem identifiers removed.

Thoughts?

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

[Jacob Hoffman-Andrews]

On 11/09/2017 02:18 PM, Richard Barnes wrote:
> Since people don't seem happy about either of these alternatives
> (identifiers+CSR because of legacy issues; CSR+CSR because of
> fragility), here's one last attempt at a different approach:
> Draft PR: https://github.com/ietf-wg-acme/acme/pull/350

I think this approach complicates things unnecessarily.

My feeling of the list is that CSR+CSR has reasonable support as a
compromise solution. Hugo said it's "quite clumsy", and Eric said "seems
like a great opportunity for defects." I think we can reduce (but not
eliminate) the chance for defects by saying the initial CSR and final
CSR MUST be identical; then Let's Encrypt can store a hash (32 bytes)
rather than the full hash.

I still think identifiers+CSR is better, in particular because what I've
heard from a few CAs is that they generally ignore everything in the CSR
except the public key, and this approach mirrors that one more closely.
But ultimately finding an approach that works well enough is better than
stalling out trying to find a solution that everyone finds ideal.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [QUESTION] Implementation of 'new-order'

[Jacob Hoffman-Andrews]

On 10/25/2017 11:30 PM, Prasheel Soni wrote:
> I have set the primary key(id) of authorization and challenges to
> autoIncrement.
>
> I am facing the issue that for creating an order I need to first
> insert a record in order entity leaving the authorizations field data
> empty. Then further I need to create a record in authorization entity
> which will provide me with the id (primary key) and this id is
> required to create authorization's URL.
>
> so should I remove authorization id (PK) from autoincrement and
> generate it randomly?
The approach we are taking in Boulder is to treat the relationship
between orders and authorizations as a many-to-many relationship. Each
order can contain many authorizations, and each authorization can be
contained in many orders. We represent this as a relationship table that
has one column for order id, and one column for authorization id,
created after both the order and the authorizations.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Agenda topic - nonces

[Jacob Hoffman-Andrews]

I'd like to talk about making nonces optional for the server.
Specifically, we introduced nonces because the main implementer (Let's
Encrypt) was using a third party to terminate TLS. However, we've found
that in practice nonces make load balancing between clusters more
difficult, and we're considering removing the third-party TLS
termination in order to be able to remove nonces.

On 10/24/2017 09:42 AM, Salz, Rich wrote:
>
> I assume we’ll do a block of time on the core draft changes, and what
> we should do about re-enter WGLC or other options.
>
>  
>
> And then I think much of our time will be on STIR certificate stuff.
>
>  
>
> But I could be totally wrong.  Do you have things you want to talk
> about?  Either locally or remotely?  We have two hours Wednesday in
> second session.
>
>  
>
> Please post!
>
>
>
> ___
> 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] Allowable mailto contacts

[Jacob Hoffman-Andrews]

On 10/19/2017 10:59 AM, Logan Widick wrote:
> What portions of the "mailto" URI scheme (RFC 6068) must an ACME server
> be able to accept as contacts?

Good question. I think we'd like to specify the narrowest subset
possible, i.e. "mailto:us...@example.com";. What would that look like in
the language of RFC 6068?

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

[Jacob Hoffman-Andrews]

On 09/19/2017 01:34 PM, Logan Widick wrote:
> Would it be possible to extract the key and identifiers from the CSR,
> add the key  to the database if it doesn't already exist, find or
> create the authorizations for the identifiers, not store the CSR, and
> then assemble the certificate from the (valid) authorizations and key
> later?
Note that the size of the CSR for an RSA key is about half from the
signature, and half from the key. So extracting the key would only save
the size of the signature, about half. Also, this wouldn't solve the
more important problem, the overhead of reviewing all authzs on all
related orders on finalizing each authz, when an order may have a
hundred or more authzs.

I support Daniel's proposal.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Rolling keys and pending validations

[Jacob Hoffman-Andrews]

Any further thoughts on whether keyAuthorizations should be bound at
challenge creation time vs challenge submission time?

On 07/07/2017 03:09 PM, Jacob Hoffman-Andrews wrote:
> On 07/07/2017 12:35 PM, Richard Barnes wrote:
>> Whether clients will notice depends on how we change the syntax to
>> express the "binding".  You seem to be assuming that we'll keep the
>> syntax the same.  That would mean that the server would note the
>> keyAuthorization to be used with the challenge at creation time, in a
>> way that's invisible to the client
> Yep, I am assuming we'll keep the syntax the same. I don't see a
> reason to change.
>> So you'll break clients in the following scenario:
>>
>> 1. Server creates challenge bound to keyAuthorization_oldkey, sends
>> to client
>> 2. Client rolls keys
>> 3. Client computes keyAuthorization_newkey
>> 4. Client provisions the validation response with keyAuthorization_newkey
>> 5. Client sends keyAuthorization_newkey in a response to the
>> challenge, signed with newkey
> Yep, this was the scenario I was describing when I said:
>
> > It only makes a different when key rollover and long-term pending
> challenges are in
> play, which is pretty uncommon.
>
> Thanks for spelling it out in more detail, that makes it clearer.
> Essentially, I am saying that it is very rare for clients to hold onto
> pending authorizations while rolling keys. The most common clients
> (Cerbot, dehydrated, lego, etc) treat "get authorization; provision
> validation response; request validation" as a single automated steps,
> taking seconds or minutes. Those clients generally don't keep
> authorizations around between runs, and would be rotating keys between
> runs. So no problem.
>
> The only clients that would have to change are those that (a) cannot
> be fully automated, and therefore hold onto pending authorizations for
> days, and (b) rotate their keys regularly. As far as I'm aware, Akamai
> is the only client doing that, and they are the ones asking for "bind
> at creation time." I believe that most other clients would not notice
> a difference.
>
>
> ___
> 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] Stale DNS and high-risk issuance

[Jacob Hoffman-Andrews]

On 07/20/2017 12:18 AM, Kevin Borgolte wrote:
> we are currently conducting a measurement study about DNS staleness
> issues with a focus on IP address churning.
Excellent, I look forward to reading it!
> We encountered the issue that Let's Encrypt (and ACME in general) can
> be (ab)used to request and receive a valid certificate for a domain,
> as long as the attacker obtains access to the IP address to which the
> DNS record points.
This is true of HTTP and TLS based validation in general. I think the
place to address these issues is not in the ACME standard, but
potentially as a separate IETF draft with the goal of later adoption by
the CA/Browser Forum. For instance, if HTTP and TLS validation were
required to contact every IP address they found in DNS, that would
mitigate the stale DNS issue you raise. On the other hand, it would hurt
usability and reliability. And my intuition is that truly "high risk"
domains (those with lots of users, or important data) do not tend to
leave stale entries in DNS, because it would harm performance. Hopefully
your study will shed light on that assumption!
> We also propose, focusing on high-risk targets, a stricter issuance
> policy:
>
> If a valid certificate (e.g., issued by the same operator or a set of
> operators, checked via CT logs) exists for the requested domain, then
> the current challenge should be signed by the key. If the last
> certificate has expired, a grace period set by operators could apply
> (e.g., 1 month or 3 months). If the expiration date has passed a long
> time ago, or if no grace period is used by the operator, then a second
> channel should be used to verify the request (e.g., DNS CRP).
As Ilari mentioned, this was originally in the plan for ACME, but we
removed it because it was not fully baked. I think it's definitely
valuable to consider a successor as a separate document. Currently the
idea I have running around my head is to specify an HTTPS challenge
alongside the HTTP challenge, where the server expects to receive a
currently valid certificate that chains either to its own roots or to
some other roots it chooses to trust. This would be an optional extra
level of validation that CAs could apply to domains they consider high
risk. Upsides: Easy to implement for the both the CA and the Subscriber.
Downsides: If all certificate keys are lost, issuance would be blocked;
HTTPS validation still assumes that it's hard for third parties to
upload unauthorized files to certain paths on the web server.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] I-D Action: draft-ietf-acme-ip-00.txt

[Jacob Hoffman-Andrews]

On 07/19/2017 07:39 AM, Martin Thomson wrote:
> In this case, I disagree. With names, there is an expectation that
> certificates can be issued for them. This is not the default case for
> IP addresses

Why do you say that issuance is disallowed by default for most IP
addresses? The CA/Browser Forum Baseline Requirements have
authentication methods that can be used to authenticate and issue for
any IP address.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] I-D Action: draft-ietf-acme-ip-00.txt

[Jacob Hoffman-Andrews]

On 07/17/2017 10:48 PM, Martin Thomson wrote:
> The biggest concern I have is the text regarding certificate lifetime
> and the handling of the possibility that IP addresses are dynamically
> allocated.  This seems a little weak and it leaves a lot to the CA to
> manage.  Is there anything that can be done to gain a stronger
> assertion that the allocation is (more) persistent?  An affirmation
> from someone higher in the tree perhaps?
I think ultimately this is a policy question and outside the scope of
ACME (except for pointing out that it's worth thinking about). If we
want a mechanism for owners of IP space to express the policy they'd
like CAs to apply to that space, it should probably look something like CAA.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Fwd: I-D Action: draft-ietf-acme-acme-07.txt

[Jacob Hoffman-Andrews]

On 07/18/2017 10:13 AM, Rifaat Shekh-Yusef wrote:
> Hi Richard,
>
> Take a look at the following exchange with Jacob:
> https://www.ietf.org/mail-archive/web/acme/current/msg02085.html
> 
>
>
> I think the draft should be clear on the response when the server
> reuses existing pending authorization:
> 1. Is it still 201 Created? or should it be 200 OK?
FWIW, Let's Encrypt is planning to return the exact same code when
reusing an existing pending authorization as when creating a new one.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] I-D Action: draft-ietf-acme-ip-00.txt

[Jacob Hoffman-Andrews]

This looks good! Nice work.

On 07/16/2017 04:29 PM, Roland Bracewell Shoemaker wrote:
> There was some previous discussion about possibly using a slightly
> simpler DNS based verification method on the list last time I posted
> this as an individual submission. After reading through the CABF BRs for
> IP validation I'm pretty sure the proposed solution (checking for a TXT
> record in the reverse mapping zone) would not be considered BR compliant
> so I've stuck with the originally proposed challenge.
>
> On 07/16/2017 04:24 PM, internet-dra...@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Automated Certificate Management 
>> Environment of the IETF.
>>
>> Title   : ACME IP Identifier Validation Extension
>> Author  : Roland Bracewell Shoemaker
>>  Filename: draft-ietf-acme-ip-00.txt
>>  Pages   : 7
>>  Date: 2017-07-16
>>
>> Abstract:
>>This document specifies identifiers and challenges required to enable
>>the Automated Certificate Management Environment (ACME) to issue
>>certificates for IP addresses.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-acme-ip/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-acme-ip-00
>> https://datatracker.ietf.org/doc/html/draft-ietf-acme-ip-00
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> ___
>> 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
>

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Rolling keys and pending validations

[Jacob Hoffman-Andrews]

On 07/07/2017 12:35 PM, Richard Barnes wrote:
> Whether clients will notice depends on how we change the syntax to
> express the "binding".  You seem to be assuming that we'll keep the
> syntax the same.  That would mean that the server would note the
> keyAuthorization to be used with the challenge at creation time, in a
> way that's invisible to the client
Yep, I am assuming we'll keep the syntax the same. I don't see a reason
to change.
> So you'll break clients in the following scenario:
>
> 1. Server creates challenge bound to keyAuthorization_oldkey, sends to
> client
> 2. Client rolls keys
> 3. Client computes keyAuthorization_newkey
> 4. Client provisions the validation response with keyAuthorization_newkey
> 5. Client sends keyAuthorization_newkey in a response to the
> challenge, signed with newkey
Yep, this was the scenario I was describing when I said:

> It only makes a different when key rollover and long-term pending
challenges are in
play, which is pretty uncommon.

Thanks for spelling it out in more detail, that makes it clearer.
Essentially, I am saying that it is very rare for clients to hold onto
pending authorizations while rolling keys. The most common clients
(Cerbot, dehydrated, lego, etc) treat "get authorization; provision
validation response; request validation" as a single automated steps,
taking seconds or minutes. Those clients generally don't keep
authorizations around between runs, and would be rotating keys between
runs. So no problem.

The only clients that would have to change are those that (a) cannot be
fully automated, and therefore hold onto pending authorizations for
days, and (b) rotate their keys regularly. As far as I'm aware, Akamai
is the only client doing that, and they are the ones asking for "bind at
creation time." I believe that most other clients would not notice a
difference.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme