Hi Stephen,

Sorry if I'm repeating myself -- I've already expressed the opinions
below, both at the mike and on the list.

> (a) work on simple naming

I think that this work should be stalled until we have an implementation
to play with and make some in vivo experiments.  (Experience shows that
the best way to break a protocol is to give an implementation to Dave.)

> (b) the drafts on handling names with help from your ISP.

I fear that these drafts are a bad case of complexity for the sake of
complexity (or perhaps a case of involving the ISP for the sake of
involving the ISP).  I still haven't seen a compelling argument that they
do solve a problem that a trivial end-to-end protocol wouldn't solve.
Back in July 2018, I wrote the following:

    This is a question that I've been asking since July 2014, and I still
    haven't received an answer I could understand.

Please see the thread starting on 18 July 2018:

    https://www.mail-archive.com/homenet@ietf.org/msg07012.html

> (We also have a chartered work item [4] on security that has seen no
> progress but you can comment on that as item (c) if you like;-)

Some pointers for the rare people who don't spend most of their leisure
time reading Internet-Drafts:

  - HNCP is based on DNCP, which includes a security mechanism designed to
    provide authenticity, integrity and confidentiality of the HNCP data:

        RFC 7525 Section 8

    I believe that this is implemented in hnetd.  (Yeah, Markus and
    Stephen did some remarkable work.)

  - Babel has two security mechanisms:

        https://tools.ietf.org/html/draft-ietf-babel-hmac
        https://tools.ietf.org/html/draft-ietf-babel-dtls

    There appear to be no standards-track key distribution and rotation
    protocols for either of OSPF, IS-IS, BGP or BFD (static keying seems
    to be the norm), so a natural question is whether HNCP could serve
    this purpose, or whether it would be better to use a dedicated key
    distribution and rotation mechanism.

  - RFC 3971 Section 6 says the following:

       To protect Router Discovery, SEND requires that routers be
       authorized to act as routers.  This authorization is provisioned in
       both routers and hosts.

    Since hosts don't participate in HNCP, it is not clear if HNCP can be
    used as a SEND trust anchor.  I believe there's the same issue with
    securing access the DNS stub resolver (DNSCrypt, DNS over TLS, etc.).

-- Juliusz

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to