Re: Security guidelines discussion in the IESG

[Sam Hartman <[e-mail]>]

>>>>> "Romascanu," == Romascanu, Dan (Dan) <[e-mail]> writes:

    >> -----Original Message----- From: Steven M. Bellovin
    >> [mailto:[e-mail]] Sent: Wednesday, April 26, 2006
    >> 4:14 PM To: Romascanu, Dan (Dan) Cc: [e-mail];
    >> [e-mail]; [e-mail]; [e-mail]
    >> Subject: Re: Security guidelines discussion in the IESG
    >> 
    >> On Wed, 26 Apr 2006 14:30:50 +0300, "Romascanu, Dan \(Dan\)"
    >> <[e-mail]> wrote:
    >> 
    >> >  
    >> > My instinct is to say that the security area need to issue a
    >> document > similar to what RFC 4181is for MIB reviewers. The
    >> security folks seem > to believe that this role is played by
    >> RFC 3552, and that the security > advisors for specific WGs
    >> would do the rest. In reality for raqmon > this did not work,
    >> and maybe other similar cases exist.
    >> >  
    >> Dan, could you give more detail on what's wrong with 3552?  As
    >> you say, we thought that 3552 was filling that role.
    >> 
    >> --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
    >> 

    Romascanu,> There are two problems that we have felt directly in
    Romascanu,> the case I was involved with:

    Romascanu,> 1. Just from reading 3552 (and other) it's hard at
    Romascanu,> least for a non-security person to figure out which
    Romascanu,> security feature requirements match the protocols to
    Romascanu,> use. In the RAQMON case, we ended up figuring out that
    Romascanu,> we didn't need SASL at all, just "mandatory TLS". The
    Romascanu,> confusion cost us about 5 months already and counting.
    Romascanu,> Some kind of a guiding document, including a mapping
    Romascanu,> table or matrix would be extremely useful.

Interesting.  So, I actually thought that 3552 served its purpose in
the raqmon case: the document correctly identified what security
threats needed to be addressed.  The only problem from my standpoint
was that the document stopped at saying that TLS could be used to
address the threats (a true statement) but did not go so far as to
normatively describe how to do so.

So, I think we may want to take a step back here.  I wonder if the
security community and you have a different idea of what problem 3552
is attempting to solve.

I'd argue that 3552 is mostly only trying to help you understand what
problems you need to solve.


I'd argue that RFC 3631 is intended to tell you about what security
technologies are out there, and that the documents defining those
technologies need to be responsible for helping you understand how to
use those technologies in your application.

There's also draft-iab-auth-mech, but according to its author, it is
intended more to help designers of security mechanisms than people
trying to use mechanisms in their protocol.