Cryptographic Proofs for HTTP Messages
draft-sporny-http-proofs-00

Abstract

For a client to access a particular resource on the Web, a server must expend a certain amount of computational effort to respond to the request. In some cases this computational effort is sizeable and the server may want to only respond to certain clients. For example, in a distributed denial-of-service attack, a server may require all clients to expend a certain amount of resources via a client-run proof-of-work algorithm to throttle the number of incoming requests to a more manageable number. This document details a few HTTP Headers that may be used to request and transmit cryptographic mathematical proofs in HTTP headers.

Feedback

This specification is a thought exercise that may be submitted on a standardization track in the future. Feedback related to this specification should be sent to msporny@digitalbazaar.com.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on February 27, 2015.

Copyright Notice

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Table of Contents

• 1. Introduction
• 2. The Components of a Proof
• 2.1. Proof Parameters
• 2.1.1. algorithm
• 2.1.2. difficulty
• 2.1.3. problem
• 2.1.4. solution
• 2.2. Ambiguous Parameters
• 3. The 'Proof' HTTP Authentication Scheme
• 3.1. Authorization Header
• 3.1.1. Initiating Proof Authorization
• 3.1.2. Proof Example
• 4. The 'Proof' HTTP Header
• 4.1. Proof Header
• 4.1.1. Proof Header Example
• 5. References
• 5.1. Normative References
• 5.2. Informative References
• Appendix A. Security Considerations
• Appendix B. Extensions
• Appendix C. Test Values
• C.1. Default Test
• Appendix D. Acknowledgements
• Appendix E. IANA Considerations
• E.1. Signature Authentication Scheme
• E.2. Proof Algorithm Registry
• Author's Address

1. Introduction

This protocol extension is intended to provide a simple and standard way for clients and servers to request and transmit mathematical proofs to one another.

For a client to access a particular resource on the Web, a server must expend a certain amount of computational effort to respond to the request. In some cases this computational effort is sizeable and the server may want to only respond to certain clients. For example, in a distributed denial-of-service attack, a server may require all clients to expend a certain amount of resources via a client-run proof-of-work algorithm to throttle the number of incoming requests to a more manageable number.

Editor's note: Explain why proofs of work are interesting for HTTP. Specifically, when you have a public resource where you don't want to authenticate users, but you do want to be able to throttle requests. For example, proxies, URL redirection services, and CDNs could benefit from these sorts of services to mitigate distributed denial-of-service attacks. Systems where all clients slam a particular endpoint, like high-frequency trading systems, could use such a mechanism to purposefully slow incoming requests. Block-chain-like systems could use this mechanism as a native way to access shared databases (like a decentralized ledger). There may be more uses, but those are the ones that inspired this specification.

2. The Components of a Proof

There are a number of components in a proof that are common between the 'Proof' HTTP Authentication Scheme and the 'Proof' HTTP Header. This section details the components of a HTTP Proof.

2.1. Proof Parameters

The following section details the proof parameters.

2.1.1. algorithm

REQUIRED. The `algorithm` field specifies the specific mathematical proof algorithm that is employed by the rest of the parameters. The value of this field SHOULD be a registered algorithm as defined in the Proof Algorithm Registry.

2.1.2. difficulty

REQUIRED. The `difficulty` field denotes the level of difficulty that is associated with the `algorithm` field. The value of the field is highly dependent on the algorithm listed in the Proof Algorithm Registry.

2.1.3. problem

OPTIONAL. The `problem` value is used by the server to specify the problem to solve. It is typically used to initialize the proof algorithm.

2.1.4. solution

OPTIONAL. The `answer` value is used by the client to specify the answer to the problem posed to it by the server. This field is typically used when sending a calculated answer to the server.

2.2. Ambiguous Parameters

If any of the parameters listed above are erroneously duplicated in the associated header field, then the last parameter defined MUST be used. Any parameter that is not recognized as a parameter, or is not well-formed, MUST be ignored.

3. The 'Proof' HTTP Authentication Scheme

The "proof" authentication scheme is based on the model that the client must authenticate itself with a mathematical proof that answers the question posed by the server. The scheme is parameterized enough such that it is not bound to any particular proofing algorithm.

3.1. Authorization Header

The client is expected to send an Authorization header (as defined in RFC 7235 [RFC7235], Section 4.1) where the "auth-scheme" is "Proof" and the "auth-param" parameters meet the requirements listed in Section 2: The Components of a Proof.

