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

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 18 Mar 2003 10:35:46 -0800

One *nit* spotted in the security considerations section:

The security considerations section should reference the search path
issue mentioned in section 2.2. It may also be good to recommend that
clients using this get their DNS client configuration, including
search path, from a trusted source, and that DHCP likely does not
provide sufficient protection..

I think this can be respun without another WG last call.

					- Bill

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 20 Mar 2003 01:42:27 +0100 (CET)

we suggest the following changes.

	jakob

@@ -304,7 +304,14 @@
    <t>
     As stated in <xref target="policy"></xref>, we recommend that SSH
     implementors provide a policy mechanism to control the order of
-    methods used for host key verification.
+    methods used for host key verification. One specific scenario for
+    having a configurable policy is where clients use unqualified host
+    names to connect to servers. In this case, we recommend that SSH
+    implementations check the host key against a local database before
+    verifying the key via the fingerprint returned from DNS. This
+    would help prevent an attacker from injecting a DNS search path
+    into the local resolver and forcing the client to connect to a
+    different host.
    </t>

    <t>

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 20 Mar 2003 00:48:01 -0500

<wg chair hat off>

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).

Also, the security of SSHFP records depends on the client being
properly configured as a secure DNS client; exactly what is required
to do this are out of scope for the SSHFP document but some methods
are described in references [4] and [9].

						- Bill

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 20 Mar 2003 07:13:02 +0100 (CET)

> trusted source (i.e., not from DHCP or PPP/ipcp).

or one could just acknowledge that DNS search paths are evil.

	jakob

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 20 Mar 2003 09:54:26 -0800

<wg chair hat off>

> or one could just acknowledge that DNS search paths are evil.

I think it's unreasonable from a usability standpoint to require that
users always type FQDN's rather than shorter name forms..

					- Bill

---

From: Jakob Schlyter <[email-masked]>
Date: Fri, 21 Mar 2003 00:28:03 +0100 (CET)

On Thu, 20 Mar 2003, Bill Sommerfeld wrote:

> 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?

	jakob

---

From: wes <[email-masked]>
Date: Thu, 20 Mar 2003 15:39:34 -0800

On Thursday, March 20, 2003, at 03:28 PM, Jakob Schlyter wrote:

>> trusted

I don't think the implementation can ensure that. However, the users of 
the client system can ensure that by manually coding a DNS search path 
that doesn't get over-written by DHCP.

-- 
wes / [email-masked] / 000f1a2f

---

From: Darren J Moffat <[email-masked]>
Date: Thu, 20 Mar 2003 15:48:38 -0800 (PST)

> that doesn't get over-written by DHCP.

I doubt very much that normal users can do any such thing. On most
systems DNS configuration is system wide, not per user.
Most users don't even know what DNS is (and they shouldn't really need to).

The administrator of the system may be able to do what is suggested -
but it depends on the OS and how it deals with DHCP.  It also depends on
what APIs will be available for DNSSEC and/or normal DNS.

Clever users with use of LD_PRELOAD (and its equivalent if it exists) on
UNIX like systems might be able to do what was suggested.

-- 
Darren J Moffat

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 21 Mar 2003 00:18:54 -0500

> 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..

					- Bill

---

From: wes <[email-masked]>
Date: Mon, 24 Mar 2003 11:29:24 -0500

> 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

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 24 Mar 2003 14:28:21 -0500

[wg chair hat off]

> 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. 

Good.

>       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.

I'd say "No way with current DNS lookup API's to tell.." instead of
assuming that this will be true for all time..

					- Bill

---

From: wes <[email-masked]>
Date: Mon, 24 Mar 2003 14:37:41 -0500

> assuming that this will be true for all time..

Yep, sounds good. I'll make the change.