RE: secsh-sftp-scp-uri draft

["Joseph Salowey" <jsalowey%cisco.com@localhost>]

> -----Original Message-----
> From: ietf-ssh-owner%NetBSD.org@localhost 
> [mailto:ietf-ssh-owner%NetBSD.org@localhost] On Behalf Of Heikki Nousiainen
> Sent: Thursday, August 28, 2003 10:00 PM
> To: ietf-ssh%NetBSD.org@localhost
> Cc: Joseph Salowey; 'Steve Suehring'
> Subject: RE: secsh-sftp-scp-uri draft
> 
> 
> On Wed, 20 Aug 2003, Joseph Salowey wrote:
> > > > 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.
> > > 
> > 
> > [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).
> 
> 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?
> 

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

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

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

> 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.
>
[Joe] A stale link will have the wrong fingerprint and they will not be
able to make a connection.  
 
> 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.
> 
[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.

> 
>  For what it's worth,
>   Heikki Nousiainen
>