Re: IESG feedback on core drafts.

[Bill Sommerfeld <sommerfeld%east.sun.com@localhost>]

> Very nice.  There's one more point I want mentioned, aside from
> Bill's suggestions:  a caveat about the dangers of using forwarding
> (of ports, X11, or the authentication agent) to machines that
> aren't trustworthy.  (Some of that should, perhaps, be in -connect
> instead, since there's already related text.)

So, I'm wondering if it might make more sense to have a single set of
security considerations in the -arch draft, with pointers from the
other three documents.  Like most things security related, they cut
across functional areas, and I really don't want to waste time
trying to get all the hairs perfectly split.

> One more thing, and this is probably my own experiences talking:
> suggest that implementations provide a simple way for a logged-in
> client to retrieve the fingerprint of the host's key, as well as
> the stored fingerprint.  Furthermore, this should be done in a
> way that's hard for a MITM attacker to spoof.  The idea is that
> sometimes, you log in to a new machine -- but then you'd like to
> verify that the key you just accepted indeed matches what's stored
> on the new machine.  (Ideally, there's be something involving,
> say, the Interlock Protocol, but that's a job for a new document,
> not for Security Considerations in this one.)

Uhh.. my "mission creep" detector just went off...

I've been reminded that there are several vendors who are waiting for
these documents to come out as RFC's before casting an implementation
into firmware.  

Steve: if you feel strongly that this belongs in the documents, can
you provide sample text for this provision *this week*?

						- Bill