Re: [saag] Additions to RFC 3631?

["Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>]

The transition from one security solution to another one was already
mentioned at the Paris IAB technical plenary as a tough issue. (Looking
at IPv6 it seems that transition is in general a problem -- not only for
security.)

What surprised me with the presentations of the panel members was that
there are even new security problems introduced with the roll-out of new
solution solutions that interfere badly with existing deployments. Chris
Weber provided the example of CORS. 

Here is the pointer to the slides and the meeting minutes (in case
someone wasn't listening to the plenary):
http://www.ietf.org/proceedings/83/technical-plenary.html

In a nutshell, I agree with what you state below, Steve. I would just
extend it beyond cryptographic algorithms.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
Of
> ext Steve Crocker
> Sent: Monday, May 21, 2012 5:12 PM
> To: IETF Security Area Advisory Group
> Cc: Steve Crocker
> Subject: Re: [saag] Additions to RFC 3631?
> 
> I've been lurking and only following loosely, so I apologize in
advance
> if the following is off the mark.
> 
> I was pleased to see mention of RFC 4086 on proper implementation of
> random number generation -- I am proud to be one of the co-authors --
> but I thought the issue at hand is transition of crypto algorithms
when
> current algorithms become obsolete.  This is a problem that occurs in
> all protocols that use crypto algorithms, and in my opinion we have
> underplayed this in our designs.  Every protocol that uses crypto
should
> be designed with transition mechanisms built in -- and tested! -- on
the
> assumption the protocol will outlive the current set of crypto
> algorithms.
> 
> Whether we adopt a generic way of doing this across protocols or a
> specific way for each protocol is a matter of discussion.  If we can't
> come up with a way to do it in a uniform way, then it's ok with me to
> have a separate way for each protocol.  In any case, I think it's
> important -- no, that's not strong enough -- essential to have a way
of
> transitioning from current algorithms to future algorithms without
> disrupting service.  These transitions will usually take a fairly long
> time, five to ten years I think, so the process can be somewhat
relaxed.
> Relaxed does not mean undefined or vacuous.
> 
> Steve
> 
> On May 21, 2012, at 10:01 AM, Steven Bellovin wrote:
> 
> > As noted by others, RFC 4086 covers that.  It may also need
improving;
> I haven't reread it recently.  However, even a pointer to it is out of
> place in 3631bis.  3631 is about protocol mechanisms; 4086 is about
> implementations.  Mouse Mouse's suggestions are more in the domain of
> 3365, which is security design philosophy.  3631 says "if you want to
> put security into a protocol, here are the best choices we have
today".
> My question is whether or not that list should be changed.
> >
> > On May 21, 2012, at 3:20 04AM, Yaron Sheffer wrote:
> >
> >> And a short section on crypto-grade random number generation. I
would
> be glad to contribute it.
> >>
> >> 	Yaron
> >>
> >> On 05/21/2012 09:32 AM, Simon Josefsson wrote:
> >>> Steven Bellovin<[e-mail]>  writes:
> >>>
> >>>> Does anyone have any suggestions for additions or corrections to
> RFC 3631?
> >>>> It looks to me like it's held up pretty well, save for newer
> versions of
> >>>> some of the protocols.
> >>>
> >>> I think channel bindings ought to be discussed, as a simple way to
> bind
> >>> different layers together to avoid certain attacks.  It could be
> >>> discussed in the SASL or GSS-API section.  Further, I think EAP as
a
> >>> protocol should be included in the list of standard security
> mechanisms.
> >>>
> >>> /Simon
> >>> _______________________________________________
> >>> saag mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/saag
> >>
> >
> >
> > 		--Steve Bellovin, https://www.cs.columbia.edu/~smb
> >
> >
> >
> >
> >
> > _______________________________________________
> > saag mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/saag
> 
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag