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

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 29 Aug 2017 12:47:02 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-homenet-dot-12: 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-homenet-dot/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for your work on this draft!  The SecDir review raised a few important
points I'd like to discuss that should be easy to resolve.  The first is adding
in privacy considerations in his comments for the Security considerations
section posted here for convenience (but a response to his full thread might be
best):

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.

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.

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

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.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The other comments raised by the SecDir review should get a response,
especially those on section 4 as there are some wording suggestions to better
clarify what is intended in the document.

https://mailarchive.ietf.org/arch/msg/secdir/E7fjRdo94abFW5nqjVBbLspvkww

---

From: Ted Lemon <[email-masked]>
Date: Tue, 29 Aug 2017 16:19:23 -0400

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

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.

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

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

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 29 Aug 2017 16:30:00 -0400

Oh, Daniel's comment on point 3 is correct, and I've already updated the text based on the gen-art review. :)