Re: [Acme] Terms of service agreement changes

[Hugo Landau]

On Sat, Aug 06, 2016 at 11:30:25AM -0700, Jacob Hoffman-Andrews wrote:
> Let's Encrypt recently did its first update of its Subscriber Agreement,
> and ran into some incompatibility. The current spec makes it seem like
> the client should update the registration object whenever the Subscriber
> Agreement (known in ACME as terms-of-service) changes.
> 
> However, early in drafting LE's Subscriber Agreement, we realized that
> if we required human approval of Subscriber Agreement changes, that
> would break auto-renewal. So our Subscriber Agreement says that updates
> automatically apply to existing users after a notice period.*
> 
> The existing ACME terms-of-service flow is an awkward hold-over from
> when we treated the new-reg URL as the entry point. Currently you create
> an account, get told the ToS URL, and update the account object with
> that URL. That then gets stored as a property of the registration object
> forever.
> 
> Now that we have the directory object, and it contains a
> terms-of-service URL, we can say that for CAs with a terms-of-service
> URL, you must agree before you can create an account. We can have an
> "agree": true field in the new-reg POST to signal agreement to the
> current terms-of-service from the directory object. Then the
> terms-of-service URL doesn't need to be a permanent part of the
> registration object, and we can avoid ambiguity over whether and when
> clients need to update or check it.

I don't think we need to get rid of the URI-based approach. Though this
is rather asinine, '"agree": true' would be vulnerable to race
conditions between retrieving the directory and registering (...).

Here are some more options:

1. Add a "agreement-valid": bool field to the registration object 
   which indicates whether the current agreement value is valid even
   if it doesn't match the ToS valid.

2. Have the server return a ToS link value equalling the old (but still
   acceptable) agreement value when returning registration data.
   Registrations with a no-longer-acceptable agreement value or
   no agreement set get the current ToS link value.

3. Update the agreement URI for all accounts when updating agreements,
   so that the agreement URI always matches the Link-advertised URI
   if the agreement is valid. Not really feasible if there's a notice
   period, though, assuming the notice period doesn't apply to new
   registrations.

I think option 1 is probably the best, but I may be biased in favour of
what's easiest to implement in my own client.

(In the LE case specifically, I wonder if the URI needs to change at all
if the agreement is designed so that updates apply automatically. Each
version should probably have an immutable archival URI, but a single
fixed URI could point to the current version. Still, this needs to be
worked out in the spec.)

Hugo Landau

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

Re: [Acme] Nonces for GETs

[Martin Thomson]

On 7 August 2016 at 04:55, Jacob Hoffman-Andrews  wrote:
> The rationale from the notes is that nonces are not a scarce resource.
> However, cachability and idempotence of GETs were not addressed. I think
> it's worth not requiring nonces on GETs purely for those reasons. In
> practical terms, this difference has caused real bugs for Let's Encrypt.

The hazard here is that you generate a cacheable response that
contains a nonce.  That means that clients could see the same nonce
twice if they pull from cache.  But the downside there is that you
could end up with a rejection when the nonce is used the second time.
The upside is that the rejection will contain a new nonce.  (If you
aren't retrying requests when you get a 4xx, then you will have a bad
day anyway).

Not sure about your question regarding idempotence.  Maybe you are
concerned about GET being safe (in the RFC7231 sense) and the
side-effects of the request.  To that, I'd suggest that if generating
a nonce is not safe in your server implementation, you have bought
yourself a lot of pain for nought.  Generating a nonce safely (e.g.,
without committing state) is fairly trivial.

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

Re: [Acme] Post-IETF-96 PRs

[Richard Barnes]

On Sat, Aug 6, 2016 at 12:57 PM, Peter Bowen  wrote:

> On Thu, Jul 28, 2016 at 2:52 PM, Richard Barnes  wrote:
> > Hey all,
> >
> > I just posted several PRs implementing agreements from the IETF meeting.
> >
> > #161 - Drop the OOB challenge
> > https://github.com/ietf-wg-acme/acme/pull/161
>
> I'm interested in the rationale for dropping the OOB challenge.  As it
> stands, the OOB challenge can be used to indicate that a given domain
> name (or namespace) is authorized.  This would seem to have value for
> existing CAs who want to offer some level of ACME compatibility but
> might not be able to make the whole pure-ACME workflow operate in
> their system.
>

