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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 21 Jan 2020 16:21:17 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-intarea-provisioning-domains-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains/

----------------------------------------------------------------------
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.

(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.)

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.

----------------------------------------------------------------------
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.

   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".

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".

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?

   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.

   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?

   [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?

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]")?

   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?

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.

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.

   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?

   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...

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".

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.

   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.

   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.

   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/

   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?
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.

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".

   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"

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.

   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"?

   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.)
nit: "is part of" is perhaps a bit odd

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 :)

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".

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"?

   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 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 ...?

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?

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".

   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").

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.

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.

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.

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.

Expiration times are represented as absolute times, so the usual
considerations about accurate time and clock skew apply.

   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."

   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.

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.)

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.

(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.

   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.

   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.)

Section 8.2

Is there any additional guidance we wish to give to the Experts?

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.

Section 8.4

   Interoperability considerations: This document specifies format of
   conforming messages and the interpretation thereof.

nit: "the format"

   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

Section 10.1

I'm not sure whether RFCs 2131, 3646, and 8106 need to be Normative.

Section 10.2

On the other hand, RFC 2818 does seem like it needs to be Normative (and
7556 as was already mentioned).

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 23 Jan 2020 10:20:40 -0800

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 <[email-masked]> wrote:
> > 
> 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.

> 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!
> 
> > 
> Good catch. I've updated this to indicate that only 12 bits are available.
> > 
> > 
> 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.

> 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).

> The paragraph now reads:
> 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!

> 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.)

> I see your point. Changed to:
> 
> (e.g., default routers, addresses, more specific routes, DNS Recursive
> Resolvers) with the PvD associated with the RA that provisioned the
> object. 
> > 
> 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...
> > 
> Fair point. Merged them!
> 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.

> 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.

> 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...)

> 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!

> Changed to "for"
> 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.)

> Good call. Fixed!
> 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!

> Changed to:
> If the HTTP status of the answer is greater than or equal to 400
> the host MUST close its connection...
> > 
> 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?)

> Fixed!
> 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).
> 
> Agreed. Removed the "until" clause.
> > 

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

> Fixed.
> 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.

> 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.

> Correct. It's certainly not preferred to have the NAT66 case, but we didn't want to prevent it.
> 
> 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
> > 
> Fixed
> 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.

> Nothing =) Removed the word

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

> 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.

> 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
> > 
> 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.

> 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?)

> Changed to "from".
> That's correct; I'd prefer to leave the text as is.
> > 
> > Section 6
> > 
> 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!

> 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.
> > 
> Will address as part of Adam's comments on DoS.
> > 
> 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.

> I do like the suggestion. Text is now:
> 
> security model, but simply validates that the owner of the PvD FQDN
> authorizes its use with the prefix advertised by the router. In
> trusted, no such guarantee is available.
> > 
> Removed the line about "safe" vs "unsafe", and merged the paragraphs.
> > 
> > Section 7
> > 
> Thanks for the detailed walk-through. I agree with your analysis.
> > 
> 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).

> 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.
> > 
> 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.

> Indeed!
> 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.

> Fair point. Removed that clause.
> > 
> > Section 8.4
> > 
> Fixed.
> Fixed.
> Made informative.
> Made normative.

Thanks for all the updates!

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 23 Jan 2020 11:58:29 -0800

Hi Tommy,

On Thu, Jan 23, 2020 at 10:49:17AM -0800, Tommy Pauly wrote:
> Hi Ben,
> 
> Thanks for your responses! Comments inline for the points that needed replies.

Thanks; I have no further comments.

-Ben

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 22 Jan 2020 12:42:59 -0800

Hi Ben,

Responses inline.

Best,
Tommy

Added the following:

Delay:

Sequence Number:

The paragraph now reads:

Changed this to:

Fair point. Merged them!

or from some other

Changed to "for"

Good call. Fixed!

Changed to:

Changed to:

If the HTTP status of

Fixed!

Fixed.

Changed to:

Fixed

Changed to "from".

Added:

Added:

Added:

Indeed!

How about:

Fixed.

Fixed.

Made informative.

Made normative.

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 23 Jan 2020 10:49:17 -0800

Hi Ben,

Best,
Tommy

> On Jan 23, 2020, at 10:20 AM, Benjamin Kaduk <[email-masked]> wrote:
> 
> Hi Tommy,
> 
> Also inline.
> 

It should follow the usual HTTP client logic—it will follow multiple redirects up to a point, but prevent loops.
> remark here just in case it was accidentally overlooked.)

Sorry! I did fix this, just forgot to reply to this line.
> would run the risk of interop failure.

I think in the case of captive portals and bootstrapping traffic like PvDs, it's the responsibility of the client to use appropriate protocols that will be able to traverse the network. It may certainly gate user-sensitive DNS queries behind being able to do DoH, but should use Do53 or DoH or DoT based on what the network provides/allows for captive and PvD queries.

> this is probably not the best place in the document for such discussion.

Agreed.

> their default router at the time they receive that RA?)

Ah, I see the confusion. Yes, it was referring to the first one in the list. I can say "first listed RA" rather than just "first RA".
> that are actually well-known; captive.example.com <http://captive.example.com/> does not really seem
> "well-known" to me.  IIRC there were some apple.com <http://apple.com/> and other examples

I see; yes, this is referring to the fact that there are static queries that go out, which vary by platform (apple will use captive.apple.com). Perhaps rather than "well known web sites", this can be "static web sites".
> the semantics of keys or their naming would be helpful.

Sure, I can clarify that the "that defined keys do not overlap in names or semantics..."