Re: [Acme] Allow get for certificates?

2018-10-09 Thread 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] Allow get for certificates?

2018-10-08 Thread 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] Allow get for certificates?

2018-10-08 Thread 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?

2018-10-08 Thread 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

Re: [Acme] Allow get for certificates?

2018-10-07 Thread Richard Barnes 
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 
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

Re: [Acme] Allow get for certificates?

2018-10-07 Thread Thomas Fossati 
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

Re: [Acme] Allow get for certificates?

2018-10-06 Thread Richard Barnes 
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 code 405 "Method Not
>>
>> -Allowed" and type "malformed".
>>
>> -
>>
>> ## Request URL Integrity
>>
>>  It is common in deployment for the entity terminating TLS for HTTPS to
>> be different
>>
>>
>> ___
>> 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] Allow get for certificates?

2018-10-06 Thread Eric Rescorla 
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 code 405 "Method Not
>
> -Allowed" and type "malformed".
>
> -
>
> ## Request URL Integrity
>
>  It is common in deployment for the entity terminating TLS for HTTPS to be
> different
>
>
> ___
> 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] Allow get for certificates?

2018-10-06 Thread Salz, Rich 
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 terminating TLS for HTTPS to be 
different

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