Subject: [http-auth] Web Payments Telecon Minutes for 2013-06-19

From: Manu Sporny <[email-masked]>
Date: Wed, 19 Jun 2013 12:51:01 -0400

cc: IETF HTTP Auth WG (this call dealt with the HTTP Signatures spec)

Thanks to Dave Longley for scribing the call today. The minutes for this
week's Web Payments telecon are now available here:

https://payswarm.com/minutes/2013-06-19/

Full text of the discussion follows for archival purposes at the W3C.
Audio of the meeting is available as well (link provided below).

--------------
Web Payments Community Group Telecon Minutes for 2013-06-19

Agenda:
   http://lists.w3.org/Archives/Public/public-webpayments/2013Jun/0025.html
Topics:
   1. HTTP Signatures - Nonce Support
   2. Update on GSoC Student Progress
   3. HTTP Signatures - Trailer Support
Chair:
   Manu Sporny
Scribe:
   Dave Longley
Present:
   Dave Longley, Manu Sporny, David I. Lehn, Brent Shambaugh,
   Andrei Oprea
Audio:
   https://payswarm.com/minutes/2013-06-19/audio.ogg

Dave Longley is scribing.
Manu Sporny:  Mark Cavage is not going to be able to join today,
   but we need to get through the nonce/trailer stuff since next
   week will be the Payment API. Any updates or changes to the
   Agenda?

Topic: HTTP Signatures - Nonce Support

Manu Sporny:  we've been alluding to dealing with nonces in the
   last few calls and what we've been focusing on is looking at
   time-based (time-window) nonce
Manu Sporny:  we're expecting that the nonce will have some kind
   of client id/some kind of rule for the nonce to be incremented
Manu Sporny:  nonces could be used for both HTTP and HTTPS (if
   you want extra protection)
Manu Sporny:  nonces are specifically designed in this spec to
   handle replay attacks over HTTP
Manu Sporny:  the basic parameters are the nonces are generated
   and must always increment, if a nonce is used the date field must
   be included in the digital signature, if nonce is there, you must
   include a nonce parameter and the date field but it's currently
   unknown where the client ID will be placed
Dave Longley:  I don't know if we dramatically simplify server
   implementations by having a client-ID. If it just keeps track of
   every nonce that comes in over a time window. [scribe assist by
   Manu Sporny]
Dave Longley:  Having a client ID doesn't simplify the server, I
   don't think. [scribe assist by Manu Sporny]
Dave Longley:  The way the client generates a client ID is not
   necessary. [scribe assist by Manu Sporny]
Dave Longley:  it can just be a random value. [scribe assist by
   Manu Sporny]
Manu Sporny:  Isn't the random value a client ID. [scribe assist
   by Manu Sporny]
Manu Sporny:  i didn't intend for this to mean that it's a
   session
Dave Longley:  The nonce is an opaque value to the server.
   [scribe assist by Manu Sporny]
Manu Sporny:  what i'm trying to address here is what if you have
   two pieces of software on your phone from the same IP address,
   how the server know which incrementing nonce is which
Dave Longley:  It's true that a session ID + a counting nonce
   results in a smaller memory usage. [scribe assist by Manu Sporny]
Dave Longley:  The client generates a random value that is
   sufficiently long enough that there will be no clashes. The
   server looks for the next nonce to be higher than the previous
   nonce. [scribe assist by Manu Sporny]
Dave Longley:  emphasis is on incrementing, not necessarily by 1,
   it just needs to be higher than the previous one. [scribe assist
   by Manu Sporny]
Manu Sporny:  What exactly does the signature string look like
   now? [scribe assist by Manu Sporny]
Dave Longley:  I think we want something like this:
   clientId=abce7de767eebf, nonce=abac8ec6e7cece
Dave Longley:  Perhaps this instead, nonce=1
Manu Sporny:  we should be very clear and explicit about how to
   implement nonces in the spec
Manu Sporny:  instead of just letting it be a grab bag of options
Manu Sporny:  to make things simpler for implementers
Dave Longley:  Let's just make the nonce a 32-bit integer, it
   counts up. Hopefully you won't make 4 billion requests in a 5
   minute time window. If you do, generate a new clientId. The
   ClientID should be sufficiently long over a 5 minute window.
   [scribe assist by Manu Sporny]
Manu Sporny:  We could do it by IP address. [scribe assist by
   Manu Sporny]
Dave Longley:  I think it starts becoming more complicated in
   that sense... let's just make it sufficiently long enough - how
   many bytes, hex-encoded, placed into the signature as a signature
   parameter. [scribe assist by Manu Sporny]
Manu Sporny:  So how long is long enough? [scribe assist by Manu
   Sporny]
