Subject: Re: [Tools-discuss] Auto-posting IESG ballots

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 19 Dec 2017 11:03:31 +0100

Hi Ekr,

In yesterday's datatracker release 6.68.0, now deployed, an API to auto-
post iesg ballot positions was included.

A brief description of usage, with an example, is available here:

  https://datatracker.ietf.org/api/#iesg-position-api

The limitations on the API keys follow what we discussed below.  For testing
purposes, you may want to use the datatracker sandbox,

  https://sandbox.ietf.org/

where your password is 'password' (as is that of everybody else).

Any personal API keys you create on the sandbox server will not carry over
to the production site, and will be overwritten within 24 hours when the
next database update comes in from the production site (just after 5 in the
morning, PST).  The same goes for positions and other changes you may make.

Please let me know when you've had time to try it out, and of course if you
have comments and questions about the API endpoint.

Best regards,

	Henrik

On 2017-10-18 20:50, Eric Rescorla wrote:
> On Wed, Oct 18, 2017 at 11:43 AM, Henrik Levkowetz <[email-masked]>
> wrote:
> 
>>
>> On 2017-10-18 17:37, Eric Rescorla wrote:
>> > On Wed, Oct 18, 2017 at 8:31 AM, Henrik Levkowetz <[email-masked]>
>> > wrote:
>> >
>> >>
>> >> On 2017-10-18 16:58, Eric Rescorla wrote:
>> >> > On Wed, Oct 18, 2017 at 7:54 AM, Henrik Levkowetz <
>> [email-masked]>
>> >> > wrote:
>> >> >
>> >> >>
>> >> >> On 2017-10-18 16:47, Eric Rescorla wrote:
>> >> >> > Thanks. I would actually be fine with replicating the existing API
>> >> >> surface
>> >> >> > (it's not that hard to generate form fills), as long as I could
>> use an
>> >> >> API
>> >> >> > key rather than a cookie, because it's a real pain to replicate the
>> >> >> > anti-CSRF logic.
>> >> >>
>> >> >> I'm fine with an API key as alternative to anti-CSRF, but would not
>> >> like to
>> >> >> rely on only that for authorization.
>> >> >
>> >> >
>> >> > I was thinking a per-user API token
>> >>
>> >> Yes, I assumed that.
>> >>
>> >> > the way that (say) the Github API works.
>> >> > Would that be a problem?
>> >>
>> >> I'll go and check the github API key details and the way they are used.
>> >>
>> >> Essentially, what you're proposing is to use a combined authentication
>> >> and authorization token instead of username+password.  If that token
>> >> doesn't leak, it should not be a problem.  If it leaks, it's of course
>> >> a potential problem.
>> >>
>> >
>> > Right, but of course that's the situation for a password as well.
>>
>> Agreed, but you clearly aim to limit exposure of the password more
>> strongly than the API key.  To counterbalance this, I believe the
>> API key should be limited in what it authorizes the holder to do.
>> More below.
>>
> 
> This seems conceptually fine.
> 
> 
>>> One property of API keys is often that they have a limited lifetime,
>> >> in order to reduce the impact of leakage.  Given what you write below,
>> >> I guess that's a property you would like to avoid, too?  Or would that
>> >> be acceptable?
>> >>
>> >
>> > Yes, I would like to avoid that. The invariant I want to have here is
>> that
>> > I can provision the bridging server (the one that moves data back and
>> > forth between phabricator and the data tracker) with credentials for
>> > each side and then let it run indefinitely. At the end of the day,
>> > one might imagine merging that logic into phab or the datatracker
>> > or both, but because you want to avoid polling, the upshot will
>> > still be distribution of credentials.
>>
>> Right.
>>
>> Ok, so in order to limit the damage an exposed API key can do, here are
>> some thoughts:
>>
>>  * Provide a GUI to revoke a key (necessary in any case) and give
>>    an overview of existing keys and their usage.
>>
> 
> This seems like a good plan.
> 
> 
>  * Time limit the validity of the key to N days (30?) from the time of
>>    the latest login to the datatracker using username+password.
>>
> 
> Yeah, this seems like it would probably work though might be brittle.
> 
> 
>  * Limit the key to a given URL path prefix (e.g., /api/iesg/ballot/)
>>    This means having multiple keys if we evolve additional API endpoints,
>>    which I expect to happen.
>>
>>  * Provide regular information in the datatracker GUI about API key
>>    activity in a manner easily digested and minimally distracting.
>>    Maybe a message once a week, summarising the activity?
>>
> 
> Both of these seem like good ideas.
> 
> -Ekr
> 
> 
>>
>> Thoughts?
>>
>>         Henrik
>>
>>
>> >
>> > -Ekr
>> >
>> >
>> >> > Are you ok with doing a regular login
>> >> >> cycle to cookie storage ahead of posting to the form with the API
>> key?
>> >> >>
>> >> >
>> >> > I could also do this as long as the cookie was perpetual so I could
>> >> > log in through my browser and then store the cookie on the server.
>> >> > I'd like to avoid having my password on the server.
>> >>
>> >> Understood.
>> >>
>> >>         Henrik
>> >>
>> >> >
>> >> > -Ekr
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >>
>> >> >>         Henrik
>> >> >>
>> >> >> > -Ekr
>> >> >> >
>> >> >> >
>> >> >> > On Wed, Oct 18, 2017 at 5:19 AM, Henrik Levkowetz <
>> >> [email-masked]>
>> >> >> > wrote:
>> >> >> >
>> >> >> >> Hi Ekr,
>> >> >> >>
>> >> >> >> On 2017-10-17 15:52, Eric Rescorla wrote:
>> >> >> >> > Hi folks.
>> >> >> >> >
>> >> >> >> > I've been working some more on my IETF review tools and I'm now
>> at
>> >> the
>> >> >> >> point
>> >> >> >> > where I want to take an external review and hoist it into the
>> IESG
>> >> >> >> Ballot.
>> >> >> >> > Is there
>> >> >> >> > an existing API surface for this kind of thing? Perhaps one
>> which
>> >> >> takes
>> >> >> >> an
>> >> >> >> > auth token
>> >> >> >> > so no CSRF/cookie nonsense?
>> >> >> >>
>> >> >> >> No, there isn't, but adding an endpoint for this isn't that hard.
>> >> There
>> >> >> >> are things ahead of it in the queue, though ,:-)
>> >> >> >>
>> >> >> >>
>> >> >> >> Best regards,
>> >> >> >>
>> >> >> >>         Henrik
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >
>>
>>
> 
> 
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Dec 2017 05:55:29 -0800

Thanks!

On Tue, Dec 19, 2017 at 2:03 AM, Henrik Levkowetz <[email-masked]>
wrote:

> > On Wed, Oct 18, 2017 at 11:43 AM, Henrik Levkowetz <[email-masked]
> >
> > wrote:
> >
> >>