Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Wed, Nov 21, 2018 at 01:53:09PM +0000, Sara Dickinson wrote:
> 
> 
> > Begin forwarded message:
> > 
> > From: Benjamin Kaduk <[e-mail] <mailto:[e-mail]>>
> > Subject: Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)
> > Date: 19 November 2018 at 00:28:19 GMT
> > To: "The IESG" <[e-mail] <mailto:[e-mail]>>
> > Cc: [e-mail] <mailto:[e-mail]>, Tim Wicinski <[e-mail] <mailto:[e-mail]>>, [e-mail] <mailto:[e-mail]>, [e-mail] <mailto:[e-mail]>, [e-mail] <mailto:[e-mail]>
> > Resent-From: <[e-mail] <mailto:[e-mail]>>
> > Resent-To: [e-mail] <mailto:[e-mail]>, [e-mail] <mailto:[e-mail]>, [e-mail] <mailto:[e-mail]>, [e-mail] <mailto:[e-mail]>, [e-mail] <mailto:[e-mail]>
> 
> Many thanks for the detailed review. 
> 
> > 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> > 
> > It is pretty shocking to not see any discussion of the privacy
> > considerations of storing data including client addresses (and ports)
> > alongside DNS transactions, given how central DNS resolution is to user
> > behavior on the web.  (Note that there are mentions of potentially
> > anonymized data in Sections 6.2 and 6.2.3 which would presumably
> > forward-reference the privacy considerations.)  Data normalization would
> > probably also be mentioned in this section, since (e.g.) the case used for
> > a query/response could be used in fingerprinting an implementation.
> 
> There have been extensive discussion of data storage risks and practices in two DPRIVE documents so I’d suggest the following changes in the first instance to address this:

This is exactly the sort of thing I was hoping to see, thank you!  I have
just a couple tweaks to suggest, inline.

> New Privacy Considerations section:
> “ Storage of DNS traffic by operators in PCAP and other formats is a long standing and widespread practice. Section 2.5 of draft-bortzmeyer-dprive-rfc7626-bis is an analysis of the risks to Internet users of the storage of DNS traffic data in servers (recursive resolvers, authoritative and rogue server). 
> 
> Section 5.2 of draft-dickinson-dprive-bcp-op describes mitigations for those risks for data stored on recursive resolvers (but which could by extension apply to authoritative servers). These include data handling practices and methods for data minimisation, IP address pseudonymization and anonymization. Appendix B of that document presents an analysis of 7 published anonymization processes. In addition RSSAC have recently published RSSAC04: " Recommendations on Anonymization Processes for Source IP Addresses Submitted for Future Analysis”[1].
> 
> The above analyses consider full data capture (e.g using PCAP) as a
> baseline for privacy considerations and therefore this format
> specification introduces no new user privacy issues beyond those of full
> data capture. It does provides mechanisms to selectively record only

I would say "beyond those of full data capture (which are quite severe)".
That is, while the current state of affairs is a valid baseline for
comparison, that does not absolve us of responsibility for analyzing the
current state of affairs.  (To be clear,
draft-bortzmeyer-dprive-rfc7626-bis is a fine place for the bulk of that
anlaysis to live, but in this document we should not pretend that the
current state of affairs is a good situation to be in.)

> certain fields at the time of data capture to improve user privacy and to
> explicitly indicate that data is sampled and or anonymised. It also
> provide flags to indicate if data normalisation has been performed; data
> normalisation increases user privacy by reducing the potential for
> fingerprinting individuals however a trade-off is potentially reducing

I think "however" would be offset by commas on both sides.

