RE: [Cfrg] Re: [saag] Algorithm upgrades

[Stephen Kent <kent at bbn.com>]

At 5:09 PM -0800 11/1/04, Hallam-Baker, Phillip wrote:
>  >1. _New_ protocols that are being design should include the ability to
> > negotiate algorithms. This is just good hygiene. If this is not
> > formalized, it should be.
>
> I strongly disagree. History has showed that negotiation mechanisms can lead
> to worse security problems than they are meant to address. The IETF has
> certainly showed an exceptional ability to overcomplicate them.
>
> What we need is a policy layer for the whole application protocol layer
> stack. It should not be part of the individual protocols, it should be part
> of the DNS.

I'm not convinced that the choice of algorithm, modes, key length, 
etc. is always an application decision.  One may want to impose 
constraints on algorithms in a more secure context than that provided 
by an application. Also, the role of the DNS in this context is 
questionable, and may be in conflict with your application layer 
negotiation. Protocols like e-mail  where there is no realtime 
ability to negotiate security parameters, could benefit from some 
form of directory advertisement of algorithm capabilities, but 
primarily for encryption. (If I send a signed message to a bunch of 
folks, I may not want to check to determine what algorithms each 
recipient supports, to add signatures to accommodate all of them.) 
Selection of mandatory defaults makes interoperability generally 
viable in the absence of posted algorithm capability schemes. Also, 
making algorithm capabilities known via DNS requires an ability to 
update DNS entries, and if one really wanted to do this on an 
individual basis, it would require more user access to DNS data than 
we typically support today, which could cause all sorts of problems 
for both users and DNS administrators.

Steve

_______________________________________________
Cfrg mailing list
Cfrg at ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg