Subject: Re: [dns-privacy] Suresh Krishnan's Discuss on draft-ietf-dprive-dtls-and-tls-profiles-09: (with DISCUSS)

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 6 Jun 2017 10:18:39 +0200

On Tue, May 09, 2017 at 08:43:15PM -0700,
 Suresh Krishnan <[email-masked]> wrote 
 a message of 37 lines which said:

> I do have a concern regarding section 7.3 as it is not clear what
> really is being requested on the DHCP front here. While using an IP
> address or an FQDN are generally both possible choices while
> providing configuration options using DHCP, the use of FQDNs for
> acquiring trusted DNS servers seems problematic. We have spent a
> great deal of effort writing up some of the potential issues in
> Section 8 of RFC7227.

It seems there was no reply to this DISCUSS? If so, let me give my
opinion: I disagree with the DISCUSS. Section 7.3 is just here to lay
down some paths toward a future and possible DHCP extension. It does
not attempt to standardize one. It does not request anything from the
current DHCP servers.

Mentioning section 8 of RFC 7227 could help, but this section does not
discuss the DNS-specific issues (such as the fact we need both IP
address and name of the DNS resolver, which RFC 7227 frame it as an
exclusive choice).

Possible solution if it is absolutely necessary to clear the DISCUSS:
moving section 7.3 to an appendix to make clear it is not part of the
DNS-over-TLS profiles definition.

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 7 Jun 2017 00:25:25 +0530

Hi Stephane,

> On Jun 6, 2017, at 1:48 PM, Stephane Bortzmeyer <[email-masked]> wrote:
> 
> It seems there was no reply to this DISCUSS?

Yes. There was no response to this DISCUSS.

> If so, let me give my
> opinion: I disagree with the DISCUSS.

Not sure what you are disagreeing with. Are you saying this text is clear about what is needed from the eventual DHCP option(s)?

> Section 7.3 is just here to lay
> down some paths toward a future and possible DHCP extension.

What is(are) the paths? If it was clear, I wouldn’t really be asking.
 
> It does

What does this text mean?

"However when using a Strict profile the DHCP
   servers used as sources of authentication domain names MUST be
   considered secure and trustworthy.  This document does not attempt to
   describe secured and trusted relationships to DHCP servers."

The strict profile requires the DHCP server to be “secure and trustworthy” but declines to define what it means by “secure and trusted”. So I cannot tell if it requires anything from current DHCP servers or not. 

> DNS-over-TLS profiles definition.

If the text is taken out, I will certainly clear. 

Thanks
Suresh

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 6 Jun 2017 21:21:39 +0200

On Wed, Jun 07, 2017 at 12:25:25AM +0530,
 Suresh Krishnan <[email-masked]> wrote 
 a message of 42 lines which said:

> > If so, let me give my opinion: I disagree with the DISCUSS.
> 
> Not sure what you are disagreeing with. Are you saying this text is
> clear about what is needed from the eventual DHCP option(s)?

IMHO, yes.

> The strict profile requires the DHCP server to be “secure and
> trustworthy” but declines to define what it means by “secure and
> trusted”. So I cannot tell if it requires anything from current DHCP
> servers or not.

Proposal for a new 7.3:

In the typical case, a DHCP server [RFC2131] [RFC3315] provides a list
of IP addresses for DNS resolvers (see section 3.8 of [RFC2132]), but
does not provide a domain name for the DNS resolver, thus preventing
the use of most of the authentication methods described here. (All
those that are based on a mechanism with ADN in table 2.)

In the future, a DHCP server might use a DHCP extension to provide a
list of authentication domain names for the offered DNS servers, which
correspond to IP addresses listed. People who wish to work on such a
yet-to-come extension may be interested in section 8 of [RFC7227].

Even with this future extension, this leaves open the issue of the
trust in the DHCP server. Of course, in a typical hotspot, the DHCP
server is not to be trusted (see section 23 of [RFC3315]) for the
Strict profile. When using an Opportunistic profile, it would be
reasonable to use the ADN indicated by the DHCP server, given the
security expectation of that profile.

Some clients may have an established trust relationship with a known
DHCP server for discovering their network configuration.  When using a
Strict profile the DHCP servers used as sources of authentication
domain names is sensible only if the server is considered secure and
trustworthy. This document does not attempt to describe secured and
trusted relationships to DHCP servers, which is a purely DHCP
issue. (Still open, at the time of writing.)  Whilst some
implementation work is in progress to secure IPv6 connections for
DHCP, IPv4 connections have received little to no implementation
attention in this area.

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 7 Jun 2017 14:27:56 +0100

> On 6 Jun 2017, at 19:55, Suresh Krishnan <[email-masked]> wrote:
> 
> Hi Stephane,
>> 

Apologies, I indirectly responded to a similar comment another review (in that we would need to update the text given that there were several comments on it) but hadn’t proposed any new text. The revised I-D is still being worked on.

> On 6 Jun 2017, at 20:21, Stephane Bortzmeyer <[email-masked]> wrote:
>> 

Stephane was correct in that this section was not requesting or proposing anything specific with regard to DHCP, only outlining a potential future use case. 

I have proposed some minor modifications to Stephane’s text below which could make this even clearer, however if this isn’t sufficient then I think moving this to an appendix would be the best option. 

Sara. 

> Proposal for a new 7.3:

7.3 No configuration - dynamic discovery of ADN 

This section discusses the general case of a DNS client discovering both the authentication domain name and IP address dynamically. This is not possible at the time of writing by any standard means. However since, for example, a future DHCP extension could (in principle) provide this mechanism the required security properties of such mechanisms are outlined here. 

When using a Strict profile the dynamic discovery technique used as a source of authentication domain names MUST be
considered secure and trustworthy. This requirement does not apply when using an Opportunistic profile given the
security expectation of that profile. 

7.3.1 DHCP

In the typical case today, a DHCP server [RFC2131] [RFC3315] provides a list

This document does not specify or request any DHCP extension to provide authentication domain names. However, if one is developed in future work the issues outlined in section 8 of [RFC7227] should be taken into account as should the Security Considerations in section 23 of [RFC3315]) . 

This document does not attempt to describe secured and
trusted relationships to DHCP servers, which is a purely DHCP
issue (still open, at the time of writing.)  Whilst some
implementation work is in progress to secure IPv6 connections for
DHCP, IPv4 connections have received little to no implementation
attention in this area.

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 8 Jun 2017 00:12:03 +0530

Hi Stephane/Sara,
  I will be happy with either of your text proposals as they certainly clarify things for me.

Regards
Suresh

> On Jun 7, 2017, at 6:57 PM, Sara Dickinson <[email-masked]> wrote:
> 
>

---

From: Terry Manderson <[email-masked]>
Date: Fri, 16 Jun 2017 01:12:38 +0000

Thanks Suresh..

Authors, any ETA on when the revs that addresses Suresh's and EKR's Discusses?

Cheers
Terry

On 8/06/2017, 4:42 AM, "iesg on behalf of Suresh Krishnan" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Stephane/Sara,
    
    Regards
    Suresh