Dave Longley:  128 bits - 16 bytes. [scribe assist by Manu
   Sporny]
Dave Longley:  nonce starts at 1 and counts up [scribe assist by
   Manu Sporny]
Dave Longley:  32-bit number [scribe assist by Manu Sporny]
Dave Longley:  not hex-encoded [scribe assist by Manu Sporny]
David I. Lehn: thinks these rules might be too arbitrary for a
   spec
David I. Lehn:  You're picking numbers and those numbers might
   not work for everyone. [scribe assist by Manu Sporny]
Dave Longley:  We're picking 128-bit because we want to pick
   something that will probably not clash. [scribe assist by Manu
   Sporny]
Dave Longley:  We could be more specific about talking about this
   stuff - we have a 5 minute time window, how many clients will
   connect over that timeframe. [scribe assist by Manu Sporny]
Manu Sporny:  we could look at the number of requests for google+
   and see if you generated a random number if there would be a
   clash
Manu Sporny:  if we wanted to support a billion simultaneous
   clients, etc. we could see what the chance is for two clients
   picking the same ID
Manu Sporny:  we think 128 bit would make it very unlikely for a
   clash even for the next 10 years, etc.
Brent Shambaugh: I found this while trying to learn more. Frame
   of reference? Nonces in Bitcoin: https://en.bitcoin.it/wiki/Nonce
   (32 bit)
Dave Longley:  Also, the time window matters - we aren't
   necessarily setting it. [scribe assist by Manu Sporny]
Dave Longley:  IPv6 addresses are 128-bit as well - it's not too
   large to put into an HTTP header... we don't need anything larger
   than that, really. number of unique addresses. [scribe assist by
   Manu Sporny]
Manu Sporny:  if the numbers we picked are wrong, reviewers will
   complain loudly
Manu Sporny:  we can also add a note to fix these limits later as
   needed
David I. Lehn:  it seems like everyone should just be using
   HTTPS, i don't understand the use case for HTTP
David I. Lehn:  are people actually going to use this protocol at
   all in the non-secure case?
Manu Sporny:  are you arguing to remove nonces from the spec and
   HTTP support?
David I. Lehn:  i just know it's complicated and wonder if we
   need to put the extra effort in for this
Manu Sporny:  if we don't put nonces in here it removes a class
   of applications that just wants to use HTTP
David I. Lehn:  i just think these issues will double the size of
   the spec or more, it will be added complexity that people will
   have to try and understand before using this
Manu Sporny:  before trying to run it over HTTP
David I. Lehn:  if half of the spec is optional it seems kind of
   silly to me
David I. Lehn:  we'll have to consider that clients will have to
   be buffering things
Manu Sporny:  well, it's much easier on the client because the
   client only needs to store one server session ID
Manu Sporny:  you generate a random number for the client ID and
   initialize the nonce to 1 and then count up, that should be it
   for sending requests
Manu Sporny:  for the server, you just store client IDs and then
   make sure the nonce is incrementing
David I. Lehn:  well, it's just more complicated than not having
   to do any of that
Manu Sporny:  well, yeah, but if someone wants to use HTTP this
   is what has to be done to prevent against replay attacks
Manu Sporny:  i agree that it's more complicated, but if we do
   want to support this over HTTP we have to do this
Dave Longley:  btw, we shouldn't call it client ID because the
   server might want to use it in responses
Dave Longley:  I think we include the request line, host and
   date. [scribe assist by Manu Sporny]
Manu Sporny:  should we always include the date?
David I. Lehn:  The implementation in PaySwarm does that by
   default, but the spec itself just does the date. We're more
   strict. [scribe assist by Manu Sporny]
Dave Longley:  What do we do? [scribe assist by Manu Sporny]
Dave Longley:  We sign the request line, host and date - it's
   going to be broken if you don't do that. [scribe assist by Manu
   Sporny]
Manu Sporny:  When you sign you have to include the sessionId and
   the nonce value? [scribe assist by Manu Sporny]
Dave Longley:  We could call it nonce and the other thing be the
   counter. [scribe assist by Manu Sporny]
Dave Longley:  We can mess around with the names later. [scribe
   assist by Manu Sporny]
Manu Sporny:  Seems strange - nonce stands for "only once"
   [scribe assist by Manu Sporny]
Dave Longley:  Let's not re-use that, I haven't looked that
   closely in Digest Access Auth, we should come up with another
   name. [scribe assist by Manu Sporny]
Manu Sporny:  Where does it go? At the front of the signature?
   [scribe assist by Manu Sporny]
Dave Longley:  Yeah, at the front, helps with randomness...
   [scribe assist by Manu Sporny]
