Re: [Int-area] Benjamin Kaduk's Discuss on draft-ietf-intarea-provisioning-domains-10: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Tommy,

Also inline.

On Wed, Jan 22, 2020 at 12:42:59PM -0800, Tommy Pauly wrote:
> Hi Ben,
> 
> Thanks very much for your thorough review!
> 
> I've pushed changes to address these comments. I'm keeping pending changes available here, to be published after the telechat: https://github.com/IPv6-mPvD/mpvd-ietf-drafts/pull/25 <https://github.com/IPv6-mPvD/mpvd-ietf-drafts/pull/25>
> 
> Responses inline.
> 
> Best,
> Tommy
> 
> > On Jan 21, 2020, at 4:21 PM, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> > 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> > 
> > Alexey basically already noted this in his Comment, but I'll elevate it
> > to a Discuss: the usage of TLS for retrieving PvD Additional Information
> > is not really completely specified -- generally in this sort of case
> > where there's a (provisioning) domain name to authenticate we'd expect
> > to require that the server present a certificate with DNS-ID [RFC6125]
> > that matches the expected name.  We could also cite RFC 7525 for TLS
> > best practices and/or make a TLS version recommendation (i.e., 1.3).
> > 
> > There seems to be a missing step in the binding of the PvD ID to the
> > actual usage, or rather, we are making stronger statements about
> > authenticity than the technology seems to justify.  While we can verify
> > that the TLS certificate used to access the additional information
> > matches with the PvD ID provided, there doesn't seem to be a step to
> > validate that the PvD ID in question is applicable for the current
> > network environment.  The prefix match helps some, but (to first order)
> > only for globally-routable prefixes in the absence of NAT.  Malicious
> > routers (e.g., coffeeshop wifi) can fairly easily implement NAT66 and
> > circumvent host-side countermeasures; tunneling traffic through to a
> > compromised host actually in the target PvD would allow circumvention of
> > the TLS-server-side countermeasures.  I have some suggested rewordings
> > in the Comment section that should bring the claims in line with what is
> > actually provided.
> 
> I've moved the following up into Section 4.1 (Retrieving the PvD Additional Information):
> 
> Recommendations for how to use TLS securely can be found in {{!RFC7525}}.
> 
> When a host retrieves the PvD Additional Information, it MUST
> verify that the TLS server certificate is valid for the performed
> request; specifically, that a DNS-ID {{?RFC6125}} on the certificate is equal to
> the PvD ID expressed as an FQDN. This validation indicates that the
> owner of the FQDN authorizes its use with the prefix advertised by the router.
> If this validation fails, hosts MUST close the connection and treat the PvD
> as if it has no Additional Information.

This looks good.  I think that the other changes elsewhere serve to close
up the too-strong claims about the RA being authorized to use a PvD, but
will probably have to read the whole text in context to be sure.

> > 
> > (As something of a side note, it seems that the JOSE/signature scheme
> > discussed in the secdir review thread, that does have a tighter binding
> > to the local network with the PvD, could defeat the caching attack
> > discussed there by having the host supply a nonce in the RS and
> > including that in the signed response, but that requires a lot of
> > expensive signatures and has some challenging key-management problems.
> > So it doesn't seem worth pursuing, even though it's attractive to make
> > more use of the network locality.)
> 
> Yes, this is an interesting direction, but I think it's out of scope of our document here due to the extra load of key management, etc. It's certainly worth pursuing an extension to make things more secure!
> 
> > 
> > The IANA Considerations for PvD Option Flags indicates that bits 0 to 15
> > are managed by IANA, but I think there are only 12 bits available due to
> > the 4-bit Delay field.
> 
> Good catch. I've updated this to indicate that only 12 bits are available.
> > 
> > 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > Section 3.1
> > 
> > Do we want to give any guidance about what to put for the Sequence
> > Number (and/or Delay) when the H-bit is not set?  IIUC they are only
> > relevant for the fetching of additional data.
> 
> Added the following:
> 
> Delay:
> : (4 bits) Unsigned integer used to
> delay HTTP GET queries from hosts by a randomized backoff (see
> {{retr}}). If the H-flag is not set, senders SHOULD set the delay to zero,
> and receivers SHOULD ignore the value.
> 
> Sequence Number:
> : (16 bits) Sequence number for the
> PvD Additional Information, as described in {{data}}. If the H-flag is not
> set, senders SHOULD set the Sequence Number to zero, and receivers
> SHOULD ignore the value.

Thanks.

> 
> > 
> >   R-flag:  (1 bit) 'Router Advertisement' flag stating whether the PvD
> >      Option is followed (right after padding to the next 64 bits
> >      boundary) by a Router Advertisement message header (see section
> >      4.2 of [RFC4861]).  The usage of the inner message header is
> >      described in Section 3.4.
> > 
> > nit(?): I'd be wary of saying "PvD option is followed", since IIUC the
> > inner RA header and subsequent options are still part of "the PvD
> > option".
> 
> Changed this to "the PvD Option header is followed"

Ah, that is good and brings this text in line with the rest of the document
(which I guess I didn't notice until after I had already written this
comment, or I would have suggested it myself).

> > Section 3.2
> > 
> >   In order to provide multiple different PvDs, a router MUST send
> >   multiple RAs.  If more than one different Implicit PvD is advertised,
> >   the RAs MUST be sent from different link-local source addresses.
> > 
> > This seems to imply that implicit PvDs can be advertised via the PvD RA,
> > but the only contents specified for the "PvD ID FQDN" field thereof is a
> > DNS-format FQDN, and we don't say how to construct one of those for an
> > implicit PvD.  I think the intent is just to say that "RAs sent from
> > different link-local source addresses establish distinct implicit PvDs,
> > in the absence of a PvD Option".
> 
> The paragraph now reads:
> 
> In order to provide multiple different PvDs, a router MUST send
> multiple RAs. RAs sent from different link-local source addresses
> establish distinct implicit PvDs, in the absence of a PvD Option. Explicit
> PvDs MAY share link-local source addresses with an Implicit PvD
> and any number of other Explicit PvDs.

Very nice; thank you!

> > Section 3.4
> > 
> >   received RA otherwise.  If an RA message header is present both
> >   within the PvD Option and outside it, as indicated by the R-flag, the
> >   header within the PvD Option takes precedence.
> > 
> > Why is the R-flag relevant?
> 
> It was referring to when the message header is present in the PvD Option, but I see how it is hard to read. Removed that clause.

I think I had misread this at first (confusing the "RA message header" with
generic "RA options"), and was complaining that the "inner" RA options take
precedence regardless of whether there's an inner RA header (and thus, the
value of the R-bit).  But this is actually talking about the RA message
header itself, so such a complaint is not valid.
(I think this text would probably be fine with or without mention of the
R-flag.)

> > 
> >   Similarly, hosts MUST associate all network configuration objects
> >   (e.g., default routers, addresses, more specific routes, DNS
> >   Recursive Resolvers) with the PvD associated with the RA which last
> >   updated the object.  For example, addresses that are generated using
> >   a received Prefix Information option (PIO) are associated with the
> >   PvD of the last received RA which included the given PIO.
> > 
> > I'm not sure I'm parsing the first sentence as intended.  For any given
> > configuration object, there will be an RA which has most-recently
> > updated that object ("last updated the object"); that RA has some
> > associated PvD, whether via explicit PvD ID option or assignment of
> > implicit PvD.  It sounds like this is telling me to associate the object
> > with the aforementioned PvD, so that "last PvD wins" for any given
> > object, but this seems at odds with the idea of having multiple PvDs
> > active at once, with separate configurations.  So I'm not sure that
> > the "last updated" phrasing is giving the right impression.
> 
> I see your point. Changed to:
> 
> Similarly, hosts MUST associate all network configuration objects
> (e.g., default routers, addresses, more specific routes, DNS Recursive
> Resolvers) with the PvD associated with the RA that provisioned the
> object. 
> > 
> >   While resolving names, executing the default address selection
> >   algorithm [RFC6724] or executing the default router selection
> >   algorithm when forwarding packets ([RFC4861], [RFC4191] and
> > 
> > Is this an exhaustive list?
> 
> Changed this to:
> 
> While performing PvD-specific operations such as resolving names,
> executing the default address selection algorithm {{!RFC6724}} or executing
> the default router selection algorithm when forwarding packets...
> > 
> >   [RFC8028]), hosts and applications MAY consider only the
> >   configuration associated with any non-empty subset of PvDs.
> > 
> >   For example, a host MAY associate a given process with a specific
> >   [...]
> > 
> > nit: maybe these should not be separate paragraphs?
> 
> Fair point. Merged them!
> > 
> > Section 3.4.1
> > 
> >   When a host retrieves stateful assignments using DHCPv6, such
> >   assignments MUST be associated with the received PvD which was
> >   received with RAs with the M-flag set and including a matching PIO.
> > 
> > Is there a reason to use different language here than the previous
> > paragraph (which was "all the explicit and implicit PvDs received on the
> > same interface and [stuff about the RA]")?
> 
> Yes, this is intentionally worded differently (based on much discussion in the WG). We'd like to leave this as-is.

Okay, I just wasn't sure if it was intentionally different or not.

> >   In cases where an address would be assigned by DHCPv6 and no matching
> >   PvD could be found, hosts MAY associate the assigned address with any
> >   implicit PvD received on the same interface or to multiple of
> >   implicit PvD received on the same interface.  This is intended to
> >   resolve backward compatibility issues with rare deployments choosing
> >   to assign addresses with DHCPv6 while not sending any matching PIO.
> > 
> > Wouldn't backwards compatibility be better if we specified "all implicit
> > PvD on the same interface" rather than leaving things in a
> > nondeterministic state?
> 
> Again, this is something that we discussed as a group a lot. It is intentionally left open to the host implementation.

Sure, this is just a nonblocking comment and I don't have grounds to
override the WG decision.

> > 
> > Section 3.4.2
> > 
> >   When a PvD-aware host retrieves configuration elements from DHCPv4,
> >   the information is associated either with a single Explicit PvD on
> >   that interface, or else with all Implicit PvDs on the same interface.
> > 
> > This is further specified in the following two paragraphs, right?  So
> > maybe "as detailed below" would help the reader.
> 
> I'd like to leave this as is, since the directly following paragraphs do elaborate the point. I feel that "as detailed below" makes it seem like the "below" is further than the next sentence.

Okay.  (I am somewhat prone to commenting on a given sentence about things
that are clarified shortly thereafter...)

> > 
> > Section 3.4.4
> > 
> >   PvD-aware hosts can be provisioned with recursive DNS servers via RA
> >   options passed within an Explicit PvD, via RA options associated with
> >   an Implicit PvD, via DHCPv6 or DHCPv4, or from some other
> >   provisioning mechanism that creates an Implicit PvD (such as a VPN).
> > 
> > nit: didn't we say that IPsec VPNs were explicit PvDs?  If so, they will
> > not be provisioning recursive DNS servers via RA options, and thus are
> > not covered by any of the items in this listing.
> 
> Indeed, good catch! It really should be:
> 
> or from some other
>   provisioning mechanism that creates an Explicit PvD (such as a VPN).

Ah; that makes more sense!

> >   In all of these cases, the recursive DNS server addresses SHOULD be
> >   associated with the corresponding PvD.  Specifically, queries sent to
> >   a configured recursive DNS server SHOULD be sent from a local IP
> >   address that was provisioned by the PvD via RA or DHCP.  Answers
> > 
> > nit: are they provisioned "by" the PvD" or "with"/"for" the PvD?
> 
> Changed to "for"
> > 
> >   PvD-aware applications will be able to select which PvD(s) to use for
> >   DNS resolution and connections, which allows them to effectively use
> >   multiple Explicit PvDs.  In order to support non-PvD-aware
> >   applications, however, PvD-aware hosts SHOULD ensure that non-PvD-
> >   aware name resolution APIs like "getaddrinfo" only use resolvers from
> >   a single PvD for each query.  Handling DNS across PvDs is discussed
> > 
> > just to check: this SHOULD is only at a per-API-call level, and
> > subsequent calls to getaddrinfo (even with the same arguments) are
> > permitted to use results from different PvDs?  I would have naievly
> > expected that the "default PvD" used for such non-PvD-aware applications
> > would be relatively stable over time...
> 
> Yes this is per-call. I clarified by saying:
> 
> ...use resolvers from a single PvD for a given query.

Okay, thanks.  (It is surprising to me, but all that is needed is to be
clear; there are many things about which I'm not an expert.)

> > Section 4
> > 
> >   This JSON object is restricted to the restricted profile of I-JSON,
> >   as defined in [RFC7493].
> > 
> > nit: I-JSON is a restricted profile of JSON, but does not itself has a
> > "restricted profile" subset, so I'd suggest just "is restricted to the
> > I-JSON profile".
> 
> Good call. Fixed!
> > 
> > Section 4.1
> > 
> >   Note that the DNS name resolution of the PvD ID, the PKI (Public Key
> >   Infrastructure) checks as well as the actual query MUST be performed
> >   using the considered PvD.  In other words, the name resolution, PKI
> > 
> > nit(?): I am not sure if these "PKI checks" are supposed to be DNSSEC or
> > the TLS validation.  I don't think we previously discussed having
> > separate per-PvD TLS trust anchors, which mostly leads me to assume
> > DNSSEC PKI, but greater clarity in the document would be welcome.
> 
> Changed to:
> 
> Note that the DNS name resolution of the PvD ID, any connections made
> for certficate validation (such as OCSP {{?RFC6960}}), and
> the HTTP request itself MUST be performed using the considered PvD.

Ah, that helps me; thanks!

> >   If the HTTP status of the answer is greater than or equal to 400 the
> >   host MUST abandon and consider that there is no additional PvD
> >   information.  If the HTTP status of the answer is between 300 and
> > 
> > nit: "abandon" is a transitive verb and requires an object.
> 
> Changed to:
> 
> If the HTTP status of the answer is greater than or equal to 400
> the host MUST close its connection...
> > 
> >   399, inclusive, it MUST follow the redirection(s).  If the HTTP
> >   status of the answer is between 200 and 299, inclusive, the host MAY
> >   get a file containing a single JSON object.
> > 
> > Is redirect-chasing recursive or one-time?
> > I agree with Alissa that this "MAY" is not normatiave.
> 
> Fixed with Alissa's feedback:
> 
> If the HTTP status of
> the answer is between 200 and 299, inclusive, the response is expected to
> be a single JSON object.

Great!  (What's the answer to the redirect-chasing question, though?)

> >   After retrieval of the PvD Additional Information, hosts MUST
> >   remember the last Sequence Number value received in the RA including
> >   the same PvD ID.  Whenever a new RA for the same PvD is received with
> > 
> > nit: s/the RA/an RA/
> 
> Fixed!
> > 
> >   a different Sequence Number value, or whenever the expiry date for
> >   the additional information is reached, hosts MUST deprecate the
> >   additional information and stop using it until a new JSON object is
> >   retrieved.
> > 
> > Is this really just "a different Sequence Number value" or do we want "a
> > larger Sequence Number value"?  If the former, then it's not really
> > functioning as a *sequence* number, is it?
> 
> The sequence number does increment (which is useful for logging, etc), but the client
> behavior is the same for any different value (since it could be wrapped).
> 
> > Also, is the "until [...]" clause really needed?  Regardless of whether
> > new additional information is retrieved (and validated), *this*
> > additional information is still not being used.
> 
> Agreed. Removed the "until" clause.
> > 
> > nit: if we are going to say "uniformly random" for the [(B-A)/2,B]
> > interval, we should probably also use "uniformly" for the "random time
> > between zero and 2**(Delay * 2) milliseconds".

(This is just a nit and doesn't really need a response, but putting a
remark here just in case it was accidentally overlooked.)

> >   Since the 'Delay' value is directly within the PvD Option rather than
> >   the object itself, an operator may perform a push-based update by
> >   incrementing the Sequence value while changing the Delay value
> > 
> > nit: "Sequence Number"
> 
> Fixed.
> > 
> > Section 4.2
> > 
> >   RA by the network operator.  In particular, when a captive portal is
> >   present, hosts MUST still be allowed to perform DNS, PKI and HTTP
> >   over TLS operations related to the retrieval of the object, even
> >   before logging into the captive portal.
> > 
> > I assume "DNS" here means "DNS over UDP(/TCP) on port 53 in the
> > traditional, unencrypted, protocol of STD 13"?  It may be prudent to be
> > clear about the expectations here.
> 
> I'd prefer to not specify the DNS protocol here. If the local network ends up provisioning DoT or DoH, and in the future doesn't allow Do53, I'd want that to be equally included.

My concern is more along the lines of "if what is allowed is not what the
client is willing/planning to do, the client is in for a sad time".  If the
client's author reads this differently than the captive portal's author, we
would run the risk of interop failure.

> > 
> >   Routers SHOULD increment the PVD Option Sequence Number by one
> >   whenever a new PvD Additional Information object is available and
> >   should be retrieved by hosts.  If the value exceeds what can be
> >   stored in the Sequence Number field, it SHOULD wrap back to zero.
> > 
> > Why are these just "SHOULD"?
> 
> Changed the wrapping value to a MUST. Leaving the increment as a SHOULD, since it is up to the deployment to decide if all changes are worth pushing an update to be fetched.

Okay, thanks.

> >   The server providing the JSON files SHOULD also check whether the
> >   client address is part of the prefixes listed into the additional
> >   information and SHOULD return a 403 response code if there is no
> >   match.
> > 
> > (I assume that the "SHOULD" is to allow for exceptions when NAT-shaped
> > things are in use.)
> 
> Correct. It's certainly not preferred to have the NAT66 case, but we didn't want to prevent it.
> 
> > nit: "is part of" is perhaps a bit odd
> 
> Changed to:
> 
> client address is contained by the prefixes listed in the additional
> information, and SHOULD return a 403 response code if there is no
> match.
> > 
> > Section 4.3
> > 
> > [perhaps update the example "expires" value to something slightly more
> > current, both here and in 4.3.1?]
> > 
> >   | noInternet | No Internet, set     | Boolean  | true               |
> >   |            | when the PvD is      |          |                    |
> >   |            | restricted.          |          |                    |
> > 
> > nit: "set to 'true'"; setting it to "false" does not provide such an
> > indication :)
> 
> Fixed
> > 
> > In addition to Alissa's Discuss point, "MUST create sub-dictionaries,
> > [...] with a key of the format 'vendor-*'" is in conflict with "URN
> > namespace SHOULD be used rather than the 'vendor-*' format".
> 
> As changed for Alissa's comments, the new paragraph is:
> 
> Private-use or experimental keys MAY be used in the JSON
> dictionary. In order to avoid such keys colliding with IANA registry
> keys, implementers or vendors defining private-use or experimental
> keys MUST create sub-dictionaries. If a set of PvD Additional Information keys
> are defined by an organization that has a Formal URN Namespace {{URN}},
> the URN namespace SHOULD be used as the top-level JSON key for
> the sub-dictionary. For other private uses, the sub-dictionary key
> SHOULD follow the format of "vendor-\*", where the "\*" is replaced by the
> implementer's or vendor's identifier. For example, keys specific to the FooBar
> organization could use "vendor-foobar". If a host receives a sub-dictionary with
> an unknown key, the host MUST ignore the contents of the sub-dictionary.

This doesn't quite provide a strict prohibition against using a
likely-to-conflict name for the sub-dictionary's key, but it's hard to
believe that anyone not actively being contrarian would do the wrong thing,
so I don't see much need to tweak it further.

> > Section 4.4
> > 
> >   When a host retrieves the PvD Additional Information, it MUST verify
> >   that the TLS server certificate is valid for the performed request
> >   (e.g., that the Subject Alternative Name is equal to the PvD ID
> >   expressed as an FQDN).  This authentication creates a secure binding
> >   between the information provided by the trusted Router Advertisement,
> > 
> > What makes an RA "trusted"?
> 
> Nothing =) Removed the word

I'll have to quote you on that sometime :)

> >   and the HTTPS server.  However, this does not mean the Advertising
> >   Router and the PvD server belong to the same entity.
> > 
> > Can you give me an example of when they would not be part of the same
> > entity?  I can only partially see how that would happen.
> 
> I think it's clearer to remove the sentence, since it's not a particularly interesting point. The idea is that you may have a PvD server provider that's run by a larger service (say your local network is a one-off cafe network, but it points to extended info that's generic for a larger set of deployments), but I don't know if that really is relevant here.

It may be useful to give the reader a reminder about the distinction
between advertising router and PvD server in the context of there only
being a unidirectional authorization binding (PvD authorizes addresses, but
router-to-PvD is mostly not authorized/authenticated), but I agree that
this is probably not the best place in the document for such discussion.

> > 
> > I see there's some discussion of client IPv4 addresses here, but note
> > that the "prefixes" entry in the additional information is specifically
> > limited to IPv6 prefixes.  Does the prefix check just not work at all
> > for IPv4, or we know that NAT44 is too prevalent for it to be worth
> > trying, or ...?
> 
> The prefix checking here, and all of the additional info, does require IPv6 prefixes. Partly, IPv4 and NAT44 make this less useful, but its more that it's not really possible to have multiple co-existing IPv4 explicit PvDs anyhow. Since this form of explicit PvD is defined by the RA option, it makes sense to use the IPv6 prefix only.
> 
> > 
> > Section 5
> > 
> > Do you want to also mention that some fields (e.g., Sequence Number) are
> > only listed when relevant, and/or provide default values for the
> > examples when they are not explicitly listed?
> 
> Added the following text:
> 
> Values in the PvD Option header that are not
> included in the example are assumed to be zero or false (such as the
> H-flag, Sequence Number, and Delay fields).

Thanks.

> > Section 5.2
> > 
> >   In the above example, non-PvD-aware hosts will only use the first RA
> >   sent from their default router and using the 2001:db8:cafe::/64
> >   prefix.  PvD-aware hosts will autonomously configure addresses from
> > 
> > nit(?): I can't decide whether "from" or "for" is intended in "from
> > their default router".
> 
> Changed to "sent by their default router".

Oh, hmm, that's not where I thought this was going.  Perhaps I was just
confused!  Anyway, I was reading this along the lines of "a host will join
a network and listen for RAs, possibly solicting them too.  The first
received RA will be used as the default router", but on a re-read, it seems
likely that "first" just means "the first one in the example, not the
second one in the example".  (But will the host know that the sender is
their default router at the time they receive that RA?)

> >   both PIOs, but will only use the source address in 2001:db8:f00d::/64
> >   to communicate past the first hop router since only the router
> >   sending the second RA will be used as default router; similarly, they
> >   will use the DNS server 2001:db8:f00d::53 when communicating with
> >   this address.
> > 
> > nit: I'm not sure I understand what "communicating with this address" is
> > intended to mean (it would make more sense to me as "communicating from
> > this adddress").
> 
> Changed to "from".
> > 
> > Section 5.3
> > 
> >      *  RA Header: router lifetime = 1600 (PvD-aware hosts will use
> >         this router as a default router), implicit length = 2
> > 
> > just to check my understanding: this is only "use as a default router"
> > within the scope of this PvD (and will use the other RA's data as
> > default router for the other PvD)?  I'd perhaps consider adding "for
> > this PvD", though it's far from clear that such clarification in the
> > text is needed.
> 
> That's correct; I'd prefer to leave the text as is.
> > 
> > Section 6
> > 
> > This RA Option can include other RA Options; we should probably note
> > that the security considerations of the included options continue to
> > apply.
> 
> Added:
> 
> Since the PvD ID RA option can contain an RA header and other RA options,
> any security considerations that apply for specific RA options continue to
> apply when used within a PvD ID option.

Thanks!

> > When RAs have to be split to avoid exceeding the link MTU, there is
> > perhaps some scope for selective packet blocking to influence host
> > behavior (by denying them some of the PvD-specific configuration),
> > though of course such attacks are pretty challenging on a local
> > network/link.
> 
> Added:
> 
> Fragmentation of RAs can lead to processing only part of a PvD ID
> option, which could lead to hosts receiving only part of the contained
> options. As discussed in {{router}}, routers MUST include the PvD ID
> option in all fragments generated.
> > 
> > Attacks to block attempts to retrieve the additional information are
> > more likely succeed, though the scope is perhaps limited since all that
> > stuff is supposed to be optional.  We can't really limit what vendors
> > will do with it, though, so we should probably treat it as having some
> > significant risk of DoS.
> 
> Will address as part of Adam's comments on DoS.
> > 
> > Expiration times are represented as absolute times, so the usual
> > considerations about accurate time and clock skew apply.
> 
> Added:
> 
> Since expiration times provided in PvD Additional Information use absolute time,
> these values can be skewed for hosts without an accurate time base, or
> due to clock skew. Such time values MUST NOT be used for security-sensitive
> functionality or decisions.

Thanks.

> >   This specification does not improve the Neighbor Discovery Protocol
> >   security model, but extends the purely link-local trust relationship
> >   between the host and the default routers with HTTP over TLS
> >   communications which servers are authenticated as rightful owners of
> >   the FQDN received within the trusted PvD ID RA option.
> > 
> > I think I need some more persuasion to believe that the routers are
> > actually "authenticated as rightful owners of the FQDN received" as
> > claimed here.  In light of the following paragraph in the text, perhaps
> > we should say something more like "validates that the owner of the FQDN
> > authorizes its use with the prefix advertised by the router" and "in
> > combination with implicit trust in the local router (if present), this
> > gives the host some level of assurance that the PvD is authorized for
> > use in this environment.  However, when the local router cannot be
> > trusted, no such guarantee is available."
> 
> I do like the suggestion. Text is now:
> 
> This specification does not improve the Neighbor Discovery Protocol
> security model, but simply validates that the owner of the PvD FQDN
> authorizes its use with the prefix advertised by the router. In
> combination with implicit trust in the local router (if present), this
> gives the host some level of assurance that the PvD is authorized for
> use in this environment. However, when the local router cannot be
> trusted, no such guarantee is available.
> > 
> >   Users cannot be assumed to be able to meaningfully differentiate
> >   between "safe" and "unsafe" networks.  This is a known attack surface
> >   that is present whether or not PvDs are in use, and hence cannot be
> >   addressed by this document.  However, a host that correctly
> >   implements the multiple PvD architecture ([RFC7556]) using the
> >   mechanism described in this document will be less susceptible to such
> >   attacks than a host that does not by being able to check for the
> >   various misconfigurations described in this document.
> > 
> > I think this is only true for certain definitions of "safe" and would
> > like to learn more about what definition the authors had in mind when
> > writing this.
> 
> Removed the line about "safe" vs "unsafe", and merged the paragraphs.
> > 
> > Section 7
> > 
> > Whenever we introduce new identifier (types), the question of privacy
> > considerations arises with respect to tracking of the identified entity
> > or related entities, among other things.  The PvD itself here is not
> > really "trackable", so we seem to be concerned only with tracking of
> > devices that connect to /use a given PvD.  I'll try to walk through the
> > workflow to confirm that there's not more that needs to be said here:
> > Generally, a host is going to mostly just be receiving the PvD ID value,
> > and not broadcasting it in much outgoing traffic.  It would perhaps get
> > some configuration about PvD IDs in some area (though configured PvD IDs
> > seems more likeoy on routers than hosts), and receives PvD IDs via RA
> > options, and uses the PvD ID to correlate/associate information across
> > RAs, potentially across networks and mobility events.  The only time I
> > see the PvD ID being sent outbound from a PvD-aware host is in the query
> > to the PvD's well-known URI for additional information, and we say that
> > the DNS resolution used to look up that name must be from the same
> > configuration that claims to use that PvD. This is done with the intent
> > that there's no additional information leakage, as we're essentially
> > just echoing back the PvD ID to the same administrative entity that gave
> > it to us.  For honest routers it clearly should work fine, but what
> > happens if we have dishonest routers?  A dishonest router could send an
> > RA claiming a different/bogus PvD ID, and an honest host as specified
> > here would then go ahead and make the DNS+HTTPS query for additional
> > information, which is still just echoing back the value that was sent,
> > to who sent it.  There would only be some additional information leakage
> > if the host was configured to be selective about which PvDs to fetch
> > additional information for, so that the attacker could check whether a
> > given PvD ID was on the whitelist or not.  I think, though, that even if
> > a host does have a whitelist of PvD IDs it will use, there's still no
> > harm from always fetching the additional information and just discarding
> > it for non-whitelisted PvDs -- that lets such a host blend into the
> > genera population of PvD-aware hosts without directly revealing that it
> > has a whitelist or the contents thereof.  (Its subsequent network
> > traffic might still give some implicit signal, though that's perhaps
> > less conclusive.)
> 
> Thanks for the detailed walk-through. I agree with your analysis.
> > 
> > I don't have a great sense of how (un)likely host-leve PvD whitelists
> > are to be seen in practice, and thus whether it's worth putting the
> > above advice/analysis (just the "to blend in, always fetch even if you
> > ignore" part) into the document.  Given that we do mention
> > FQDN/IP-prefix whitelists, I'm leaning towards including this aspect as
> > well.
> 
> Added the following privacy consideration based on this:
> 
> Hosts might not always fetch PvD Additional Information, depending on
> whether or not they expect to use the information. However, if a host
> whitelisted only certain PvD IDs for which to fetch Additional Information,
> an attacker could send various PvD IDs in RAs to detect which PvD IDs
> are whitelisted by the client. To avoid this, hosts SHOULD either fetch
> Additional Information for all eligible PvD IDs on a given local network, or
> fetch the information for none of them.

Thanks.  That also seems to cover another risk I had thought of after I
wrote that, namely that advice to always fetch can serve as a signal that
the host supports PvDs at all.  Your text leaves the host that freedom,
which is good (since the largest anonymity set will probably change over
time).

> 
> > 
> > (The above analysis changes some if a host is going to be caching any
> > PvD-specific information across mobility events within the same PvD, but
> > I don't see much to indicate that such long-term caching would occur.)
> > 
> >   default router, this property can't be ensured.  Therefore, hosts
> >   willing to retrieve the PvD Additional Information before using it
> >   without leaking identity information, SHOULD make use of an IPv6
> > 
> > nit: this is either tautological or not saying what it's intended to,
> > since it's impossible to use the information without having first
> > retrieved it...
> 
> > 
> >   Privacy Address and SHOULD NOT include any privacy sensitive data,
> >   such as User Agent header or HTTP cookie, while performing the HTTP
> >   over TLS query.
> > 
> > ...so perhaps rephrasing akin to "To minimize the leakage of identity
> > information while retrieving PvD Additional Information, hosts SHOULD
> > [...]" is in order.
> 
> Yes, that sentence was a bit confused. The new text is:
> 
> To minimize the leakage of
> identity information while retrieving the PvD Additional Information, hosts
> SHOULD make use of an IPv6 temporary address and SHOULD NOT
> include any privacy-sensitive data, such as a User-Agent header field
> or an HTTP cookie.
> > 
> >   From a user privacy perspective, retrieving the PvD Additional
> >   Information is not different from establishing a first connection to
> >   a remote server, or even performing a single DNS lookup.  For
> >   example, most operating systems already perform early queries to well
> >   known web sites, such as http://captive.example.com/hotspot-
> >   detect.html, in order to detect the presence of a captive portal.
> > 
> > I understand the desire to only use names/numbers designated as "for
> > example use" in RFCs, but this seems like a case where it might be worth
> > making an exception.
> 
> I don't see an issue with using "example.com" here as the example domain. Did you have something specific in mind?

The phrasing "well known web sites" made me think there were specific ones
that are actually well-known; captive.example.com does not really seem
"well-known" to me.  IIRC there were some apple.com and other examples
listed in a reference or some of the email discussion, and I thought those
were what this was trying to refer to.

> >   Network operators SHOULD restrict access to PvD Additional
> >   Information to only expose it to hosts that are connected to the
> >   local network, especially if the Additional Information would provide
> >   information about local network configuration to attackers.  This can
> > 
> > (It seems that even the existence of a vendor-* subobject might be
> > considered "sensitive" in this fashion.)
> 
> Indeed!
> > 
> > Section 8.2
> > 
> > Is there any additional guidance we wish to give to the Experts?
> 
> How about:
> 
> Experts are requested to ensure that defined keys do not overlap,
> and represent non-vendor-specific use cases. Vendor-specific keys
> SHOULD use sub-dictionaries, as described in {{aiformat}}.

That seems reasonable, though perhaps clarifying if the non-overlap is in
the semantics of keys or their naming would be helpful.

> > Section 8.3
> > 
> >   document (as specified in Figure 1).  Future assignments require
> >   Standards Action [RFC8126], via a Standards Track RFC document.
> > 
> > nit: please drop the "via a Standards Track RFC document" clause; it's
> > basically redundant with Standards Action and I'm not sure why there's a
> > specific need to disallow BCP documents from allocating such codepoints.
> 
> Fair point. Removed that clause.
> > 
> > Section 8.4
> > 
> >   Interoperability considerations: This document specifies format of
> >   conforming messages and the interpretation thereof.
> > 
> > nit: "the format"
> 
> Fixed.
> > 
> >   Applications that use this media type: This media type is intended to
> >   be used by network advertising additional Provisioning Domain
> >   information, and clients looking up such information.
> > 
> > nit: "networks" plural
> 
> Fixed.
> > 
> > Section 10.1
> > 
> > I'm not sure whether RFCs 2131, 3646, and 8106 need to be Normative.
> 
> Made informative.
> > 
> > Section 10.2
> > 
> > On the other hand, RFC 2818 does seem like it needs to be Normative (and
> > 7556 as was already mentioned).
> 
> Made normative.

Thanks for all the updates!

-Ben