Web Payments Telecon Minutes for 2013-06-05

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

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

http://payswarm.com/minutes/2013-06-12/

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-12

Agenda:
   http://lists.w3.org/Archives/Public/public-webpayments/2013Jun/0021.html
Topics:
   1. Security Considerations for HTTP Signatures
   2. Nonces and Trailers
   3. Amr Fahmy and Summer of Code
   4. Active Attacks - Message Insertion
   5. Active Attacks - Message Deletion / Modification
   6. Active Attacks - Man-In-The-Middle
   7. On-path / Off-path Attacks / Link-Local
   8. Next Steps
Resolutions:
   1. Add a section on nonces to the HTTP Signatures
      specification, but make them an optional feature.
Chair:
   Manu Sporny
Scribe:
   David I. Lehn
Present:
   David I. Lehn, Manu Sporny, Mark Cavage, Dave Longley, Amr Fahmy,
   Brent Shambaugh
Audio:
   http://payswarm.com/minutes/2013-06-12/audio.ogg

David I. Lehn is scribing.
Manu Sporny:  Any updates to agenda?

Topic: Security Considerations for HTTP Signatures

Manu Sporny:
   https://payswarm.com/specs/source/http-signatures-audit/
Manu Sporny:  I've started the security considerations document,
   going to update as we go through attacks.
Manu Sporny:  New attack on message insertion. Not a big deal,
   and don't need to change spec, but need to let people now.

Topic: Nonces and Trailers

Mark Cavage:  Should touch on nonces and trailers.
Mark Cavage:  Don't want to require nonces. Make the optional and
   not MUST. Too difficult for wide adoption.
Manu Sporny:  Seemed like consensus, have nonces but make them
   optional.
Mark Cavage:  For general spec it seems like too much, for
   payments it may be appropriate.
Manu Sporny:  Personal applications may not require nonces.
Manu Sporny:  What do people think?

PROPOSAL:  Add a section on nonces to the HTTP Signatures
   specification, but make them an optional feature.

Manu Sporny: +1
Dave Longley: +1
David I. Lehn: +1
Mark Cavage: +1

RESOLUTION: Add a section on nonces to the HTTP Signatures
   specification, but make them an optional feature.

Dave Longley:  Can detail drawbacks for not implementing nonces
Manu Sporny:  Let's talk about signatures in trailers.
Mark Cavage:  Can you send authorization twice? once in header
   and once in trailer
Manu Sporny:  How to sign content? mcavage using Content-MD5 in
   spec but it's being deprecated in HTTP 2.
Manu Sporny:  Might need to use another header (Content-SHA256)
   or similar
Mark Cavage:  Why is the HTTPbis WG removing it?
Manu Sporny:  Issues with proxies and partial content. Was a
   brittle feature. Not sure what replacement is.
Dave Longley: http://tools.ietf.org/html/rfc3230
Dave Longley: Digest: md5=HUXZLQLMuI/KZ5KDcJPcOA==
Dave Longley: Digest:
   SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5=,unixsum=30637
Manu Sporny:  Bring it up since you could put sig/hash in trailer
Mark Cavage:  Right way to do this is checksum the body and sign
   the checksum.
Dave Longley:  Replace Content-MD5 with generic Digest header and
   you can set algorithm and params
Manu Sporny:  We will need some form of Digest
Mark Cavage:  No problem using some other method vs Content-MD5
Manu Sporny:  Want to use trailers?
Mark Cavage:  May need to buffer contents to do this, should spec
   it out.
Manu Sporny:  Do we do one signature for the headers, then
   another one for the trailer (with just the Digest?)
Dave Longley:  We would want one signature for the headers, then
   another one in the trailer that includes all the header signature
   fields. That would be the most secure way of doing it.

Topic: Amr Fahmy and Summer of Code

Manu Sporny:  Get an idea of what Amr will work on. Amr: Give a
   quick intro and what you need.
Amr Fahmy:  Computer science student in Egypt, want to work on
   mobile PaySwarm APIs. Very excited to be a part of this work.
Amr Fahmy:  started with web keys, finishing registration process
Amr Fahmy:  Currently stuck on issue with getting registration to
   work on different systems.
Manu Sporny:  Might be browser, IP, cache, CORS, or similar.
Manu Sporny:  We'll debug this after the call.
Manu Sporny:  Planning to work on this to get web keys
   registration done, then publish asset and listing for sale?
Amr Fahmy:  correct
Manu Sporny:  Any trouble looking at javascript code?
Amr Fahmy:  Mozilla PaySwarm tutorials were enough to get it
   working.
Amr Fahmy:  Do you need web api done before mobile api?
Manu Sporny:  Probably should get python api working and build on
   top of that knowledge for the mobile API.
Manu Sporny:  Thanks for showing interest and let us know how we
   can help!

Topic: Active Attacks - Message Insertion

Manu Sporny:  Back to HTTP Signatures
Manu Sporny: http://tools.ietf.org/html/rfc3552#section-3.3.2
Manu Sporny:  Message insertion has to do with forging a message
   and inserting it in the network.
Manu Sporny:  difficult to do when digital signatures are used.
Mark Cavage:  For https this is covered by TLS. For http you
   should be advised to sign everything.
Manu Sporny:  There's attack over https with comprimised
   certificate with MITM attack. For a monetary transfer the MITM
   could fake a rejection, trick victim to send request again, MITM
   queues up requests and sends them later.
Manu Sporny:  Attacker could just replay messages, not forge
   them.
Mark Cavage:  Basically issue of what to do when TLS channel not
   trusted.
Mark Cavage:  If you just sign Date header then attacker could do
   anything in this case.
Brent Shambaugh: neurons firing: mitm ... Ettercap ...
   http://linux.die.net/man/8/ettercap
Manu Sporny:  This is really an issue at the application layer,
   but we do want to warn people about that possibility.
Dave Longley:  Yeah, you could solve this by having a
   challenge-response, or encrypting information in the channel as
   well as signing.
Mark Cavage:  Might need another side channel, like an additional
   key different from HTTPS.
Manu Sporny:  Could add other headers that are not signed.
   Applications should only trust signed headers.
Dave Longley:  Might need to authorize responses too.
Dave Longley:  We have no security authorization on responses.
   Not sure if Authorization header is allowed in responses.
Manu Sporny:  If doing this over HTTP use nonces and do digital
   signatures on response, good low-cost way to implement something
   that 'works'
Manu Sporny:  This devolves into implementing TLS over HTTP.
Mark Cavage:  You could copy semantics for response and make it
   optional depending if it's needed.
Mark Cavage:  Way to look at this is if you're not using TLS then
   you're off the rails.
Dave Longley:  Need to spec out something so if you can use HTTP
   - it needs to work.
Brent Shambaugh:  Mentioning ettercap when hearing of MITM
Manu Sporny:  Might be good to use for auding

Topic: Active Attacks - Message Deletion / Modification

Manu Sporny: http://tools.ietf.org/html/rfc3552#section-3.3.3
Manu Sporny:  Message insertion, modification, deletion fall
   under same category. Usually why sequence numbers are used, to
   make deletion difficult.
Mark Cavage:  This heads towards IPSec / TLS over http.
Mark Cavage:  All related to MITM. Any of these things possible
   in the case where HTTPS/Certificate Authorities are broken.
Mark Cavage:  If you are MITM you can completely modify messages,
   hard to stop deletion in this spec.
Manu Sporny:  Deletion possible, modifiction difficult.
Mark Cavage:  If you sign everything you are covered on
   modification.
Dave Longley:  attacking identity vs message itself
Mark Cavage:  As long as you sign everything, you would need to
   break RSA to break the stream.
Dave Longley:  This is the same thing as attacking RSA for
   message inseration, deletion, and modification.
Mark Cavage:  This spec seems more aimed towards IP instead
   application level.
Dave Longley:  Need to mention all these issues in a MITM
   section.
Dave Longley:  Modification is going to fall under breaking RSA.
Dave Longley:  Anything not signed you could change since there's
   no protection.
Manu Sporny:  No state tracking. Could attack state of server,
   harder to attack client state.
Manu Sporny:  No traditional security handshaking, just a signed
   message.
Manu Sporny:  May be attacks at application level but not http
   signatures level.
Dave Longley:  Might want to define a message as anything signed
   according to the spec. Anything that is a message is protected
   and the security considerations become the same ones for RSA (in
   that, you have to break RSA).
Dave Longley:  Anything not considered a message is vulnerable to
   attack.

Topic: Active Attacks - Man-In-The-Middle

Manu Sporny: http://tools.ietf.org/html/rfc3552#section-3.3.5
Manu Sporny:  HTTP can always have MITM attack, sign the stuff
   you don't want modified. You can still have deletion issues. Any
   headers that aren't signed should be assumed to have been
   modified.
Manu Sporny:  This is basically a re-cap of what we discussed.
   HTTP is wide open to MiTM. HTTP Signatures used with HTTP
   protects the information that is signed from
   insertion/modification, but not deletion. HTTPS protects against
   all of these attacks, unless HTTPS is broken. In the event that
   HTTPS is broken, the security is no better than HTTP with HTTP
   Signatures (which is better than just plain 'ol HTTP).

Topic: On-path / Off-path Attacks / Link-Local

Manu Sporny:  On-path attacks are basically everything that we've
   covered to this point. Somebody inbetween has tampered with the
   message. Off-path is done a bit lower in the networking stack,
   TCP/IP layer. HTTP Signatures really don't care about the network
   topology, they just care about sender/receiver and protecting the
   data that is signed.
Dave Longley:  Our messages are protected by RSA. To break HTTP
   Signatures, you have to break RSA.
Dave Longley:  origins don't matter for our messages
Manu Sporny:  Anything else for on-path, off-path, link-local?

Topic: Next Steps

Manu Sporny:  What's the next step?
Manu Sporny:  Can do STRIDE analysis on spec? Is that useful or
   do we have enough of an audit to put spec up for public review?
Mark Cavage:  We're going to add more verbage and prose but basic
   spec hasn't changed.
Mark Cavage:  Add nonces, trailer support. Is STRIDE going to add
   anything? Probably thinking along those lines anyway.
Manu Sporny:  Can only do so much here, good to point people to
   security review.
Manu Sporny:  Goal next week for nonces, server signatures, and
   so on. Then put it up for review to see what other people say.
Mark Cavage:  Should we split work up?
Manu Sporny:  I started security consideration section, can work
   on it today, mcavage can you work on nonces, ...
Mark Cavage:  Will try to work on it this week.
Manu Sporny:  We'll have another telecon next week to talk about
   nonces and server signatures or pick up mozpay navigator api.
Manu Sporny:  Thanks!

-- 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, 12 June 2013 18:44:24 UTC