Hiya, Given the level of list inactivity, it's actually really helpful that you took the time to re-tx those points!
One clarifying question below... On 08/03/2019 12:48, Juliusz Chroboczek wrote: > 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. Our (chairs), plan for that has been to try help the WG get the draft to the point where one would normally do a WGLC and to then hold off on that WGLC, waiting for the kind of implementation experience you mention. Given the level (i.e., lack) of engagement though, I'm wondering if that's still a viable plan, despite the good work Ted and others continue to do it this space. I'm not sure if by "stalled" you mean sticking with the plan above, or something else (e.g., for the WG to go entirely quiescent until the authors come back and claim the draft is done and have running code). Can you clarify? Thanks, S. > (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 >
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
