Subject: secsh-sftp-scp-uri draft

From: Steve Suehring <[email-masked]>
Date: Wed, 20 Aug 2003 12:02:16 -0500

Hello,

Based on the emails over the past week, Joe and I (mostly Joe)  have
compiled a list of the issues and nits that need to be addressed with the
secsh-sftp-scp-uri draft so that we can redraft.

1.  Default port issue

Status:  Proposed change- "If the port is not included, the default port 
(22) is assumed."

2.  Specifying ciphers etc as parameters

Status: Looking for consensus.

3.  More formal SCP SFTP URL definition

Status: Looking for consensus.

4.  Multiple host key algorithms and fingerprints

Status: Looking for consensus.

5.  Security considerations in trusted vs. untrusted URLS

Status: I'll be revisiting the security considerations section but I'm 
wary of a slippery slope here.

6.  Nits

Status: Simon Tatham had some nits that I'll be addressing and I'll
probably find others as well.  ABNF references, for a reminder to me.

If there are other issues outstanding, please let me know.

Steve

---

From: Heikki Nousiainen <[email-masked]>
Date: Wed, 20 Aug 2003 21:01:46 +0300 (EEST)

Hello,

My few cents:

> Status:  Proposed change- "If the port is not included, the default port 

Sounds reasonable.

> 2.  Specifying ciphers etc as parameters

I fail to see the need for these. Client already has a list of preferred 
algorithms and server can dictate use of a specific cipher as the drafts 
stand.
Only place I can find this useful is when server wants to use a cipher not 
allowed by the default client policy (say, des or none). I'd be 
very wary allowing such action.

Educate me, if I've missed something.

[snip]
> 4.  Multiple host key algorithms and fingerprints

I'd like to see fingerprints removed from the draft. I think it's calling 
for trouble in a way of man-in-the-middle or impersonation attacks.

> 5.  Security considerations in trusted vs. untrusted URLS

Is there such a thing as trusted URL? I doubt it. Maybe the source can be 
verified, but there's no validity protection on the URL itself. Consider 
someone being able to post content on a trusted site. Or an attacker 
tricking some trusted user to send crafted URL in e-mail. An employee gone 
bad and sending a malicious URL.

It's hard to get it right, and in my opinion, the risks far outweigh the 
benefits (maybe some anonymous SFTP scheme?).

My suggestion:
Let the SSH/SCP/SFTP URIs be location pointers, and remove connection 
parameters altogether. Treat all URIs as 'untrusted' and let SSH handle
the decissions over connection setup.

 Best regards,
  Heikki Nousiainen

---

From: "Joel N. Weber II" <[email-masked]>
Date: Wed, 20 Aug 2003 17:42:19 -0400

> Status:  Proposed change- "If the port is not included, the default port 

I'd prefer to see something along the lines of ``If the port is not
included, the default port that is used when the user does not specify
a port is assumed.''  In particular, I would like the text to have the
property that if the ssh protocol were changed to support SRV in the
future, that ssh URLs would automagically start using SRV records when
the port is not specified, without needing to update the URL spec.

> Status: Looking for consensus.

I would like to see the URL scheme not provide a way to specify any of
the cihper etc parameters that were specified in the original draft,
because they facilitate downgrade attacks, and I don't think anyone
has argued that they actually would get any value out of using these
parameters.

> Status: Looking for consensus.

I have rather mixed feelings about this.

I do think if we are going to support host key fingerprints in URLs at
all, we should allow multiple fingerprints to be included, and we
should have an explicit algorithm identifier.

Are there any implementors who intend to implement the host key
fingerprints?  Do these implementors have confidence that they can
distinguish between trusted and untrusted URLs?  (Like, are there any
web browsers they're going to interact with that provide enough
information to determine this when passing a URL to the ssh client?
Or is there a reasonable expectation that browser APIs would gain this
functionality?)

If https://evil.example.com has a link to ssh://goodguy.example.com
where the ssh URL on evil.example.com's webpage has a fingerprint, is
that going to make things less secure than if we omit fingerprints
from the ssh URL?

Do we suspect that there are a non-trivial number of cases where
people can deal with getting for their web page an X.509 certificate
that is in some useful way certified, but they can't deal with getting
an X.509 certificate for their ssh server?  (I've seen fas.harvard.edu
be an example of being able to deal with X.509 for ``the web'' but not
for ssh, but this may be mostly a matter of poor documentation being
made available to the sysadmins, along with a lack of support for
certificates in at least one popular ssh implementation, although I
think the implementation they were using when I was paying attention
to this does support certificates.  In particular, their helpdesk
insisted that I was being too paranoid when I asked them for some way
to cryptographically verify their host key.  Eventually they sent me
completely unauthenticated mail with the fingerprint, but that didn't
really solve the problem I cared about the way I wanted it solved.)

(Also, I'm handwaving a bit in assuming that the web is always secured
using X.509, but at the moment, it basically is; I don't think my web
browser will do either krb5 or OpenPGP.)

