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

From: Manu Sporny <[email-masked]>
Date: Thu, 06 Jun 2013 17:32:52 -0400

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/