Yeah, I noted this at the mic in IETF 96, and it just sort of got shrugs on
both sides.  I don't think anyone is calling real strongly for it to be
pulled out, so if you think it's useful, I'm happy to leave it.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Nonces for GETs

[Richard Barnes]

On Sat, Aug 6, 2016 at 2:55 PM, Jacob Hoffman-Andrews  wrote:

> At IETF 96 it was proposed to drop this issue:
> https://www.ietf.org/proceedings/96/minutes/minutes-96-acme.
>
> The rationale from the notes is that nonces are not a scarce resource.
> However, cachability and idempotence of GETs were not addressed. I think
> it's worth not requiring nonces on GETs purely for those reasons. In
> practical terms, this difference has caused real bugs for Let's Encrypt.
>

Could you comment a little more specifically on what issues this has caused
you?



> Would someone like to present a specific defense of providing a unique
> nonce with every GET?
>

As Ron notes, there's a need for some way to prime the nonce pump.  Because
POSTs require nonces, that means that we need either use a non-POST method
or modify POST behavior.  Let me propose a few options for people to opine
on...

Option 1: HEAD to some existing resource that admits a GET (e.g., directory)
Pro: Aligns with HTTP's requirement for GET == HEAD if you also send
Replay-Nonce for the GET
Con: ... but sending Replay-Nonce for the GET makes the affected resource
non-cacheable

Option 2: GET/HEAD to a new-nonce resource
Pro: Clean separation of the nonce-priming function
Con: One more resource to specify / provision / remember

Option 3: HEAD to the resource you would be POSTing to
Pro: Simple client logic; no need to use a separate resource
Con: Contrary to a SHOULD in RFC 7231, especially when the resource doesn't
respond to GET

Option 4: POST an empty body to the resource you would be POSTing to; get
nonce in error response
Pro: Client can use the same resource; priming POST can't be mistaken for a
real POST
Con: Client and server need a special case in their POST logic

I think my preference order would be 3 ~= 4 > 2 > 1, but I don't have
strong feelings here as long as we end up with something predictable for
the client to do.

--Richard



>
> ___
> 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] Terms of service agreement changes

[Richard Barnes]

On Sun, Aug 7, 2016 at 8:34 AM, Hugo Landau  wrote:

> On Sat, Aug 06, 2016 at 11:30:25AM -0700, Jacob Hoffman-Andrews wrote:
> > Let's Encrypt recently did its first update of its Subscriber Agreement,
> > and ran into some incompatibility. The current spec makes it seem like
> > the client should update the registration object whenever the Subscriber
> > Agreement (known in ACME as terms-of-service) changes.
> >
> > However, early in drafting LE's Subscriber Agreement, we realized that
> > if we required human approval of Subscriber Agreement changes, that
> > would break auto-renewal. So our Subscriber Agreement says that updates
> > automatically apply to existing users after a notice period.*
> >
> > The existing ACME terms-of-service flow is an awkward hold-over from
> > when we treated the new-reg URL as the entry point. Currently you create
> > an account, get told the ToS URL, and update the account object with
> > that URL. That then gets stored as a property of the registration object
> > forever.
> >
> > Now that we have the directory object, and it contains a
> > terms-of-service URL, we can say that for CAs with a terms-of-service
> > URL, you must agree before you can create an account. We can have an
> > "agree": true field in the new-reg POST to signal agreement to the
> > current terms-of-service from the directory object. Then the
> > terms-of-service URL doesn't need to be a permanent part of the
> > registration object, and we can avoid ambiguity over whether and when
> > clients need to update or check it.
>
> I don't think we need to get rid of the URI-based approach. Though this
> is rather asinine, '"agree": true' would be vulnerable to race
> conditions between retrieving the directory and registering (...).
>
> Here are some more options:
>
> 1. Add a "agreement-valid": bool field to the registration object
>which indicates whether the current agreement value is valid even
>if it doesn't match the ToS valid.
>
> 2. Have the server return a ToS link value equalling the old (but still
>acceptable) agreement value when returning registration data.
>Registrations with a no-longer-acceptable agreement value or
>no agreement set get the current ToS link value.
>
> 3. Update the agreement URI for all accounts when updating agreements,
>so that the agreement URI always matches the Link-advertised URI
>if the agreement is valid. Not really feasible if there's a notice
>period, though, assuming the notice period doesn't apply to new
>registrations.
>
> I think option 1 is probably the best, but I may be biased in favour of
> what's easiest to implement in my own client.
>
> (In the LE case specifically, I wonder if the URI needs to change at all
> if the agreement is designed so that updates apply automatically. Each
> version should probably have an immutable archival URI, but a single
> fixed URI could point to the current version. Still, this needs to be
> worked out in the spec.)
>