> the capacity to identify attack traffic via query name signatures.
> Operators should carefully consider their operational requirements and
> privacy policies and SHOULD capture at source the minimum user data
> required to meet their needs“
> 
> [1] https://www.icann.org/en/system/files/files/rssac-040-07aug18-en.pdf <https://www.icann.org/en/system/files/files/rssac-040-07aug18-en.pdf>
> 
> 
> As noted, there are a few other places we can also highlight the privacy aspects:
> 
> Introduction:
> OLD: “The PCAP [pcap] or PCAP-NG [pcapng] formats are typically used in practice for packet captures, but these file formats can contain a great deal of additional  information that is not directly pertinent to DNS traffic analysis  and thus unnecessarily increases the capture file size.”
> 
> NEW: “The PCAP [pcap] or PCAP-NG [pcapng] formats are typically used in practice for packet captures, but these file formats can contain a great deal of additional  information that is not directly pertinent to DNS traffic analysis  and thus unnecessarily increases the capture file size. Additionally these tools and format typically have no filter mechanism to selectively record only certain fields at capture time, requiring post-processing for anonymisation or pseudonymistaion of data to protect user privacy.
> 
> Section 4, bullet point 2:
> 
> OLD: “Different users will have different requirements
>           for data to be available for analysis.  Users with minimal
>           requirements should not have to pay the cost of recording full
>           data, though this will limit the ability to perform certain
>           kinds of data analysis and also to reconstruct packet
>           captures.  For example, omitting the resource records from a
>           Response will reduce the C-DNS file size; in principle
>           responses can be synthesized if there is enough context.”
> 
> NEW: “Different operators will have different requirements
>           for data to be available for analysis.  Operators with minimal
>           requirements should not have to pay the cost of recording full
>           data, though this will limit the ability to perform certain
>           kinds of data analysis and also to reconstruct packet
>           captures.  For example, omitting the resource records from a
>           Response will reduce the C-DNS file size; in principle
>           responses can be synthesized if there is enough context.
>           Operators may have different policies for collecting user data
>           and can choose to omit or anonymise certain fields at
>          capture time e.g. client address."
> 
> And yes, in both sections 6.2 and 6.2.3 add forward references to the Privacy Considerations section
> 
> 
> > 
> > I'm also concerned about the policy/procedure for allocating/extending the
> > various bitfields and similar potential extension points in the data
> > structures.  Section 8 covers the major/minor versioning semantics with
> > respect to new map keys and new maps, but not addition of new bits within
> > existing (uint) bitmaps.  Given the usage of the CDDL .bits constraint,
> > it's not really clear that an IANA registry is the right tool to use, but I
> > think some indication of the expected way to allocate new bits is in order,
> > whether it's "a future standards-track document that updates this document"
> > or otherwise.  (I've noted many, but not all, instances of such bitmaps in
> > my COMMENT section.)
> 
> We are inclined to follow the lead of existing RFCs making use of CBOR, namely
> * RFC8152 'CBOR Object Signing and Encryption' (July 2017)
> * RFC8392 ‘CBOR Web Token (CWT)' (May 2018) and 
> * RFC8428 'Sensor Measurement Lists (SenML)' (Aug 2018) 
> and request IANA create a C-DNS registry with
> subregistries with keys for each of the different maps used in C-DNS.
> New entries in these subregistries would follow Expert Review as defined
> in RFC8126. This appears to be the emerging usual way of dealing with
> CBOR map key values, particularly integer.

That sounds like a fine path forward, thanks.

