Re: WG chair nits on draft-ietf-secsh-dns-02.txt

[wes <wgriffin%jtan.com@localhost>]

On Friday, March 21, 2003, at 12:18 AM, Bill Sommerfeld wrote:

> > > An alternate approach which I think is superior is to ensure that the
> > > DNS search path used while resolving SSHFP records comes from a 
> > > trusted
> > > source (i.e., not from DHCP or PPP/ipcp).
> >
> > how can the ssh client implementation ensure that?
>
> The ssh client can't, but a system containing an ssh client could.
>
> Security considerations are not just for subsystem implementors;
> they're also for the users..

Agreed. I put this paragraph together last week, it addresses the 
search path concerns through configuration of the "system" instead of 
the implementation.

Index: draft-ietf-secsh-dns-xx.xml
===================================================================
RCS file: /cvs/sshdev/draft/draft-ietf-secsh-dns-xx.xml,v
retrieving revision 1.44
diff -u -r1.44 draft-ietf-secsh-dns-xx.xml
--- draft-ietf-secsh-dns-xx.xml 20 Mar 2003 00:42:42 -0000      1.44
+++ draft-ietf-secsh-dns-xx.xml 20 Mar 2003 23:31:06 -0000
@@ -315,6 +315,15 @@
    </t>

    <t>
+    A different approach to solve the DNS search path issue would be 
for
+    clients to use a trusted DNS search path, i.e., one not acquired
+    through DHCP or other autoconfiguration mechanisms. Since there is
+    no way for the DNS lookup APIs to tell whether a search path is 
from
+    a trusted source, the entire client system would need to be
+    configured with this trusted DNS search path.
+   </t>
+
+   <t>
     Another dependency is on the implementation of DNSSEC itself.  As
     stated in <xref target="auth"></xref>, we mandate the use of
     secure methods for lookup and that SSHFP RRs are authenticated by