POST /foo HTTP/1.1
Host: example.org
Date: Tue, 07 Aug 2014 20:51:35 GMT
Content-Type: application/json
Content-Length: 18

{"hello": "world"}
     

The rest if this section uses the following HTTP request as an example.

3.1.1. Initiating Proof Authorization

HTTP/1.1 401 Unauthorized
Date: Thu, 08 Jun 2014 18:32:30 GMT
Content-Length: 1234
Content-Type: text/html
WWW-Authenticate: Proof realm="Example",
  algorithm="scrypt",difficulty="1068",problem="0f43ba8b21"

...

A server may notify a client when a protected resource could be accessed by authenticating itself to the server. To initiate this process, the server will request that the client authenticate itself via a 401 response code. The server may optionally specify which type of proof, difficulty, and problem it would like to have solved in the WWW-Authenticate header. For example:

3.1.2. Proof Example

Authorization: Proof realm="Example",algorithm="scrypt",difficulty="1068",
  problem="0f43ba8b21",solution="00000000b28fcd2"

The authorization header and proof would be generated as:

4. The 'Proof' HTTP Header

The "proof" HTTP Header is based on the model that the client must authenticate itself with a mathematical proof that answers a question that is commonly known to the client and the server. The scheme is parameterized enough such that it is not bound to any particular proofing algorithm.

4.1. Proof Header

The sender is expected to transmit a header (as defined in RFC 7230 [RFC7230], Section 3.2) where the "field-name" is "Proof", and the "field-value" contains one or more "auth-param"s (as defined in RFC 7235 [RFC7235], Section 4.1) where the "auth-param" parameters meet the requirements listed in Section 2: The Components of a Proof.

POST /foo HTTP/1.1
Host: example.org
Date: Tue, 07 Aug 2014 20:51:35 GMT
Content-Type: application/json
Content-Length: 18

{"hello": "world"}

The rest if this section uses the following HTTP request as an example.

4.1.1. Proof Header Example

Proof: algorithm="scrypt",difficulty="1068",
  problem="0f43ba8b21",solution="00000000b28fcd2"

The proof header would be generated as:

5. References

5.1. Normative References

5.2. Informative References

Appendix A. Security Considerations

Editor's note: Clearly there are a number of concerning reverse denial of service attacks that could be executed over non-HTTPS connections. A simple header injection could keep a client spinning for a very long time. Much more thinking needs to be put into this section.

Appendix B. Extensions

This specification was designed to be simple, modular, and extensible. Developers that desire more functionality than this specification provides are urged to ensure that an extension specification doesn't already exist before implementing a proprietary extension.

Proof Parameter: iterations
Reference to specification: [SOME_ALGORITHM], Section XYZ.
Notes (optional): The `iterations` parameter is used to specify the number
of iterations to run on the mathematical proof algorithm.
    

If extensions to this specification are made by adding new Proof Parameters, those extension parameters MUST be registered in the Proof Parameter Registry. The registry will be created and maintained at (the suggested URI) http://www.iana.org/assignments/http-proof-parameters. An example entry in this registry is included below:

Appendix C. Test Values

Editor's note: Some scrypt parameters. 
    

Editor's note: This section should include some scrypt calculation stuff.

POST /foo?param=value&pet=dog HTTP/1.1
Host: example.com
Date: Thu, 05 Jan 2014 21:31:40 GMT
Content-Type: application/json
Content-Length: 18

{"hello": "world"}
    

All examples use this request:

C.1. Default Test

Editor's Note: A simple scrypt-based proof of work.

Appendix D. Acknowledgements

The editor would like to thank the following individuals for feedback on and implementations of the specification (in alphabetical order): None yet.

Appendix E. IANA Considerations

E.1. Signature Authentication Scheme

The following entry should be added to the Authentication Scheme Registry located at http://www.iana.org/assignments/http-authschemes

Authentication Scheme Name: Proof
Reference: [RFC_THIS_DOCUMENT], Section 2.
Notes (optional): The Proof scheme is designed for clients to authenticate themselves with a server by performing a mathematical proof.

E.2. Proof Algorithm Registry

The following initial entries should be added to the Proof Algorithm Registry to be created and maintained at (the suggested URI) http://www.iana.org/assignments/proof-algorithms:

Algorithm Name: scrypt
Reference: [SCRYPT_RFC_WHEN_IT_EXISTS] Status: active

Author's Address