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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 1 Nov 2004 17:09:55 -0800

>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.

	Phill

_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 02 Nov 2004 23:21:26 +1300

>stack. It should not be part of the individual protocols, it should be part

Hmm, time to dig out the policy issues quote... from an anonymous contributor
to PKIX, this being a reference to the UK comedy "Father Ted":

  Ted says that whenever he gets asked a religious question he doesn't
  understand he always responds with "Ah, that must be an ecumenical matter"
  which univerally produces nods of admiration at the profound wisdom of the
  statement. It seems that that the PKIX list equivalent is "Ah that must be a
  policy matter".

I believe that in both cases here "policy layer"/"policy matter" is being used
as a synonym for either "too-hard basket" or "someone else's problem".

Peter.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 02 Nov 2004 10:02:08 -0500

In message <[email-masked].

>stack. It should not be part of the individual protocols, it should be part

I'm very far from convinced that a single policy layer is feasible or
even desirable -- policies for individual applications will vary too 
much.  That said, I'm 100% certain that putting anything like policies
into the DNS is a bad idea.  The discussion in RFC 3445 outlines some 
reasons why this is a bad idea; I could go on about this at great 
length, but this is probably the wrong forum for that discussion.

		--Steve Bellovin, http://www.research.att.com/~smb

---

From: Stephen Kent <[email-masked]>
Date: Tue, 2 Nov 2004 13:34:43 -0500

>stack. It should not be part of the individual protocols, it should be part

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

---

From: Sam Hartman <[email-masked]>
Date: Tue, 02 Nov 2004 12:56:03 -0500

>>>>> "Hallam-Baker," == Hallam-Baker, Phillip <[email-masked]> writes:

    >> 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.

    Hallam-Baker,> I strongly disagree. History has showed that
    Hallam-Baker,> negotiation mechanisms can lead to worse security
    Hallam-Baker,> problems than they are meant to address. The IETF
    Hallam-Baker,> has certainly showed an exceptional ability to
    Hallam-Baker,> overcomplicate them.

I agree there are problems with negotiation layers.  

However so far they seem to be the only mechanism I've found that
work.  Can you explain how we would have handled the conversion from
DES to AES for IPSec in an alternate universe where all the protocols
worked as you desire?  I think that will help me understand what you
propose much better.

--Sam

---

From: James Hughes <[email-masked]>
Date: Tue, 2 Nov 2004 02:14:05 -0500

On Nov 1, 2004, at 8:09 PM, 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 

Well. We disagree then.

The only history of negotiation failures that I have seen is the GSM 
vulnerability where they put ECC under weak encryption and then used 
that same key for high strength, cracked the key, spoofed a base 
station, mounted a MIM attack and got in. Yes this is a protocol 
vulnerability with 2 (Doh!) stupid crypto mistakes. Was this caused 
because there was algorithm flexibility or because of other reasons? I 
would suggest that this is more about the other mistakes than about the 
fact that there were protocol vulnerabilities. If you have other 
examples, I'm all ears.

Keeping a protocol centered on the problem without the siren call of  
"feature creep" is not easy. It is this creep of "just one more feature 
cuz its a simple tweak" that, when compounded created a 
incomprehensible stew of incongruous kludges. If one can keep their eye 
on the ball, and is managed as a fundamental feature ( not an add on ) 
along with scalability and reliability, then it -is- possible to have 
algorithm flexibility.

Half of the IETF protocols are more complicated than the average IETF 
protocol.

Well, maybe we strongly agree. What we need is an ability to add new 
algorithms, remove bad algorithms with causing undue complexity to the 
user.

>  stack. It should not be part of the individual protocols, it should 

This seems like a policy punt. what are you suggesting and why?

Thanks

jim

---

From: "D. J. Bernstein" <[email-masked]>
Date: 5 Nov 2004 20:18:33 -0000

Sam Hartman writes:
> Can you explain how we would have handled the conversion from
> worked as you desire?

May I ask how the conversion worked in your universe, and exactly what
conversion costs were avoided by the negotiation mechanism?

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 05 Nov 2004 16:54:20 -0500

> conversion costs were avoided by the negotiation mechanism?

In our universe, we configured IPsec security gateways to accept both
AES and 3DES, then incrementally changed the preferred algorithm of the
clients. 

The conversion cost avoided was the need for a "flag day" during which
all clients needed to be changed simultaneously.

						- Bill