Manu Sporny:  So place the clientID and then the nonce at the
   beginning as they're encoded in the message.  [scribe assist by
   Manu Sporny]
Dave Longley:  There is no reason we need to decode them.
   Consider both a string. [scribe assist by Manu Sporny]
Dave Longley:  ASCII string since it's over HTTP. [scribe assist
   by Manu Sporny]
Dave Longley:  Once it's Base64 encoded, it's ASCII, just use
   that value. [scribe assist by Manu Sporny]
Brent Shambaugh:  wasn't really familiar with nonces, started
   looking at Bitcoin, proof of work. [scribe assist by Manu Sporny]
Manu Sporny:  I don't know how useful proof of work is -
   definitely not for the server, maybe for the client? [scribe
   assist by Manu Sporny]
Dave Longley:  Don't know how useful it is for what we're trying
   to do here. [scribe assist by Manu Sporny]

Topic: Update on GSoC Student Progress

Andrei Oprea:  what i've done this week is implement a really
   basic website
Andrei Oprea:  i've managed to public/private key pair and
   register with payswarm using the JS module
Manu Sporny:  do you have the site running publically some where?
Andrei Oprea:  not yet, i'll do that
Andrei Oprea: https://github.com/piatra/webpayments-marketplace
Andrei Oprea:  i wanted to get listings working sometime this
   week
Andrei Oprea:  i wanted to give a rough idea of what's going on
   and have some people try it out
Manu Sporny:  any questions?
Andrei Oprea:  so far things have gone well, i've been following
   along with the blog posts manu wrote and no questions so far
Manu Sporny:  yeah, we're interested in seeing how persona will
   work out, getting it integrated w/web payments
Manu Sporny:  ok, great job, andrei

Topic: HTTP Signatures - Trailer Support

Manu Sporny:  so the main question here is what will be in the
   trailer's authentication header
Manu Sporny:  We will want to sign the header, and then sign the
   trailer (including all headers in the header) [scribe assist by
   Manu Sporny]
Dave Longley:  I think most servers can store all the headers
   that came across... trying to simplify processing of trailers
   authentication header. Could you just process the previous
   authentication header and then add whatever trailers you wanted?
   [scribe assist by Manu Sporny]
Dave Longley:  Would that work? Or would that looks strange?
   [scribe assist by Manu Sporny]
Dave Longley:  It would look like it's listing itself... if you
   authenticated other stuff previously, maybe that would be
   sufficient. [scribe assist by Manu Sporny]
Manu Sporny: Authorization: Signature
Manu Sporny: https://payswarm.com/specs/source/http-signatures/
Manu Sporny: Authorization: Signature
   keyId="Test",algorithm="rsa-sha256",headers="request-line host
   date content-type content-md5 content-length",
Dave Longley:  That's what it would look like, minus the
   content-md5 [scribe assist by Manu Sporny]
Authorization: Signature
   keyId="Test",algorithm="rsa-sha256",headers="request-line host
   date content-type"
Dave Longley:  ^^ that would be in the request header. [scribe
   assist by Manu Sporny]
Authorization: Signature
   keyId="Test",algorithm="rsa-sha256",headers="authorization
   content-md5 x-my-trailer"
Dave Longley:  In the trailer, you would get this ^^ [scribe
   assist by Manu Sporny]
Dave Longley:  It may seem circular to people. [scribe assist by
   Manu Sporny]
Dave Longley:  it isn't ... you are supposed to use the value
   from the header
Manu Sporny:  We might want to be more clear than just using
   'authorization' [scribe assist by Manu Sporny]
Dave Longley:  We could make both suggestions, maybe Mark has an
   opinion. [scribe assist by Manu Sporny]
Dave Longley:  Other than that, it doesn't seem like there is a
   limitation in the trailers for what we could put in there.
   [scribe assist by Manu Sporny]
Dave Longley:  You can't have another trailers header in
   trailers. We could repeat the authorization header, it's just how
   implementations will deal with that and we still don't know how
   many implementations deal with it correctly anyway. [scribe
   assist by Manu Sporny]
Dave Longley:  We don't know how implementations deal w/ repeated
   headers... which authorization header? Trailer or Header? [scribe
   assist by Manu Sporny]
Dave Longley:  Our decision might depend on what we think other
   implementations might do - the problem with this idea is that
   it's not well implemented (trailers) [scribe assist by Manu
   Sporny]
Dave Longley:  sort of have a catch-22 here, we want to spec out
   what to do with trailers just in case anyone implements them, but
   we need to know how they implement them to get a good idea of how
   to specify this
Manu Sporny:  ok, next week we're going to be talking about
   whitelists
Manu Sporny:  with respect to payment APIs

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/