Early Review of draft-ietf-dnssd-mdns-relay-01
review-ietf-dnssd-mdns-relay-01-secdir-early-atkins-2018-12-27-00
Request | Review of | draft-ietf-dnssd-mdns-relay |
---|---|---|
Requested revision | No specific revision (document currently at 04) | |
Type | Early Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2018-12-05 | |
Requested | 2018-11-14 | |
Requested by | David Schinazi | |
Authors | Ted Lemon , Stuart Cheshire | |
I-D last updated | 2018-12-27 | |
Completed reviews |
Secdir Early review of -01
by Derek Atkins
(diff)
|
|
Comments |
Hello Security Area Directorate, We would love to have an early review of draft-ietf-dnssd-mdns-relay. We believe the document is in good shape as far as DNSSD goes (it's passed WGLC) but we're not security experts and would appreciate the extra scrutiny! In particular the protocol uses TLS and goes into detail about some TLS handling, and we want to make sure our authors got that right. Thanks, David Schinazi, as chair of DNSSD. |
|
Assignment | Reviewer | Derek Atkins |
State | Completed | |
Request | Early review on draft-ietf-dnssd-mdns-relay by Security Area Directorate Assigned | |
Reviewed revision | 01 (document currently at 04) | |
Result | Has nits | |
Completed | 2018-12-27 |
review-ietf-dnssd-mdns-relay-01-secdir-early-atkins-2018-12-27-00
Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving security requirements and considerations in IETF drafts. Comments not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: * Ready to publish, but nits remain Details: * The specific authorization details between the Client and Relay is elided. Specifically, how does a proxy get configured for specific client connections? The spec does say it needs to get configured (section 9), and talks at length about configuring the relay for the available networks, but doesn't say much else about how to authorize clients. * Can a Relay be a client to another Relay? It's unclear what would happen if someone tried to configure it that way; the specification does not talk to that possibility (or prohibit it), as far as I can tell. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant