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

[Richard Barnes]

You seem to be trying to approach this point-by-point.  What Adam and I
have been saying is that randomizing everything, you don't have to do the
analysis case by case.  That's why that's the desired recommendation --
it's conservative.

If you want to do the analysis, go ahead.  The URL plan is 100% up to the
server operator.  But the recommendation in the spec should be the
conservative one.

--Richard

On Tue, Oct 9, 2018 at 7: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  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
>> 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)

[Diego R. Lopez]

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

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: diego.r.lo...@telefonica.com
Tel: +34 913 129 041
Mobile:  +34 682 051 091
--

On 09/10/2018, 16:46, "Acme on behalf of Richard Barnes" 
mailto:acme-boun...@ietf.org> on behalf of 
r...@ipv.sx> wrote:

So here's the compromise I would propose:

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.

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

In units of PRs, I think that means:
- Merge #459 (remove GET for certificates)
- Merge #460 (randomize URLs)
- Close #462 (meta flag for GET; obsoleted by #459)
- Close #457 (remove recommendation for capability URLs; obsoleted by #459)

Jacob, Daniel: How does that strike you?

--Richard

On Tue, Oct 9, 2018 at 10:32 AM Daniel McCarney 
mailto:c...@letsencrypt.org>> wrote:
I am also opposed to this change. I think it is a clunky solution and there 
hasn't been convincing justification of why the base ACME draft needs to carry 
this complexity instead of having STAR add the extensions it requires.

On Mon, Oct 8, 2018 at 3:27 PM Jacob Hoffman-Andrews 
mailto:j...@eff.org>> wrote:

>   
> 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
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please immediately reply to the sender that you have received this 
communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode 
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa 
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica 
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização 
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem 
por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
proceda a sua destruição
___
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)

[Richard Barnes]

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  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
> 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 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)

[Richard Barnes]

So here's the compromise I would propose:

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.

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

In units of PRs, I think that means:
- Merge #459 (remove GET for certificates)
- Merge #460 (randomize URLs)
- Close #462 (meta flag for GET; obsoleted by #459)
- Close #457 (remove recommendation for capability URLs; obsoleted by #459)

Jacob, Daniel: How does that strike you?

--Richard

On Tue, Oct 9, 2018 at 10:32 AM Daniel McCarney  wrote:

> I am also opposed to this change. I think it is a clunky solution and
> there hasn't been convincing justification of why the base ACME draft needs
> to carry this complexity instead of having STAR add the extensions it
> requires.
>
> On Mon, Oct 8, 2018 at 3:27 PM Jacob Hoffman-Andrews  wrote:
>
>> >   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
>>
> ___
> 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)

[Daniel McCarney]

I am also opposed to this change. I think it is a clunky solution and there
hasn't been convincing justification of why the base ACME draft needs to
carry this complexity instead of having STAR add the extensions it
requires.

On Mon, Oct 8, 2018 at 3:27 PM Jacob Hoffman-Andrews  wrote:

> >   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
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Allow get for certificates?

[Daniel McCarney]

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


I support this narrow fix.

On Mon, Oct 8, 2018 at 3:25 PM Jacob Hoffman-Andrews  wrote:

> 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  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 

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

[Daniel McCarney]

I'm strongly in favour of Jacob's suggestions in 459.

On Fri, Oct 5, 2018 at 7:17 PM Jacob Hoffman-Andrews  wrote:

> 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 listAcme@ietf.orghttps://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