Re: [dbound] DBOUND - updated use cases?

[Ian Williams <[e-mail]>]

In the interest of spawning some discussion, I'll start with my own
reply.

Full disclosure, I work for AWS. We operate a large Internet-connected
service network, for both our direct customers and our customer's
customers. A few of the below use-cases consider the latter of the two,
for AWS customers that may themselves be a SaaS vendor or similar.

-----

1) We have a large number of boundaries we'd need to publish. Taking an
example resource within an example service, that resource might have a
domain name that follows the below pattern (2LD may vary):

   "resource-id.cluster-id.servicename.region-name.amazonaws.com"

With the current PSL, we'd need to publish 1+ records per region per
service. We currently have over 200 services across 27 regions, and
those numbers grow on a regular basis. This puts an immense strain on
the PSL - both on the size of the list itself, and the humans that help
maintain the list for the internet community (Ryan + Jothan + others:
thank you for your continued voluntarism here).

Putting this information into DNS allows us to publish our own records,
without straining a team of volunteers with our bolus of updates.

-----

2) We have suffixes that are public, but not routable or resolvable
outside of our network (public-like-PSL, not public-like-pool). A good
example I have is the internal zone within all AWS virtual private
clouds (VPCs). VPCs are resources customers can create, which reserves
them a logically-isolated portion of AWS's network. Within each VPC,
there is a VPC-internal DNS zone which contains DNS records for
resources within the VPC (suffix zone of "compute.internal" or
equivalent), which is separated per-VPC. Every network interface in a
VPC will have an associated per-interface record in this zone (for VPCs
using a default configuration). More details available here:
https://aws.amazon.com/vpc/

For customers that have chosen to peer their VPC with another customer,
this VPC-internal zone would now have multiple different customers
operating within it. We'd like to prevent any inferred-level of trust
(when it comes to things like cookies/CORS policies) between DNS names
in this zone.

There are other examples where this might apply for us, but they all
fall into this pattern. The current PSL verification process requires
that we attest we own the zone at merge/build time, rather than at
runtime. We do not own "internal" outside of the VPC itself, so this
would fail.

-----

3) We operate a DNS management service used by our customers (Amazon
Route 53). In the auspices of the PSL, this would be considered as
just-another-DNS-service - there are plenty of other DNS management
services in existence, and we're likely all in the same pool here.

-----

4) Registry operators and/or DNS application developers may have a
desire to handle eTLDs/suffixes differently at runtime. This may be to
prevent human error in their service, and/or mitigate abuse or misuse
of their service. AWS is one such entity; we have applications which
currently check the PSL at runtime to prevent inappropriate ownership
claims about high value public suffixes or eTLDs.

-----

5) In Sullivan's 2016 draft [1], the specific use-case regarding HTTP
cookies is one that we care about. We think this is relevant to hosting
providers of customer-content with shared domain suffixes. This is one
of the key things we're currently interested in the PSL for.

---

[1]: draft-sullivan-dbound-problem-statement-02, s.4, ss. 1,
      "HTTP state management cookies"
https://datatracker.ietf.org/doc/html/draft-sullivan-dbound-problem-statement-02#section-4

Regards,

Ian Williams
Sr. Security Engineer
AWS Security