Re: [Acme] Allow get for certificates?

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

[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

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

[Salz, Rich]

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 

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