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

[Kathleen Moriarty <[e-mail]>]

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