- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Wed, 19 Jun 2013 12:51:01 -0400
- To: Web Payments <public-webpayments@w3.org>
- CC: IETF HTTP Auth <http-auth@ietf.org>
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/
Received on Wednesday, 19 June 2013 16:51:25 UTC