Re: [homenet] Kathleen Moriarty's Discuss on draft-ietf-homenet-dot-12: (with DISCUSS and COMMENT)

[Ted Lemon <[e-mail]>]

I think these secdir comments are actually out of scope for this work (I'll comment in detail inline).   In order to mitigate the problems described, we would have to do work that is already being done in other working group documents (e.g. draft-tldm-simple-homenet-naming-01).   If you are interested in where this work is going, it would be better to wait a week or two and read the working group draft, which has been adopted and is due for a -00 submission.

Suggestions to use DTLS don't make sense, because we aren't allowed to require changes on the hosts.   Hosts currently do MDNS and spew private information all over the place; that problem is actually already being addressed by vendors.   The printer security problem is significant and is being discussed in the working group.   Again, DTLS doesn't really address this, because there is no PKI solution.

It might make sense to have a presentation on this next month when we meet in Boston—I'd be curious to get feedback from you and some of the other security folks on what we've been talking about.   I'm preparing a presentation for NIST in two weeks that will cover this topic as well, so I may be able to use some of that in Boston, if it makes sense to give me time on the agenda (I've presented quite a few times, so it might be too soon for me to present again).

Anyway, the point is that I don't think I can answer this discuss by making substantive changes to the document.

> On Aug 29, 2017, at 3:47 PM, Kathleen Moriarty <[e-mail]> wrote:
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> There are also some privacy issues associated to leaking names outside the
> homenet boundaries. For example daniel_smith.home.arpa reveal the identity of
> the member of the homenet, my_ipad.home.arpa reveals the devices you own, the
> application.
> 
> home.arpa may also used in larger environment such as corporate / private.
> going from one to the other may also leak such information.
> 
> The leak can be from the homenet to the outside world in which case one neeed
> to control the queries sent. But in intruder (or guest) may also access the
> homenet and proceed to discovery of the names. As a result even though homenet
> is believe to be a trusted environment, care should be considered while
> publishing under the home.arpa. as well as whose the information is accessible
> to.

The only sense in which the homenet is considered to be a trusted environment is that we have no choice but to treat it as if it were in some sense isolated from the global internet.   It is absolutely true that any device that gains access to the homenet can enumerate all published names.   The cure, which is well known, is to not publish names that expose private information.   The dnssd working group has developed a solution to this problem: https://tools.ietf.org/html/draft-ietf-dnssd-privacy-02 <https://tools.ietf.org/html/draft-ietf-dnssd-privacy-02>

This doesn't work for printers.

Use of home.arpa in environments other than home networks is not being recommended in this document, and hence the mention of that as an issue seems like a non sequitur.

> They might be collision as well. myprinter.home.arpa may be found in various
> environments, and upon discovery you may also - in this example - print
> confidential information to that printer. In some case you may not even be
> aware, for example, if your printing information failed home, and is
> re-activated once you are in another environment.

I think what is meant here is that if you are at home and have a printer named "myprinter.home.arpa." and then later on you are at someone else's home, or at a malicious coffee shop, there might be a printer there also named "myprinter.home.arpa.", that there is no way to detect this problem.   This is true, but by no means a new problem.   This problem is already explicitly called out in the security considerations section, so I don't think additional text is needed.   If you think that example text is needed, I can add that.

This is a problem we very much want to solve.   If you look at  https://datatracker.ietf.org/doc/draft-sctl-service-registration/?include_text=1 <https://datatracker.ietf.org/doc/draft-sctl-service-registration/?include_text=1> you can see that we are working on this.   A device that does service registration generates a public/private key pair and uses the public key to defend its ownership of the name; what is important about this is that you can tell the difference between two printers with the same name by looking up their public key, and you can in principle use that key to authenticate the printer when you connect with it via TLS.   So if you roam to a home that has a printer with the same name as your printer, an API that understands the registration protocol will not mistakenly connect to that printer as if it were the same printer.

Unfortunately this is not current practice, and it will probably be years before it _becomes_ current practice, but we are doing our best to create the infrastructure that will allow this to happen.   Making non-actionable statements about it in this document doesn't seem like a good idea when we are doing real work to actually solve the problem.   The purpose of this document is simply to allocate the name and document its use under RFC 6761, not to exhaustively define the architecture in which that name will be used.

> As information may be sensitive it may be encrypted using IPsec DTLS as
> described by dprive for both authentication and confidentiality.

This is an example of what I mean by a "non-actionable statement."   There is no way to establish authentication using a PKI trust anchor under home.arpa, so this statement is not in any way actionable at present; recommending that readers do this is simply telling them to go on a wild goose chase.

> When the trust anchor is configured in the resolver, these must be able to
> roll-over the key and should follows the requirements for DNSSEC validators. if
> it is impossible for a resolver to see the difference between an attack and a
> re-key we are in trouble.

This statement is similarly not actionable (in this document).   There is at present no trust anchor.   There can't be.   We are talking about an extension to validating resolvers that know about home.arpa that will make it possible to tell which homenet you are on in much the same way that the registration protocol I referenced earlier.   Making sure that we correctly handle the re-keying problem is definitely a good idea, and one that I hadn't thought of yet, but it's not something we could possibly address in _this_ document.