Last Call Review of draft-ietf-intarea-provisioning-domains-04
review-ietf-intarea-provisioning-domains-04-secdir-lc-hallam-baker-2019-05-23-00

This draft gives some long overdue attention to an issue that has become
increasingly problematic in real world contexts. Since this is an early review,
I am focusing on the types of issues that need to be addressed during
development.

One issue that had me somewhat confused at first is the initial sentence. "An
increasing number of hosts access the Internet via multiple interfaces".
Reading the draft, there appears to be an implicit assumption that the access
is sequential (mobile device going from one coffee shop to another) even though
the referenced document is very much focused on parallel.

It would be helpful if there was some grounding context early on in the
document to provide this context, something like:

If Alice has a mobile phone provider and a broadband provider in her home, her
devices should be capable of seamlessly transitioning from one to the other. So
that if the broadband fails, the Internet service can gracefully failover to
the mobile and vice versa for upgrades. This draft isn't going to solve that
problem but providing the basic information necessary to make this choice
intelligently is going to be crucial to any solution. There are similar
concerns for IPSEC VPN.

This particular proposal is situated at a very low level in the stack but is
making use of application level protocols to achieve its effect. I think this
is a perfectly valid approach but does mean that the issue of recursive
dependencies have to be considered and in particular in the security
considerations.

At present, the draft is structured to describe an IP packet format and then
the data that can be accessed. I suggest reversing these and presenting the PvD
schema first and then the IP packet as one choice of binding, we are likely to
want to add more. If I am provisioning an IPSEC VPN configuration to a client,
it would be logical to either include the PvD in the IPSEC connection
description or vice versa. This is particularly the case if we end up signing
the data (see later).

Turning to the security concerns, it is usually helpful to consider these in
terms of Confidentiality, Integrity and Availability and the network layer at
which the protocol operates.

In this case, the proposal appears to be link layer since it is providing
information to a host connecting to a network. But the information provided
includes (potentially) DNS services and so it is going to affect the whole
stack from the link up to the application layer.

Since this is link layer, there is a certain degree of implicit integrity
achieved because the host has either a direct physical connection or at least
proximity to the network. It is probably prudent to distinguish the cases of
hosts connecting wirelessly and physically since a physical connection provides
a higher degree of implicit integrity than wireless.

Taking the most important consideration first, what is the potential for
(ab)using this approach to perform a service attack? Here we should consider
the possibility of an attack on the host itself and the use of the mechanism to
relay attacks onto other hosts.

I have not thought of any attacks of this type yet but this is the area that
gives me the most concern.

Integrity presents two considerations, first there is the question of whether
the data has been modified, the second is where it came from in the first
place. The use of TLS does not necessarily provide a strong binding to the
domain. At the very least, data would have to be retrieved from a URL in some
portion of the address space that is reserved for administrative use. While
.well-known is often used for this purpose, it is not always valid. Another
issue with TLS is that we start off with a fairly strong implicit integrity
from the link and discard that for a repudiable authentication via TLS. I would
prefer to keep both if we can.

Rather than relying on TLS, a shorter distance between the two points would be
to sign the PvD specification with JOSE. This need not be too onerous. A client
that wants to rely on just the TLS integrity can simply Base64 decode and trust
the data as being implicitly authentic because of the  means of retrieval.

The bigger payoff from signing the PvD is that we no longer need to worry about
how it is retrieved. The killer app for DNSSEC is turning out to be the ability
to divorce DNS data from DNS transport. There are certain situations in which
the fact that the PvD is delivered over a particular link is significant but
there are other situations in which it might not.

For example, I have 12 smoke alarms in my ceilings, one of which I can only
(safely) reach by erecting scaffolding. These smoke alarms are all connected to
a WiFi router that failed and the only option the manufacturer (which I won't
name but rhymes with sproogle) gives for updating the SSID is to reconfigure
each one in turn. It would be really nice if I could program multiple SSIDs
into the devices to provide failover. Contrawise, this capability could be
extended to facilitate the initial connection of the devices to my network.
While this is not a feature the WG is likely interested in right now, it is one
that I am working on for the Mathematical Mesh and it is obviously a good idea
if we have as much commonality between the top down and bottom up configs.

Confidentiality is not generally a direct concern at the link layer but
corruption of the data (i.e. an integrity attack) might allow a disclosure
breach. But this should be stated explicitly.

Finally, as a gen-art issue, the use of x-options is generally deprecated as it
at best ends up with a situation where every client has to accept headers in
both the prefixed and unprefixed form. An IANA registry with first-come,
first-served registration fulfills the goal of preventing accidental collisions
more effectively.