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

[Eric Rescorla]

Thanks for clarifying.

On Mon, Oct 8, 2018 at 10:58 AM Salz, Rich  wrote:

>
>- No, because GET+capability > GET.  If you're going to have GET at
>all, you should have GET+capability
>
>
>
> And more importantly, you do not HAVE to do it; the text just has pointers
> on how to do it if desired.
>
___
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 

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

[Salz, Rich]

  *   No, because GET+capability > GET.  If you're going to have GET at all, 
you should have GET+capability

And more importantly, you do not HAVE to do it; the text just has pointers on 
how to do it if desired.
___
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]

No, because GET+capability > GET.  If you're going to have GET at all, you
should have GET+capability.

On Mon, Oct 8, 2018 at 12:43 PM Eric Rescorla  wrote:

> My question is whether you would remove the text that JSHA was objecting
> to about capabilities URLs.
>
> On Mon, Oct 8, 2018 at 6:31 AM Richard Barnes  wrote:
>
>> Not sure which existing text you're referring to.  No conflict comes to
>> mind.
>>
>> In particular, this seems compatible with the stuff in #post-as-get about
>> how the server indicates that it doesn't allow GET.  The model I have in
>> mind is that this flag indicates that it's reasonable for the client to try
>> GET, but the server may still deny in some cases.  Maybe that could be
>> clarified.
>>
>> On Mon, Oct 8, 2018, 09:24 Eric Rescorla  wrote:
>>
>>> Speaking as an individual.
>>>
>>> Just to be clear, this change would be expected to coexist with the
>>> existing capabilities text? Richard, does it require that we retain that
>>> text?
>>>
>>> -Ekr
>>>
>>>
>>> On Sun, Oct 7, 2018 at 4:37 PM Salz, Rich  wrote:
>>>
 WG, this PR adds a new optional indicator that GET can be used to fetch
 certificates.



 If you opposed please speak up now.



 *From: *Richard Barnes 
 *Reply-To: *ietf-wg-acme/acme <
 reply+006fe294e1a4ec2f9470322136bc74568ac35354a6bccd5792cf000117d224cc92a169ce15e8e...@reply.github.com
 >
 *Date: *Sunday, October 7, 2018 at 3:47 PM
 *To: *ietf-wg-acme/acme 
 *Cc: *Subscribed 
 *Subject: *[ietf-wg-acme/acme] Add a meta flag to indicate when GET
 requests for certificates are allowed (#462)



 This avoids the need for the client to guess. Assumes that #459
 
 will not be merged.
 --
 You can view, comment on, or merge this pull request online at:

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

- Add a meta flag to indicate when GET requests for certificates
are allowed

 File Changes

- *M* draft-ietf-acme-acme.md

 
(4)

 Patch Links:

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

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

 

 —
 You are receiving this because you are subscribed to this thread.
 Reply to this email directly, view it on GitHub
 ,
 or mute the thread
 
 .[image:
 https://github.com/notifications/beacon/AG_ilMuU3qzikm4v1_8wAF3QiJ0pjULGks5uilpMgaJpZM4XMAP2.gif]
 ___
 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)

[Eric Rescorla]

My question is whether you would remove the text that JSHA was objecting to
about capabilities URLs.

On Mon, Oct 8, 2018 at 6:31 AM Richard Barnes  wrote:

> Not sure which existing text you're referring to.  No conflict comes to
> mind.
>
> In particular, this seems compatible with the stuff in #post-as-get about
> how the server indicates that it doesn't allow GET.  The model I have in
> mind is that this flag indicates that it's reasonable for the client to try
> GET, but the server may still deny in some cases.  Maybe that could be
> clarified.
>
> On Mon, Oct 8, 2018, 09:24 Eric Rescorla  wrote:
>
>> Speaking as an individual.
>>
>> Just to be clear, this change would be expected to coexist with the
>> existing capabilities text? Richard, does it require that we retain that
>> text?
>>
>> -Ekr
>>
>>
>> On Sun, Oct 7, 2018 at 4:37 PM Salz, Rich  wrote:
>>
>>> WG, this PR adds a new optional indicator that GET can be used to fetch
>>> certificates.
>>>
>>>
>>>
>>> If you opposed please speak up now.
>>>
>>>
>>>
>>> *From: *Richard Barnes 
>>> *Reply-To: *ietf-wg-acme/acme <
>>> reply+006fe294e1a4ec2f9470322136bc74568ac35354a6bccd5792cf000117d224cc92a169ce15e8e...@reply.github.com
>>> >
>>> *Date: *Sunday, October 7, 2018 at 3:47 PM
>>> *To: *ietf-wg-acme/acme 
>>> *Cc: *Subscribed 
>>> *Subject: *[ietf-wg-acme/acme] Add a meta flag to indicate when GET
>>> requests for certificates are allowed (#462)
>>>
>>>
>>>
>>> This avoids the need for the client to guess. Assumes that #459
>>> 
>>> will not be merged.
>>> --
>>> You can view, comment on, or merge this pull request online at:
>>>
>>>   https://github.com/ietf-wg-acme/acme/pull/462
>>> 
>>> Commit Summary
>>>
>>>- Add a meta flag to indicate when GET requests for certificates are
>>>allowed
>>>
>>> File Changes
>>>
>>>- *M* draft-ietf-acme-acme.md
>>>
>>> 
>>>(4)
>>>
>>> Patch Links:
>>>
>>>- https://github.com/ietf-wg-acme/acme/pull/462.patch
>>>
>>> 
>>>- https://github.com/ietf-wg-acme/acme/pull/462.diff
>>>
>>> 
>>>
>>> —
>>> You are receiving this because you are subscribed to this thread.
>>> Reply to this email directly, view it on GitHub
>>> ,
>>> or mute the thread
>>> 
>>> .[image:
>>> https://github.com/notifications/beacon/AG_ilMuU3qzikm4v1_8wAF3QiJ0pjULGks5uilpMgaJpZM4XMAP2.gif]
>>> ___
>>> 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)

[Richard Barnes]

Not sure which existing text you're referring to.  No conflict comes to
mind.

In particular, this seems compatible with the stuff in #post-as-get about
how the server indicates that it doesn't allow GET.  The model I have in
mind is that this flag indicates that it's reasonable for the client to try
GET, but the server may still deny in some cases.  Maybe that could be
clarified.

On Mon, Oct 8, 2018, 09:24 Eric Rescorla  wrote:

> Speaking as an individual.
>
> Just to be clear, this change would be expected to coexist with the
> existing capabilities text? Richard, does it require that we retain that
> text?
>
> -Ekr
>
>
> On Sun, Oct 7, 2018 at 4:37 PM Salz, Rich  wrote:
>
>> WG, this PR adds a new optional indicator that GET can be used to fetch
>> certificates.
>>
>>
>>
>> If you opposed please speak up now.
>>
>>
>>
>> *From: *Richard Barnes 
>> *Reply-To: *ietf-wg-acme/acme <
>> reply+006fe294e1a4ec2f9470322136bc74568ac35354a6bccd5792cf000117d224cc92a169ce15e8e...@reply.github.com
>> >
>> *Date: *Sunday, October 7, 2018 at 3:47 PM
>> *To: *ietf-wg-acme/acme 
>> *Cc: *Subscribed 
>> *Subject: *[ietf-wg-acme/acme] Add a meta flag to indicate when GET
>> requests for certificates are allowed (#462)
>>
>>
>>
>> This avoids the need for the client to guess. Assumes that #459
>> 
>> will not be merged.
>> --
>> You can view, comment on, or merge this pull request online at:
>>
>>   https://github.com/ietf-wg-acme/acme/pull/462
>> 
>> Commit Summary
>>
>>- Add a meta flag to indicate when GET requests for certificates are
>>allowed
>>
>> File Changes
>>
>>- *M* draft-ietf-acme-acme.md
>>
>> 
>>(4)
>>
>> Patch Links:
>>
>>- https://github.com/ietf-wg-acme/acme/pull/462.patch
>>
>> 
>>- https://github.com/ietf-wg-acme/acme/pull/462.diff
>>
>> 
>>
>> —
>> You are receiving this because you are subscribed to this thread.
>> Reply to this email directly, view it on GitHub
>> ,
>> or mute the thread
>> 
>> .[image:
>> https://github.com/notifications/beacon/AG_ilMuU3qzikm4v1_8wAF3QiJ0pjULGks5uilpMgaJpZM4XMAP2.gif]
>> ___
>> 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)

[Eric Rescorla]

Speaking as an individual.

Just to be clear, this change would be expected to coexist with the
existing capabilities text? Richard, does it require that we retain that
text?

-Ekr


On Sun, Oct 7, 2018 at 4:37 PM Salz, Rich  wrote:

> WG, this PR adds a new optional indicator that GET can be used to fetch
> certificates.
>
>
>
> If you opposed please speak up now.
>
>
>
> *From: *Richard Barnes 
> *Reply-To: *ietf-wg-acme/acme <
> reply+006fe294e1a4ec2f9470322136bc74568ac35354a6bccd5792cf000117d224cc92a169ce15e8e...@reply.github.com
> >
> *Date: *Sunday, October 7, 2018 at 3:47 PM
> *To: *ietf-wg-acme/acme 
> *Cc: *Subscribed 
> *Subject: *[ietf-wg-acme/acme] Add a meta flag to indicate when GET
> requests for certificates are allowed (#462)
>
>
>
> This avoids the need for the client to guess. Assumes that #459
> 
> will not be merged.
> --
> You can view, comment on, or merge this pull request online at:
>
>   https://github.com/ietf-wg-acme/acme/pull/462
> 
> Commit Summary
>
>- Add a meta flag to indicate when GET requests for certificates are
>allowed
>
> File Changes
>
>- *M* draft-ietf-acme-acme.md
>
> 
>(4)
>
> Patch Links:
>
>- https://github.com/ietf-wg-acme/acme/pull/462.patch
>
> 
>- https://github.com/ietf-wg-acme/acme/pull/462.diff
>
> 
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> ,
> or mute the thread
> 
> .[image:
> https://github.com/notifications/beacon/AG_ilMuU3qzikm4v1_8wAF3QiJ0pjULGks5uilpMgaJpZM4XMAP2.gif]
> ___
> 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?

[Fossati, Thomas (Nokia - GB/Cambridge, UK)]

The 10/08/2018 09:49, Yaron Sheffer wrote:
> IMO Richard's proposal is too coarse, in the sense that servers may want to
> publish some certificates with GET and others with POST-as-GET. So either
> this should not be a server-wide flag, or if it is, it should be augmented
> by a per-Order flag where the client can request what it needs.

IIUC, your suggestion is to slightly change the semantics of
certificateGET to something like: "If this field is present and set to
"true", then the server, if requested by the client, allows GET requests
to certificate URLs (see {{post-as-get}}).", and add a new flag to the
Order to allow clients to request plain-GETs (which would be otherwise
405'd)?

If so, +1.

> Before this PR, the expectation is that certificates are only published with
> POST-as-GET by default. But extensions (such as STAR) can mandate that
> specific classes of certs be published with GET. If we don't want explicit
> per-Order signaling, we'd better leave the current text as-is.

I think PR#462 is one step in the right direction.  Going back to no
signalling, making this some sort of clandestine feature, is not great.

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

Re: [Acme] Allow get for certificates?

[Yaron Sheffer]

IMO Richard's proposal is too coarse, in the sense that servers may want 
to publish some certificates with GET and others with POST-as-GET. So 
either this should not be a server-wide flag, or if it is, it should be 
augmented by a per-Order flag where the client can request what it needs.


Before this PR, the expectation is that certificates are only published 
with POST-as-GET by default. But extensions (such as STAR) can mandate 
that specific classes of certs be published with GET. If we don't want 
explicit per-Order signaling, we'd better leave the current text as-is.


Thanks,

    Yaron


On 07/10/18 22:48, Richard Barnes wrote:

I went ahead and posted a PR adding the "meta" field:

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


On Sun, Oct 7, 2018 at 5:04 AM Thomas Fossati 
mailto:thomas.foss...@nokia.com>> wrote:


The 10/06/2018 17:27, 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.

>From the point of view of STAR this is not a big deal.  We have
acme-star where to define both the plain-GET exception - which is
a core
requirement for the delegation workflow - and how the server
advertises
support for it.

My worry is that by accepting this change, other legit plain-GET use
cases are automatically made either more complicated or potentially
insecure (someone might decide that sharing the account key across a
bunch of edge caches or some other HA configuration is a worth
trade-off.)

That said...

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

 it should be pretty easy to add the needed meta object extension
directly into the acme-acme document if this is the only missing
piece?

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

Emphatic +1



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