Re: [Add] Paul Wouters' Discuss on draft-ietf-add-dnr-11: (with DISCUSS)

[Eliot Lear <[e-mail]>]

Hi,

I have one procedural point and several comments below.

My procedural point is that it is not appropriate to preface DISCUSS 
with a treatise about the very nature of the working group and protocol, 
especially when the IESG member could have contributed to that 
discussion as an individual, both during chartering and throughout the 
progression of the work, including at either WGLC or IETF LC.  It is not 
as though this work received no attention from the community, or wasn't 
hashed out in great detail by the working group.  The ADD group is 
trying to lay out some improvements on the current state of affairs, not 
what one AD personally believes Utopia is Utopia.  One can certainly 
outline such beliefs, and I'm sure the ISE would seriously consider 
publishing them (knowing him as well as I do ;-).

Tiru has answered most of your specific issues, which I think are 
appropriate.

Several points below:


>
>     ###
>
>     Encrypted DNS servers need a public FQDN because otherwise you
>     cannot get
>     a certificate for all connecting clients that are not provisioned
>     with a
>     private/enterprise CA. How do home users run their own without
>     having a
>     public domain? And how do I authenticate the encrypted DNS on 10.1.1.1
>     that has no FQDN? (and really, has no verifiable identity at all).
>
>
> The FQDN can be provisioned by the ISP managing the CPE or the 
> security service vendor offering network security service can 
> provision the CPE with a real FQDN (please see section 4 in 
> https://datatracker.ietf.org/doc/html/draft-boucadair-add-deployment-considerations-00 for 
> more details).


If this is a security consideration and you are proposing a remediation, 
then it should be listed as such with a reference to the draft you 
mention.  It is fair game for people to argue whether the remediation 
would be effective.


>  [...]
>
>     One possible method might
>     be to bind it to the ESSID. eg if the ESSID is wifi.nohats.ca
>     <http://wifi.nohats.ca>. one could only allow
>     authentication-domain-name to be a name within nohats.ca
>     <http://nohats.ca>. Some method of reducing the
>     scope of this attack is needed I believe.
>

That's an interesting speculation that it seems to me is worth fleshing 
out in a draft of its own, and possibly liaising to the 802.11 and Wifi 
Alliance folk.  It requires an analysis of the binding of names in 
ESSIDs to domain names, and associated security considerations.  Color 
me skeptical until that work is done.

[...]

>
>     ###
>
>     Multihoming is declared out of scope, but realistically most
>     devices we are
>     talking about here are phones, and those are all multihomed. So I
>     feel pretty
>     strongly that it should not be left out of scope.
>
Let's be specific.  Phones may for a brief time make simultaneous use of 
their cellular and Wifi radios so that handoffs work correctly.  This 
could lead to an inconsistency if two resolvers are returning different 
results.  There may also be different levels of trust between different 
name servers.  Both of these issues lead to policy matters in clients, 
not something I see as relevant to standards.

I don't know of situations where devices are testing different Wifi 
networks on the same radio, and the chipsets I work with don't support 
that.  A second Wifi radio would do the job, but I also don't know of 
phones that have such second radios.  Perhaps you have a reference?

Eliot