I agree with Hugo that it seems like there's still value in having the URI
in the registration object.  It seems like there's probably requirements on
both sides here:

- The CA needs to be able prompt re-agreement
- The CA needs to be able to update the terms/SA URL without prompting
re-agreement

We can meet both of these if, as Hugo notes, we let the CA update the
agreement URI in the registration object.  Then the client can compare the
URI in the object to the URI in the directory / link header, and if they
differ, prompt for re-agreement (or deactivate the registration).

Spec-wise, I think we would just want to add a note that the server can
update the agreement URL in the registration object in cases where
agreement with the old implies agreement with the new (e.g., if they
represent the same document and just the URL changed).  We might also want
an "agreementRequired" error code that the server can use to explicitly
prompt for re-agreement.

--Richard



>
> Hugo Landau
>
> ___
> 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] Post-IETF-96 PRs

[Martin Thomson]

On 8 August 2016 at 12:39, Richard Barnes  wrote:
> So I'm honestly not that convinced that we need versioning at all here.
> Maybe we could get away with just versioning the directory?  (As I think the
> original issue proposed :) )


I believe that it was PHB who requested this originally, the rationale
being that you might create a new version of the same resource/request
that looked similar, but had different semantics.  Rather than rely on
having us (in all our possible future incarnations) not doing that, a
version indicator would make signatures invalid.

If that is a requirement that you accept, then a much simpler scheme
than the one you wrote up is possible.  Versioning the directory isn't
sufficient to achieve that goal though.  The first part of your PR
would work though: include a version, and require that it be checked.

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

Re: [Acme] Post-IETF-96 PRs

[Martin Thomson]

On 7 August 2016 at 03:46, Jacob Hoffman-Andrews  wrote:
>> #162 - Add a protocol version
>> https://github.com/ietf-wg-acme/acme/pull/162
>
> Still thinking about this one. Seems sound at first glance, but I'm thinking
> about TLS version intolerance and
> https://www.imperialviolet.org/2016/05/16/agility.html.

For similar reasons, I think that this change might be a little
overwrought.  It's certainly a non-trivial amount of added complexity.

Would it be acceptable to have a much simpler scheme that included the
version (a simple string that has to match) in the payload of all
messages?  That keeps this as a sanity check that you aren't
transporting things between incompatible versions.  The server can
provide new endpoints if it wants to support new (incompatible)
versions.

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

Re: [Acme] Post-IETF-96 PRs

[Richard Barnes]

On Sun, Aug 7, 2016 at 7:28 PM, Martin Thomson 
wrote:

> On 7 August 2016 at 03:46, Jacob Hoffman-Andrews  wrote:
> >> #162 - Add a protocol version
> >> https://github.com/ietf-wg-acme/acme/pull/162
> >
> > Still thinking about this one. Seems sound at first glance, but I'm
> thinking
> > about TLS version intolerance and
> > https://www.imperialviolet.org/2016/05/16/agility.html.
>
> For similar reasons, I think that this change might be a little
> overwrought.  It's certainly a non-trivial amount of added complexity.
>

Overwrought, indeed.  It certainly felt that way while writing it, but
that's where the line of thinking seemed to lead me.

Maybe it's worthwhile stepping back and asking what sorts of changes we
might want to make, and how those should be done.

Within the framework we have right now, you can already add new
functionality by adding resources or fields on objects.  If you want to
require the new functionality, you can add error codes to cleanly fail old
clients.  And if you want to do something totally different, you can change
the directory URL.

So I'm honestly not that convinced that we need versioning at all here.
Maybe we could get away with just versioning the directory?  (As I think
the original issue proposed :) )

--Richard



>
> Would it be acceptable to have a much simpler scheme that included the
> version (a simple string that has to match) in the payload of all
> messages?  That keeps this as a sanity check that you aren't
> transporting things between incompatible versions.  The server can
> provide new endpoints if it wants to support new (incompatible)
> versions.
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme