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
  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 Log
David I. Lehn is scribing.
Manu Sporny: Any updates to agenda?

Topic: Security Considerations for HTTP Signatures

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

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!

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