[dnsext] Draft: RRTYPE B - Web Resource Integrity

[James Addison <[e-mail]>]

A. Submission Date: N/A (draft / RFC)

B.1 Submission Type:  [x] New RRTYPE  [ ] Modification to RRTYPE
B.2 Kind of RR:  [x] Data RR  [ ] Meta-RR

C. Contact Information for submitter (will be publicly posted):
   Name: James Addison              Email Address: [e-mail]
   International telephone number: N/A
   Other contact handles: N/A

D. Motivation for the new RRTYPE application.

W3C HTML allows website authors to optionally include Subresource
Integrity[1][2] (SRI) metadata within their markup.  This enables
user-agents such as web browsers to check that the corresponding
content that they fetch matches the content intended by the website
author.

A missing link in the integrity supply chain is the initial page-load:
the user-agent is provided with no integrity expectation about the
HTML page that itself contains the subresource integrity markup
attributes.

The proposal here is to add a DNS B record type, to be used to publish
integrity metadata for the root index URI of a website on a given
domain record.

Because in most cases a web user-agent already performs DNS A and/or
AAAA lookups to retrieve IP address(es) to request a web URI from,
adding a neighbouring RR type to provide integrity metadata may allow
for both human mental models and software code to adapt incrementally,
without significant changes to existing assumptions.

E. Description of the proposed RR type.

The proposed DNS RR type is a DNS 'B' record, intended to contain a
single metadata record in the format described by the W3C Content
Security Policy Level 2's definition of a hash-source[3] .  In brief:
this is an ASCII format that is composed of a prefix that indicates a
known cryptographic hash method, followed by a single hyphen ('-')
character, followed by the base64-encoded hash of the content using
the specified algorithm.

For example, the response to a 'dig' DNS lookup for the domain name
reciperadar.com might include the following:

;; ANSWER SECTION:
reciperadar.com.    3600    IN    A    192.0.2.18
reciperadar.com.    3600    IN    B
sha512-5sY7BUrKX/1p6j6PJECwN+7rX2ORqP/StA2iR7bI9C30aGT6wF4PAEum4mnyrsQNjl/whRZ9luAVANNz9Uqkqg=

The proposed record type does not allow integrity hashes to be
specified for multiple URIs on the domain where it is configured.
Only a single 'B' record may be configured for the domain, and the
integrity hash contained within it is published solely for use
validating content fetched from the root URI path ('/') of that
domain.

A motivating use case is to provide integrity guarantees to
user-agents that fetch and load single-page web applications that are
deployed and distributed using webservers.  Updates to such an
application should be preceded by an update to the DNS B record on
each domain they are distributed from.

F. What existing RRTYPE or RRTYPEs come closest to filling that need
   and why are they unsatisfactory?

The existing A and AAAA record types provide a way for world-wide-web
user-agents to discover the IP address of server(s) to request webpage
content from.  However, these record types do not provide integrity
expectations about the content that may subsequently be communicated
to the client.

G. What mnemonic is requested for the new RRTYPE (optional)?

N/A (guidance requested)

H. Does the requested RRTYPE make use of any existing IANA registry
   or require the creation of a new IANA subregistry in DNS
   Parameters?  If so, please indicate which registry is to be used
   or created.  If a new subregistry is needed, specify the
   allocation policy for it and its initial contents.  Also include
   what the modification procedures will be.

No.

I. Does the proposal require/expect any changes in DNS
   servers/resolvers that prevent the new type from being processed
   as an unknown RRTYPE (see [RFC3597])?

No; existing servers and resolvers should be able to replicate zone
data containing 'B' records without requiring any knowledge of the
semantics of the RRtype; the type describes a textual record providing
a communication channel to carry an integrity guarantee about web
content from the author to clients of that content, using DNS as the
distribution method.

J. Comments:

Although an anticipated use case is delivery of web applications from
a fixed root URI on a domain, websites composed of static content
could also use the ability to communicate integrity expectations to
clients out-of-band from HTTP/HTTPS protocols.

Related specifications:

1. Transport layer security, which provides for in-band content
integrity guarantees within the context of a negotiated communication
session.

2. DNSSEC, which provides security assurances on the content of data
within a DNS zone.

3. The draft specification of HTTP message signatures
(draft-ietf-httpbis-message-signatures), which could provide for
integrity guarantees on portions of content communicated within HTTP
requests and responses.

Each of these are orthogonal to the proposed DNS B RRType -- and to
each other -- and could be used in combination.

[1] - https://www.w3.org/TR/2016/REC-SRI-20160623/

[2] - https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

[3] - https://www.w3.org/TR/CSP2/#hash_source