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<smb@cs.columbia.edu>  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
>>> saag@ietf.org
>>> https://www.ietf.org/mailman/listinfo/saag
>> 
> 
> 
> 		--Steve Bellovin, https://www.cs.columbia.edu/~smb
> 
> 
> 
> 
> 
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag