Re: [Dots] AD review of draft-ietf-dots-server-discovery-10

[Benjamin Kaduk <[e-mail]>]

Hi Med,

Thanks for the responses (and the follow-up link to the staged changes).
Just covering the remaining topics inline; this generally looks good.

On Mon, Sep 21, 2020 at 02:23:05PM +0000, [e-mail] wrote:
> Hi Ben, 
> 
> Thank for the review. 
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Benjamin Kaduk [mailto:[e-mail]]
> > Envoyé : vendredi 18 septembre 2020 22:22
> > À : [e-mail]
> > Cc : [e-mail]
> > Objet : AD review of draft-ietf-dots-server-discovery-10
> > 
> > Hi all,
> > 
> > Despite the first half of the review basically being entirely nits,
> > there are some substantive comments in there later on.  (Would it be
> > helpful if I tried harder to split the nits out into a separate
> > section in the future?)
> > 
> > Overall it's pretty straightforward, so no major issues left to
> > address; sorry for taking so long to get through it.
> > 
> > 
> > One thing that we should definitely fix before getting more eyes on
> > this document is that both TBD1 and TBD2 are overloaded -- we use
> > them to refer to the port assignments from the signal channel and
> > call home protocol assignments, but also for the DHCPv6 option
> > codes.
> 
> [Med] We used TBA1/TBA2 in the core text for the codes to be assigned for DHCPv6. Fixed the IANA section, though.  
> 
[...]
> > 
> >    All DOTS clients MUST support at least one of the three
> > mechanisms
> >    below to determine a DOTS server list.  All DOTS clients SHOULD
> >    implement all three, or as many as are practical for any specific
> >    device (e.g., a CPE will support the first two mechanisms, a host
> >    within a LAN will support the last two mechanisms, or an
> > application
> >    server will support a local configuration.  More samples are
> >    discussed in Section 3), of these ways to discover DOTS servers,
> > in
> >    order to facilitate the deployment of DOTS in large scale
> >    environments:
> > 
> > nit: the way the parenthetical is structured is a bit unusual, with
> > a sentence break occurring within the parentheses (and leaving quite
> > a gap for processing in the middle of the thought "implement all
> > three of these ways").  It's probably okay to just make the "SHOULD
> > implement all three" a single standalone sentence, and leave the
> > clarification of when implementing all three is
> > infeasible/unnecessary to a follow-up sentence.
> 
> [Med] Will split to ease the readability. 

Thanks, it looks a lot better.

[...]
> > 
> >       Let's consider that the DOTS server is reachable at
> >       2001:db8:122:300::1 while the Call Home DOTS client is
> > reachable
> >       at 2001:db8:122:300::2.  The DHCP server will then return one
> > DOTS
> >       reference identifier and a list that includes both
> >       2001:db8:122:300::1 and 2001:db8:122:300::2 to a requesting
> > DHCP
> >       client.  That list is passed to the DOTS client (or Call Home
> > DOTS
> >       server) which will try to establish connections to the
> > addresses
> >       of that list and destination port number TBD1 (or TBD2).  As a
> >       result, the DOTS client (or Call Home DOTS server) will select
> >       2001:db8:122:300::1 (or 2001:db8:122:300::2) as a DOTS server
> > (or
> >       Call Home DOTS client).
> > 
> > I mostly expect pushback from TSV-area reviewers about giving the
> > allocated port numbers such importance in selecting the peer address
> > to use.
> 
> [Med] We need to demux call-home from the base signal channel. We have text in the call home draft to explain this. We can point the reviewers to that section. 

Okay, we can see if that is persuasive enough to convince the reviewers.

> > 
> > Section 5.1.2
> > 
> >    format of this option is shown in Figure 5.  As a reminder, this
> >    format follows the guidelines for creating new DHCPv6 options
> >    (Section 5.1 of [RFC7227]).
> > 
> > We need the reminder for the second option but not the first one? ;)
> 
> [Med] Because we don't have a section to cite. There is only a list discussed in 5.10 but we don't only need one name. 
> 
> > 
> > Section 5.1.3
> > 
> >    are used to reach the peer DOTS agent.  In other words, the name
> >    conveyed in OPTION_V6_DOTS_RI MUST NOT be passed to underlying
> >    resolution library in the presence of OPTION_V6_DOTS_ADDRESS in a
> >    response.
> > 
> > I'm not sure how much of this needs to end up in the document
> > itself, but can we walk through the scenarios here, especially when
> > the DNS-resolution addresses for the name in question differ from
> > the addresses in OPTION_V6_DOTS_ADDRESS?
> 
> [Med] Actually, we want to avoid the aliasing issues discussed in RFC7227#section-7 (the resolution may lead to different addresses if the logic for binding a client to server is not visible to "public" resolvers). 
> 
> When OPTION_V6_DOTS_ADDRESS is configured, then it takes precedence. The client must not try to resolve the OPTION_V6_DOTS_RI. 

Thanks for the reference+discussion.  (I might say that we still have the
aliasing, but we try to forestall the negative consequences by defining a
specific priority order of processing.)

>   I don't understand yet
> > why/how this scheme ends up being safe, and am hoping that you have
> > a head start over me on doing the analysis :)
> 
> [Med] Returning both the address and the RI in the DHCP prevents redirecting a client to a "fake" server if the DNS queries are intercepted. We don't have this issue if both the address and the RI are returned in DHCP. 

I think my main concern here is that we get back a name to use for
authenticating the resulting connection, but then are told to not use our
normal procedure for establishing a secure connection to a named entity.
In theory the PKI structure should protect the communication no matter how
we decide to establish the connection (we trust the CA and the name is
certified by the trusted CA chain), but this kind of short-circuiting can
make some classes of attack easier -- if an attacker can get a fraudulently
issued cert, this mechanism lets them send the victim directly to the
attacker's machine without needing to also adjust the DNS/resolution path
on the victim.  Your example of a split-DNS case seems apt, but we should
probably mention the loss of "defense in depth" against mis-issued
certificates in the security considerations.

Which risk is more concerning (DNS spoofing vs. mis-issued cert) will
probably depend on the deployment specifics, including DNSSEC (non)usage,
so we will probably just have to document the tradeoff.

> > 
> >    If the DHCP client receives OPTION_V6_DOTS_RI only, but
> >    OPTION_V6_DOTS_RI option contains more than one name, as
> > 
> > nit: insert "the" at the start of the second line.
> 
> [Med] deleted "option". 
> 
> > 
> >    If the DHCP client receives OPTION_V6_DOTS_RI only, but
> >    OPTION_V6_DOTS_RI option contains more than one name, as
> >    distinguished by the presence of multiple root labels, the DHCP
> >    client MUST use only the first name.  Once the name is validated
> > 
> > Is there a reason to make this "use the first one" vs. "ignore the
> > whole thing as malformed?
> 
> [Med] If the message is ignored, the service won't be provided. 
> 
> > 
> >    (Section 8 of [RFC8415]), the name is passed to a name resolution
> >    library.  Moreover, that name is also used as a reference
> > identifier
> >    for authentication purposes.
> > 
> > Hmm, I'm not seeing much in Section 8 specifically of RFC 8415 that
> > looks relevant here.  Was perhaps a different document intended?
> 
> [Med] It used to be "Section 8 of 3315", but since 3315 was obsoleted by 8415, it should read "Section 10 of 8415". Good catch. Thanks. 
> 
> > 
> > Section 5.2.1
> > 
> > A reference to 2132 here would be timely, not least for
> > understanding the figure.
> > 
> 
> [Med] OK.
> 
> >      The values s1, s2, s3, etc. represent the domain name labels in
> > the
> >      domain name encoding.
> > 
> > super-nitty-nit: maybe "the octets of the domain name labels"?  IIUC
> > the RFC 2132 convention is to give such names to the individual
> > bytes of the DHCP option, but this wording implies that we are
> > naming labels, which are multi-byte (except for the root).
> 
> [Med] I see your point but the figure uses the convention used in many other dhc wg document. I will leave it. Bernie (dhc co-chair)  reviewed the dhcp part of the document and he didn't raise a comment about this.  

Okay, thanks.  I only took a narrow view into previous DHCP documents, so
he would have a better sense for what is current.

