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 Log
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: 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: 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

Created by the Web Payments Community Group. Shared with love under a CC-BY license.