---

From: "Joseph Salowey" <[email-masked]>
Date: Wed, 20 Aug 2003 22:28:06 -0700

<snip>

> Educate me, if I've missed something.

[Joe] I think there is plenty of consensus to remove this from the
draft.

> for trouble in a way of man-in-the-middle or impersonation attacks.

[Joe] Don't think that fingerprints in the URI make these problems any
worse.  I think they can actually help.  If I receive a URL in a signed
email from someone that I know I can rely on the fact that the
fingerprint is accurate.  If I have a web page with a list of SSH URLs
that is delivered over a secure connection from a trusted source then
the fingerprints in the URIs are very useful.  If the finger print
doesn't match then I know there is a problem (see below).

> bad and sending a malicious URL.

[Joe] You are correct in that trusted URLs do not exists, but trusted
sources do.  It is entirely possible that a trusted source is
compromised, that is why the URL should never overwrite a locally
configured fingerprint.  If you don't have a locally configured finger
print then the URL information is better than nothing at all. However
there is probably danger in the automation of the connection.

If for example an SSH client by default puts up a message that says
"host key for server x is gobble-gobble-gobble and is not in you
database do you want to connect?" when invoked without a URL and doesn't
put up a message when it is invoked by a URL then there could be a
problem since currently there really is no way for the client to know
the source of the URL.  

If the key matches it probably should by default put up a message like
"host key for server x is gobble-gobble-gobble and is not in your
database, however it matches the fingerprint in the URL, do you want to
connect?"   

Even better if the fingerprint in the URL does not match the host key
and there is no locally configured value you can refuse to connect by
default "The host key for server x does not match the fingerprint in the
URL and is not in the local database so the connection is not allowed."

I think this provides value.  Perhaps the security considerations should
instead give some guidance along these lines.  

> parameters altogether. Treat all URIs as 'untrusted' and let 
> SSH handle the decissions over connection setup.
> 
> 
>  Best regards,
>   Heikki Nousiainen 
>

---

From: Jon Bright <[email-masked]>
Date: Thu, 21 Aug 2003 08:52:14 +0200

> the port is not specified, without needing to update the URL spec.

Perhaps "If the port is not included, the port should be as specified in 
[SSH-TRANS] (section 3.1)"?

-- 
Jon Bright
Silicon Circus Ltd.
http://www.siliconcircus.com

---

From: Heikki Nousiainen <[email-masked]>
Date: Fri, 29 Aug 2003 07:59:59 +0300 (EEST)

> doesn't match then I know there is a problem (see below).

Both e-mail and web page could have the fingerprint next to the URL. Maybe 
it could be easier to just click the link, but again, is it worth it? The 
trust is very hard to get right, especially when jumping from the domain 
of email client or web browser. What about SSH clients, would the client 
have to keep list of applications it trusts to pass trusted URLs?

Do you trust all the SSL certificates to hand out SSH fingerprints? I 
wouldn't. Same goes for e-mail, I'd probably end up verifying the sender 
by hand and then deciding whether I trust a fingerprint or not. I'm a 
strong advocate of KISS, and here I just don't see the justification for 
this feature. Remeber the hulabaloo over dsniff and SSH MITM attacks? I 
think inclusion of fingerprints in URL's has greater potential to lead 
into similiar issues.

I see your point about negative matches in URL vs. actual host key, but 
it could have problems as well: What if I happen to give a fingerprint 
that is for dsa key and client/server agree on rsa key? Links can become 
stale either by hostkey updates or different kex algorithms. I fear users 
might get a false sense of security from the information.

The idea itself is not bad, but I'm worried it's very difficult to get 
right. Complexity is potential for trouble, and I'm not convinced it's 
worth it in this case.

 For what it's worth,
  Heikki Nousiainen

---

From: "Joseph Salowey" <[email-masked]>
Date: Fri, 29 Aug 2003 08:20:26 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Heikki Nousiainen
> Sent: Thursday, August 28, 2003 10:00 PM
> To: [email-masked]
> Cc: Joseph Salowey; 'Steve Suehring'
> Subject: RE: secsh-sftp-scp-uri draft
> 
> 
> > worse.  I think they can actually help.  If I receive a URL in a 
> > signed email from someone that I know I can rely on the 
> fact that the 

[Joe] I agree that the concept of trusted URLs cannot be easily
determined or defined.  

> that is for dsa key and client/server agree on rsa key? 

[Joe] If the fingerprint does not match for any reason then the
reccomentation is to disallow the connection by default.

> Links 
> can become 
[Joe] A stale link will have the wrong fingerprint and they will not be
able to make a connection.  
 
> right. Complexity is potential for trouble, and I'm not 
[Joe] I think I understand your point and we debated this decided to
include it in the draft because we believe it has value.  I need to
rework the security considerations section to remove the 'trusted URL'
reference because that was a bad idea and focus more on the recommended
behavior of the client.  My hope is that will simplify things.