Subject: RE: Security guidelines discussion in the IESG

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 9 May 2006 12:49:19 +0100

The SIP WG is currently engaged in a number of drafts that relate to "How to use TLS in SIP". It would be nice to know that we do not have to address general TLS issues as part of that excercise. 

regards

Keith

> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]]
> Sent: 02 May 2006 16:55
> To: Sam Hartman
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Security guidelines discussion in the IESG
> 
> 
> Sam Hartman <[email-masked]> writes:
> 
> >>>>>> "Romascanu," == Romascanu, Dan (Dan) 
> <[email-masked]> writes:
> >
> >     >> -----Original Message----- From: Steven M. Bellovin
> >     >> [mailto:[email-masked]] Sent: Wednesday, April 26, 2006
> >     >> 4:14 PM To: Romascanu, Dan (Dan) Cc: [email-masked];
> >     >> [email-masked]; [email-masked]; 
> [email-masked]
> >     >> Subject: Re: Security guidelines discussion in the IESG
> >     >> 
> >     >> On Wed, 26 Apr 2006 14:30:50 +0300, "Romascanu, Dan \(Dan\)"
> >     >> <[email-masked]> 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.
> 
> Right.
> 
> A while back Steve asked me to write a "How to use TLS" document. It's
> on my plate, but kind of got stalled. I'll try to restart it.
> 
> -Ekr
> 
>