IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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?

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




Home | Main Index | Thread Index | Old Index