> > 
> > Section 5.2.2
> > 
> > I wonder if anyone will complain that we are using a more "modern"
> > structure for the figure, instead of keeping with the "traditional"
> > DHCP option diagrams.
> 
> [Med] At least, Bernie didn't complain when he reviewed the document. 
> 
> > 
> > Section 5.2.3
> > 
> >    To discover a peer DOTS agent, the DHCPv4 client MUST include
> > both
> >    OPTION_V4_DOTS_RI and OPTION_V4_DOTS_ADDRESS in a Parameter
> > Request
> >    List Option [RFC2132].
> > 
> > Why is the v4 case a MUST but the v6 case was only MAY?
> 
> [Med] Because we start the v4 text with "To discover a peer DOTS agent,". We could align both, though. 
> 
> > 
> >    If the DHCP client receives more than one instance of
> >    OPTION_V4_DOTS_RI (or OPTION_V4_DOTS_ADDRESS) option, it MUST use
> >    only the first instance of that option.
> > 
> > I think the parenthetical needs to be dropped, since in the previous
> > section we say that this is a concatenation-requiring option.
> 
> [Med] Agree. 
> 
> > 
> >    If the DHCP client receives OPTION_V4_DOTS_RI only, but
> >    OPTION_V4_DOTS_RI option contains more than one name, as
> >    distinguished by the presence of multiple root labels, the DHCP
> >    client MUST use only the first name.  Once the name is validated
> >    (Section 10 of [RFC8415]), the name is passed to a name
> > resolution
> >    library.  Moreover, that name is also used as a reference
> > identifier
> >    for authentication purposes.
> > 
> > [same comments about "use first" as for v4] I see that here we
> > reference §10, rather than 8, of RFC 8415, though it still doesn't
> > say much explicitly about a "validation procedure".
> 
> [Med] The validation is basically check it follows Section 3.1 of [RFC1035] and compression is not used.  
> 
> > 
> > The diff between §5.1.3 and 5.2.3 includes "(e.g., PKIX [RFRC6125])"
> > only in 5.1.3; it seems like it would also apply here.
> 
> [Med] Indeed. 
> 
> > 
> >    The DHCP client MUST silently discard multicast and host loopback
> >    addresses conveyed in OPTION_V4_DOTS_ADDRESS.
> > 
> > Can we put a reference for "multicast and host loopback" addresses
> > as we did for the v6 case?
> 
> [Med] Sure. 
> 
> > 
> > Section 6
> > 
> >    1.  A DNS domain name is retrieved for each combination of
> > interface
> >        and address family.  A DOTS agent has to determine the domain
> > in
> >        which it is located relying on dynamic means such as DHCP
> >        (Section 5) . [...]
> > 
> > Hmm, this may be worth a closer look.  If I understand correctly, if
> > the procedures in Section 5 only give you a name, you're supposed to
> > use DNS to get IP addresses to talk to, from that name.  So is this
> > procedure only applicable when the A/AAAA lookup fails?  Otherwise
> > I'm not sure how you would get only a name but not full contact
> > information, from the section 5 procedure.  Or, if the intent of
> > "the name is passed to a name resolution library" in Section 5 is to
> > induce the S-NAPTR lookups defined here, Section 5 should be more
> > clear about that.
> 
> [Med] S-NAPTR lookups is covered by "... to a name resolution library". Nevertheless, some deployments may not require S-NAPTR lookups and A/AAAA resolution would be just fine.    
> 
> > 
> >    Once the DOTS agent has retrieved its DNS domain or discovered
> > the
> >    peer DOTS agent name that needs to be resolved (e.g., Section 5),
> > an
> > 
> > (The parenthetical seems redundant with step (1).)
> 
> [Med] Fixed. 
> 
> > 
> >    S-NAPTR lookup with 'DOTS' application service and the desired
> >    [...]
> >    This specification defines "DOTS" and "DOTS-CALL-HOME" as
> > application
> >    service tags (Sections 9.4.1 and 9.4.2).  It also defines
> > 
> > We should probably mention "DOTS-CALL-HOME" in both places, or just
> > say something generic like "the appropriate application service" in
> > the first instance, instead of only saying 'DOTS' the first time.
> > 
> 
> [Med] Went for "the appropriate application service". 
> 
> >    a.example.net.
> >    IN AAAA  2001:db8::1
> > 
> > I'm sure my INT-area colleagues will appreciate the IPv6 examples :)
> > 
> > Section 8
> > 
> > Having a clearly defined priority order for using the different
> > discovery mechanisms covers most of the potential security
> > considerations inherently, but I think some text is in order about
> > whether an attacker can block/modify traffic to force a "lower
> > priority"
> > mechanism to be used (but would not be able to modify the "higher
> > priority" mechanism's results with the same capabilities).
> 
> [Med] Good point. I added the folliwng: 
> 
> "An attacker may block some protocol messages (e.g., DHCP) to force the client to use a discovery mechanism with a lower priority. The security implications of such attack are those inherent to the fallback discovery mechanism discussed in the following subsections. "

Thanks for adding the mention of forcing a lower priority; I think I'll
need to reread the whole thing in context to see if I want to have anything
else mentioned here.

> > 
> > We may also want to reiterate that discovery results are scoped by
> > interface and address family, and that bad things can happen if you
> > use a result from one interface for traffic from a different
> > interface.
> 
> [Med] We can add the following: 
> 
> "The results of the discovery procedure are a function of the interface/address family. Contacting a discovered DOTS server via an interface to which it is not bind may exacerbate the delay required to establish a DOTS channel. Moreover, such behavior may reveal that a DOTS service is enabled by a DOTS client domain and exposes the identity of the DOTS service provider (that can be inferred from the name and the destination IP address) to external networks."
> 
> > 
> > There are probably not particularly interesting privacy
> > considerations of advertising/exposing DOTS server names in these
> > various discovery mechanisms, but a brief section on privacy
> > considerations is likely in order regardless.
> 
> [Med] The NEW text above touched on "privacy". I'm not sure what we need to say more. 

The one I had in mind when writing the above was "if you put the
name/address of your DOTS server/call-home-client in DHCP or DNS, people
with access to that DNS/DHCP can find out the name/address of your DOTS
server/call-home-client", which is both (1) hopefully obvious and (2)
may not be particularly sensitive information, though I guess the DOTS
server might be an interesting DDOS target itself...

> > 
> > Section 8.2
> > 
> >    The primary attack against the methods described in Section 6 is
> > one
> >    that would lead to impersonation of a peer DOTS agent.  An
> > attacker
> >    could attempt to compromise the S-NAPTR resolution.  The use of
> >    mutual authentication makes it difficult to redirect a DOTS
> > client
> >    (or a Call Home DOTS server) to an illegitimate DOTS server (or a
> >    Call Home DOTS client).
> > 
> > IIUC this property only holds if the domain name used for
> > authenticating the peer (i.e., the input to the RFC 6125 procedures)
> > is the one used as input to the procedure in Section 6, not the
> > intermediate names produced during that procedure (e.g.,
> > "example.net" as input and "a.example.net"
> > as intermediate, from Figure 10).  I don't think we specify anywhere
> > that this must be the case, so on the face of it it seems that in
> > the absence of DNSSEC, an attacker spoofing DNS responses can
> > redirect the client to an arbitrary name controlled by the attacker,
> > for which the attacker has valid PKIX credentials.  (We also allow
> > SRV-IDs for validation, so the SRV names are also affected.) I also
> > note that the analogous question for mail servers (whether they
> > authenticate as example.net or a.example.net) is a recurring source
> > of trouble, so our hand may be forced by deployment realities.
> 
> [Med] Good point. Will update the text. 

Thanks.

> > 
> > Section 8.3
> > 
> > I was going to say that we should reference the RFC 6763 security
> > considerations, too, but they are just saying the same things we
> > already say.
> > 
> > Section 12.2
> > 
> > I expect at least one AD to suggest that the architecture draft
> > should be normative since we require it for terminology, but I don't
> > insist on changing its classification at this time.  (Likewise for
> > Call Home.)
> > 
> 
> [Med] Will let them as they are. Let's see if we will get comments on this. 

Sounds good.

If you could try to add a mention of the "attacker-supplied IP addresses
makes it easier to use a mis-issued certificate" case to the security
considerations and publish the new version, it sounds like this will be
ready for IETF LC.

Thanks again,

Ben