- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Thu, 06 Jun 2013 17:32:52 -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 for co-scribing the call yesterday. The minutes for this week's Web Payments telecon are now available here: http://payswarm.com/minutes/2013-06-05/ 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-05 Agenda: http://lists.w3.org/Archives/Public/public-webpayments/2013Jun/0001.html Topics: 1. Introduction to Andrei Opera 2. ISSUE-7: HTTP Signatures Security Review Process 3. Passive Attacks - Confidentiality Violations 4. Passive Attacks - Password Sniffing 5. Passive Attacks - Offline Cryptographic Attacks 6. Active Attacks - Replay 7. Telecon frequency Chair: Manu Sporny Scribe: Manu Sporny Present: Manu Sporny, Andrei Oprea, Mark Cavage, Dave Longley, Amr Fahmy, David I. Lehn, Brent Shambaugh Audio: http://payswarm.com/minutes/2013-06-05/audio.ogg Manu Sporny is scribing. Manu Sporny: Any updates to the agenda? Topic: Introduction to Andrei Opera Manu Sporny: Andrei is one of the GSoC people that submitted a GSoC application (but we didn't get enough slots to select him) [scribe assist by Dave Longley] Manu Sporny: Andrei, could you give us a brief intro? [scribe assist by Dave Longley] Andrei Oprea: I'm a 7th year CS student, interested in working on Web Payments, did a GSoC application. Andrei Oprea: I want to create an application for Web App store. Andrei Oprea: I want to have publishers submit their apps for sale, and an API that allows them to integrate into the web app store. Andrei Oprea: Publishing assets on application, you can integrate it w/ your web app, not restricted to the store. Andrei Oprea: if time permits, I want to extend on this idea, and implement in Firefox OS using mozPay API. Manu Sporny: we are currently also working with a couple of other communities to figure out how to do web payments in an open, decentralized way, we're working with the W3C in the web apps group, etc. and we'll want to introduce you to those people and we're also working with the GNURadio group to find out how to dynamically buy and sell radio spectrum to allow people to buy extra bandwidth in certain areas to watch/download high bandwidth videos, etc. [scribe assist by Dave Longley] Manu Sporny: as far as publishing the code will you be working with github? [scribe assist by Dave Longley] Andrei Oprea: Yes, I want to expand upon payswarm.js library - on github. Manu Sporny: for hosting, would you like us to host your app somewhere so you have a VM somewhere so you can have it live all the time? [scribe assist by Dave Longley] Manu Sporny: if you'd like us to host it for you, let us know, but if you have a better hosting solution, that's fine too [scribe assist by Dave Longley] Manu Sporny: whatever solution you pick we want to ensure it's up and running all the time so we can point people at it and understand the work you're doing, etc. [scribe assist by Dave Longley] Manu Sporny: no need to decide to today [scribe assist by Dave Longley] Manu Sporny: if you have any concerns or issues or questions, we'd love to help, so ask us, this IRC channel is a good way to do that [scribe assist by Dave Longley] Manu Sporny: any other questions on how things will run? [scribe assist by Dave Longley] Topic: ISSUE-7: HTTP Signatures Security Review Process https://github.com/web-payments/payswarm.com/issues/7 Manu Sporny: there's a desire from the IETF for us to do a security review of the HTTP signatures spec, typically it's the WG that does this, but it could take multiple months if we just rely on them, so we'd like to kickstart things and start the analysis to help move things along [scribe assist by Dave Longley] Manu Sporny: i'm expecting that mark cavage can help out with what some of the possible attacks/etc. are against the spec [scribe assist by Dave Longley] Dave Longley: http://en.wikipedia.org/wiki/STRIDE_(security) We're using this document as a starting point: http://tools.ietf.org/html/rfc3552 Mark Cavage: http://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx Manu Sporny: we'll be using the STRIDE security model [scribe assist by Dave Longley] Manu Sporny: we'll probably break the analysis into two parts, one for HTTP and one for HTTPS because the models are different [scribe assist by Dave Longley] Manu Sporny: we could avoid doing HTTP by saying this is only good for HTTPS, but i'd like us to do something for both HTTP and HTTPS [scribe assist by Dave Longley] Manu Sporny: mark, thoughts? [scribe assist by Dave Longley] Mark Cavage: yes, HTTP and HTTPS is good. Mark Cavage: HTTPS will be short/sweet - we want to cover both so people understand the tradeoffs. Topic: Passive Attacks - Confidentiality Violations http://tools.ietf.org/html/rfc3552#section-3.2.1 Manu Sporny: we'll start with the RFC and go through it point by point because it models the doc we'll have to write, then we'll go over STRIDE [scribe assist by Dave Longley] Manu Sporny: to start, we'll look at passive attacks, where an attacker reads packets off the network but doesn't write them, 3.2 Passive Attacks [scribe assist by Dave Longley] Manu Sporny: with HTTP you can sniff anything [scribe assist by Dave Longley] Mark Cavage: I don't know if this is specific to the HTTP Authorization header. Mark Cavage: The obvious thing here is that over HTTP, someone can steal the authorization header and replay the attack. Manu Sporny: our solution to a possible replay attack here would be some kind of nonce [scribe assist by Dave Longley] Mark Cavage: Yeah, that's the implementation we have today. Manu Sporny: it would likely be a time-based nonce where the server and client would have to have their clocks reasonably in sync [scribe assist by Dave Longley] Mark Cavage: (time-based nonce) Mark Cavage: besides replay - there are no secret data, but your key information (identity) can be leaked. Mark Cavage: There's a spear-fishing attack here. Dave Longley: You may also be able to collect general information that may be private - you can look at the request, cookies, etc. This also falls under passive attack. Manu Sporny: right, and all of these things are known attacks against HTTP, we're not creating anything new here [scribe assist by Dave Longley] Amr Fahmy: Joining to listen in... [noisy connection, muting] [scribe assist by Dave Longley] Manu Sporny: my concern would be that someone could use the authorization headers and other information to reduce the brute force attack area of the private key being used [scribe assist by Dave Longley] Mark Cavage: This is kinda the "security boogeyman" issue - if you gather enough statistical information, you /might/ be able to break it. Mark Cavage: There may not be enough random entropy in the beginning, so that might be an issue... for HTTP Signatures, it's not quite random - it's the HTTP signature string. maybe random noise in front of signing string. Mark Cavage: In terms of cryptanalysis, not a big piece of data you're signing, the string isn't starting with random entropy. That said, the risk of that is incredibly low. Dave Longley: Biggest concern might be what's safe to send over HTTP or HTTPS. We aren't creating new holes here, but people might think that we're proposing a mechanism to secure data over HTTP, which HTTP Signatures is not. Dave Longley: We might want to say that doing over HTTPS is not good enough for people - for example OAuth2 - people misconfiguring their HTTPS servers all the time. So we might tell people that they want to put random information or nonce-like data in the headers that are signed. It may not be as simple as saying "We'll just use HTTPS". Mark Cavage: I'm agreeing, but we should just say what the properties are. I wouldn't actually change the spec to accomodate this cryptanalysis attack. If someone has a provable/not theoretical exploit of this, we'll jump to the next crypto algorithm. Mark Cavage: There are theoretical attacks, but there are low risks that those theoretical attacks would happen. Dave Longley: Yeah, we really need to not change the spec, just outline the issues. Mark Cavage: Yes, section on nonces is important. Dave Longley: really need to have a clear best practices section [scribe assist by Dave Longley] Manu Sporny: for 3.2.1 Confidentiality Violations, there's nothing really new here for HTTP, all the attacks that exist for HTTP exist here -- plus there may be a statistical attack that one could mount against the http signatures header that lets you do some cryptoanalysis on it to reduce a brute force attack, but we know of none [scribe assist by Dave Longley] Dave Longley: Yeah, that's probably fair - what we're doing w/ signatures is what everybody else does with that. It's the same thing that would happen if signing data and sending it over cleartext. Manu Sporny: for HTTPS the same applies, the danger that exists is the same as OAuth2, misconfigured servers or maybe not having enough random bytes/long enough signature string, etc. [scribe assist by Dave Longley] Manu Sporny: all the attacks are theoretical, it's about breaking digital signatures and/or TLS [scribe assist by Dave Longley] Topic: Passive Attacks - Password Sniffing Manu Sporny: there are no passwords [scribe assist by Dave Longley] http://tools.ietf.org/html/rfc3552#section-3.2.2 Mark Cavage: Yeah, leaking a password is not possible here - no passwords. Group agrees. David I. Lehn: Is there a problem with people not understanding public/private keys? David I. Lehn: What if spear fishers ask for a private key? David I. Lehn: It's an education problem. Dave Longley: yeah, education problem. Mark Cavage: I think this is a problem for HMAC Mark Cavage: the -----BEGIN PRIVATE KEY---- thing works pretty well as a deterrent for people sharing the information with the public. Mark Cavage: to help people understand that they shouldn't be sharing it. Mark Cavage: HMAC keys are shared publicly more often than private keys, based on what I've seen. Dave Longley: Yeah, we can educate at the application level, not the protocol level. Manu Sporny: is HMAC something we want to put into the spec or not? [scribe assist by Dave Longley] Manu Sporny: HMAC may be more likely to be shared accidentally by end users, it's less clear that HMAC keys are private [scribe assist by Dave Longley] Manu Sporny: should we keep HMAC in or take it out? [scribe assist by Dave Longley] Mark Cavage: We might just take it out of the examples... we could insert whatever algorithm you want, the spec is open about that. Mark Cavage: People could still put HMAC in... don't have strong feelings about taking it out/ putting HMAC in. I agree, I don't ever want to use HMAC again, there's concerns about performance, etc. Manu Sporny: there's a debate about listing every kind of crypto algorithm that works with a spec, the downside is that everyone has to implement all of those algorithms but when interoperating you have to ensure both sides support what you want to use, so we might have to give a few algorithms that have to be supported, it can't be as openended as it is right now [scribe assist by Dave Longley] Mark Cavage: if somebody is going to demand HMAC in, we should put one form of it in. Manu Sporny: i think if we are going to put HMAC in we should only put one in as a requirement [scribe assist by Dave Longley] Manu Sporny: if it gets broken, we'll have another spec ready to go [scribe assist by Dave Longley] Manu Sporny: the spec text can say other things can be supported and give some instructions on how to write a spec defining the other algorithm(s) etc [scribe assist by Dave Longley] Dave Longley: I think we should say RSA, SHA1 and SHA256 are supported - that's the minimum... then we can say you can implement whatever you want, give them instructions on how to do it. Manu Sporny: so we could do that and leave out HMAC for now and wait for people to come along and request it to be added [scribe assist by Dave Longley] Mark Cavage: I'm ok with that - MUST support RSA SHA1 / SHA256 - you MAY support other things like HMAC. Dave Longley: Sounds good to me. Group agreement. Manu Sporny: we were on password sniffing and HMAC sort of falls into that category (sort of) ... secret key being analogous to password, if you use RSA there are no passwords [scribe assist by Dave Longley] Mark Cavage: Let's just not mention HMAC, thus password sniffing is not possible. Topic: Passive Attacks - Offline Cryptographic Attacks http://tools.ietf.org/html/rfc3552#section-3.2.3 Manu Sporny: easier to attack over HTTP vs. HTTPS, primary attack vector may be not enough randomness to the signature string or we create some kind of mechanism that allows statistical analysis to reduce brute force attack space [scribe assist by Dave Longley] Manu Sporny: if you break HTTPS the attack is the same as HTTP [scribe assist by Dave Longley] Manu Sporny: otherwise as safe as HTTPS (TLS) [scribe assist by Dave Longley] Manu Sporny: we can just point people at the offline attacks for RSA and SHA1/SHA256 [scribe assist by Dave Longley] Topic: Active Attacks - Replay http://tools.ietf.org/html/rfc3552#section-3.3.1 Manu Sporny: so the replay attacks we're concerned about (there are two classes), the first is replay over HTTP which is fairly trivial and replay over HTTPS where you send a message over HTTPS to a proxy and the proxy replays it to someone else [scribe assist by Dave Longley] Dave Longley: Does the spec currently say you have to sign the host header. Mark Cavage: The spec should say you MUST sign request line, host header, and content MD5. Dave Longley: There are HTTP proxy issues - rewriting of headers. Mark Cavage: We should come back to that one - that's a different issue - http proxies. Mark Cavage: HTTP should be MUST for request line, host header, should we have nonces? Dave Longley: We should say how to do this w/ chunked transfer encoding - you may not want to use content-md5, may want to do this in a trailer. Dave Longley: It would allow you to send content bodies where you don't know the length. Mark Cavage: The problem with trailers, is that the implementation sucks. Ruby doesn't deal w/ them, etc. Mark Cavage: It's a miracle when you find a stack that does - I'm of two minds. I agree w/ what the RFC says, but based on reality, half the stuff out there doesn't work with it. Manu Sporny: this requirement comes from a previous product in our company that was built on a streaming architecture [scribe assist by Dave Longley] Manu Sporny: you could do digital signatures on the streams (as long as the implementatino does it correctly and there are plenty that aren't) and it was a fairly nice way to make things work [scribe assist by Dave Longley] Manu Sporny: we don't have to make it a requirement to support trailers but implementations are not required to implement it [scribe assist by Dave Longley] Manu Sporny: that would reflect reality but allow support [scribe assist by Dave Longley] Mark Cavage: So what you're saying is if you want to do this, digitally sign the header, then do continue. Mark Cavage: Then attach signatures on the trailer. Dave Longley: If you want to do chunked-transfer encoding, you can do a second signature on the body. I want to make sure we don't lock people out of using the spec if they want to use it in a certain way. Mark Cavage: Not disagreeing, I buy it. I think saying "put the authorization header at the end" doesn't help. It might open up a Denial of Service attack. We could say "if you want to sign the body and use streaming uploads, you do it in two steps". Dave Longley: If there are people that have these sorts of interfaces, where they try to simplify things and don't want to implement buffering on one end, they have to do buffering anyway to do content-md5. Dave Longley: I'd like to prevent solutions that require either end to buffer the entire streaming content. Mark Cavage: These aren't mutually exclusive. Manu Sporny: let's just make a general issue for how to do chunked transfer encoding w/signatures [scribe assist by Dave Longley] Manu Sporny: so... for replay attacks we'll need to figure out what to do about nonces [scribe assist by Dave Longley] Manu Sporny: some people feel that implementations become far more difficult when you require nonces (which is true) we want to ensure that these implementations are easy so they don't have to remember nonces forever, etc. [scribe assist by Dave Longley] Manu Sporny: so that's one reason for discussing time-based nonces [scribe assist by Dave Longley] Manu Sporny: we'll have to argue against others who simply say nonces will never work and are never implemented properly, etc. [scribe assist by Dave Longley] Manu Sporny: do we want to try and tackle the nonce problem? [scribe assist by Dave Longley] Manu Sporny: it sounds like (from the discussion at the beginning of the call) we want to try and tackle the problem because we'd like this spec to work over HTTP [scribe assist by Dave Longley] Manu Sporny: so we'll probably be looking at time-based nonces [scribe assist by Dave Longley] Mark Cavage: Are nonces MUST or MAY? Manu Sporny: it seems like the HTTP signature spec will be blamed if we don't make a it a MUST [scribe assist by Dave Longley] Manu Sporny: do you feel the same way, mark? [scribe assist by Dave Longley] Mark Cavage: The security purist in me totally agrees with you, but I don't think many people get it right. We're setting ourselves up to fail because of nonces. Mark Cavage: I don't have an answer, I'm torn. Manu Sporny: we could look at history (since it's been bad) and just do the opposite [scribe assist by Dave Longley] Manu Sporny: or it could just be that nonces really just need to be required and it has to be implemented properly [scribe assist by Dave Longley] Mark Cavage: There are 2-3 implementations of SSL, there may be many more clients that implement this. Mark Cavage: There are a lot of implementation concerns here - same hellhole, how do you run this thing at scale. Mark Cavage: If they're optional, nobody is going to do it. If they are not, we're going to get criticized for getting it wrong. Brent Shambaugh: ... listening in, no comment for now Manu Sporny: so we're still split on what should be done for nonces, we agree that we should specify something but we dont' know if it should be MUST or MAY [scribe assist by Dave Longley] Mark Cavage: Yes, we should have a section on nonces, and decide MUST vs. MAY later on. Topic: Telecon frequency Manu Sporny: ok, looks like we have enough work now to have telecons once a week, so we'll meet against next week to continue this discussion. [scribe assist by Dave Longley] -- 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 Thursday, 6 June 2013 21:33:16 UTC