> > 
> > There are also a couple of fields whose semantics don't seem to be
> > sufficiently well specified for a proposed-standard document, such as
> > vlan-ids, generator-id, name-rdata, and ae-code.  (I understand that some
> > of them are probably only going to have locally relevant semantics, but we
> > should be explicit about when that's the case.)
> 
> Acknowledged, we’ll add references or clarifications for these (will put details in a follow up mail that will also address your comments below).

Sounds good.

> > 
> > If I'm reading things correctly that the IP address type is inferred from
> > the bytestring length, then I think we need to enforce a restriction on the
> > address prefix length(s) to allow for that inference to be unambiguous
> > (noting that we only have the *byte* length of the address fields at our
> > disposal for disabmgituation, and not the more precise bit-length).
> 
> Ah, the first bit of the qr-transport-flags contains a IPv4/IPv6 flag so the address type can be explicitly determined from that if it is set but of course there is a corner case where that field isn’t present we hadn’t considered so we’ll have to address that. Making that field mandatory if prefixes are used would be simplest. 

I guess I had forgotten about that bit in the qr-transport-flags on my
first read.  Making it mandatory if prefix lengths are present ought to
work.

-Benjamin

> 
> > 
> > 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > Section 2
> > 
> > Please consider using the RFC 8174 version of the BCP 14 boilerplate.
> > 
> > Section 3
> > 
> >   Because of these considerations, a major factor in the design of the
> >   format is minimal storage size of the capture files.
> > 
> > maybe "storage and transmission"?
> > 
> > Section 6
> > 
> > In Figure 2, the Query name is marked as "(q)" (only present if there is a
> > query), but the running text in Section 4 (bullet 1) says that the Question
> > section from the response can be used as an identifying QNAME if there is a
> > response with no corresponding query.  Am I misexpanding QNAME here, or is
> > there a disagreement between these two parts of the text?  In particular, I
> > do not see a part of Figure 2 that would correspond to a Question section
> > in the response, given the various "(q)"/"(r)" markings.
> > 
> > Section 6.2.2
> > 
> >   Messages with OPCODES known to the recording application but not
> >   listed in the Storage Parameters are discarded (regardless of whether
> >   they are malformed or not).
> > 
> > (Do we need to say anything that the "discarded" is only w.r.t. the capture
> > process, and not meant to imply that DNS queries would not get a normal
> > response?)
> > 
> > Section 6.2.4
> > 
> > Please consider using IPv6 examples, per
> > https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ <https://www.iab.org/2016/11/07/iab-statement-on-ipv6/> .
> > 
> > Section 7.2
> > 
> >   o  The column T gives the CBOR data type of the item.
> > 
> >      *  U - Unsigned integer
> > 
> >      *  I - Signed integer
> > 
> > This is venturing a bit far from my normal area of expertise, but my
> > understanding is that CBOR native major types are only provided for
> > unsigned integer and negative integer, with "signed integer" being an
> > abstraction at a slightly higher layer that needs to be managed in the
> > application.  Do we need to add any clarifying text here or will the
> > meaning be clear to the reader?
> > 
> > Section 7.4
> > 
> > Should probably forward-reference section 8 for the format version numbers'
> > semantics.
> > 
> > Section 7.4.1.1
> > 
> > We should we reference the IANA registries by name for any of these fields
> > (e.g., opcodes, rr-types, etc.).  (Also in Section 7.5.3.1, etc.)
> > 
> > Are the storage flags going to be allocated in sequence by updating
> > standards-track documents, or some other mechanism?  (Is a registry
> > necessary?)
> > 
> > For the various address prefix fields, do we need to specify that the full
> > addresses are stored when the corresponding prefix field is absent?
> > 
> > Section 7.4.1.1.1
> > 
> > Am I parsing the "query-response-hints" text correctly to say that a bit is
> > set in the bitmap if the corresponding field is recorded (if present) by
> > the collecting implementation?  The causality of "if the field is omitted
> > the bit is unset" goes in a direction that is not what I expected.
> > (Similarly for the other fields in this table.)
> > 
> > Section 7.4.2
> > 
> > Do we need a reference for "promiscuous mode"?
> > 
> > Just to check: in "server-addresses", I just infer the IP version from the
> > length of the byte string?
> > 
> > Do we need to say more about where the vlan-ids identifiers are taken from?
> > 
> > Is the "generator-id" string intended to only be human readable?  Only
> > within a specific (administrative) context?
> > 
> > Section 7.5.1
> > 
> > Does "earliest-time" include leap seconds?
> > 
> > Section 7.5.3
> > 
> > The "ip-address" description seems to imply that very short ipv6 prefix
> > lengths could cause confusion as to the address type being indicated (e.g.,
> > setting to 32 when no ipv4 prefix length is set, or setting to the same
> > value as the ipv4 prefix length).  Do we need to restrict the ipv6 prefix
> > lengths to being 33 or larger?
> > 
> > Are the "name-rdata" contents in wire format or presentation format?
> > 
> > Section 7.5.3.2
> > 
> > What's the allocation policy/procedure for the remaining
> > qr-transport-flags transport values?  For additional bits in any/all of the
> > flags fields listed here?
> > 
> > Something of a side note, what's the mnemonic for the "sig" in
> > "qr-sig-flags"?  That is, what is it a signature of or over (it doesn't
> > seem like it's a cryptographic signature, which may be what is confusing
> > me)?
> > 
> > For "query-rcode"/"response-rcode", should there be a reference for "OPT",
> > and/or for any of the EDNS stuff in here?  (The Terminology section only
> > mentions using the naming from RFC 1035, that I can see.)
> > 
> > The "mm-transport-flags" here bear a striking resemblance to the
> > "qr-transport-flags" from Section 7.5.3.2; should there be a shared
> > registry for their contents?  (I guess the TransportFlags CDDL to some
> > extent serves this function.)
> > 
> > Section 7.7
> > 
> > How is the value of the "ae-code" determined?
> > 
> > Appendix A
> > 
> > We could perhaps apply some constraints on (e.g.) the address-prefex length
> > fields to be .le the relevant lengths.
> > 
> > Appendix C.6
> > 
> >                                           Using a strong compression,
> >   block sizes over 10,000 query/response pairs would seem to offer
> >   limited improvements.
> > 
> > nit: Using a strong compression scheme
> > 
> >