Re: IESG feedback on core drafts.

["Steven M. Bellovin" <smb%research.att.com@localhost>]

In message <200303161942.h2GJgsFJ001095%syn.hamachi.org@localhost>, Bill Sommerfeld write
s:
>> 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.

Always a reasonable option.  Will such a document appear in finite 
time?  The IESG is not fond of approving documents that say "see the 
following non-existent RFC for security considerations" -- but has 
often approved documents that point to existing documents for that 
information.
>
>> 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*?
>

I'll try -- and if I don't, I won't object to you shipping it the week 
after.  I'm certainly *not* suggesting that you design something based
on the Interlock protocol now.  In fact, I'd object you tried to...

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)