Re: [dnsext] Draft: RRTYPE B - Web Resource Integrity

[Mark Andrews <[e-mail]>]

This is insufficient to implement.  Only the presentation format
has been described.  The wire format has not been described.  Normally
hashes and binary data are converted between base64 (presentation) and
raw data for the wire format in DNS. See DNSKEY, RRSIG, TSIG, CERT, DOA, HIP,
SINK as this reduces the record size.  Additionally hash identifiers are normally
just an octet preceding the hash with a registry for mappings to well known
values as well as a few user defined values for testing.  Alternatively a
string followed by the raw data.

Below are different potential wire formats of 

sha512-5sY7BUrKX/1p6j6PJECwN+7rX2ORqP/StA2iR7bI9C30aGT6wF4PAEum4mnyrsQNjl/whRZ9luAVANNz9Uqkqg=

Octet

0000000    01  b1  8e  c1  52  b2  97  ff  5a  7a  8f  a3  c9  10  2c  0d
0000020    fb  ba  d7  d8  e4  6a  3f  f4  ad  03  68  91  ed  b2  3d  0b
0000040    7d  1a  19  3e  b0  17  83  c0  12  e9  b8  9a  7c  ab  b1  03
0000060    63         

String

0000000    06  73  68  61  32  35  36  b1  8e  c1  52  b2  97  ff  5a  7a
0000020    8f  a3  c9  10  2c  0d  fb  ba  d7  d8  e4  6a  3f  f4  ad  03
0000040    68  91  ed  b2  3d  0b  7d  1a  19  3e  b0  17  83  c0  12  e9
0000060    b8  9a  7c  ab  b1  03  63

ASCII/UTF8 

0000000    73  68  61  32  35  36  2d  73  59  37  42  55  72  4b  58  2f
0000020    31  70  36  6a  36  50  4a  45  43  77  4e  2b  37  72  58  32
0000040    4f  52  71  50  2f  53  74  41  32  69  52  37  62  49  39  43
0000060    33  30  61  47  54  36  77  46  34  50  41  45  75  6d  34  6d
0000100    6e  79  72  73  51  4e  6a  6c  2f  77  68  52  5a  39  6c  75
0000120    41  56  41  4e  4e  7a  39  55  71  6b  71  67  3d

Mark     

> On 15 Nov 2023, at 04:36, James Addison <[e-mail]> wrote:
> 
> 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
> 
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]