[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Idea: Prizes for protocol problems in key agreement
I like this idea. I would add to the "problems" list:
* Designs that can't be used for secure multicast applications
* Designs that support Key Escrow
* Designs that have only partial implementation
Alan
> From gnu@toad.com Thu Aug 22 05:50:04 1996
> X-Authentication-Warning: toad.com: Host localhost [127.0.0.1] didn't use HELO protocol
> To: ipsec@TIS.COM, gnu@toad.com
> Subject: Idea: Prizes for protocol problems in key agreement
> From: John Gilmore <gnu@toad.com>
> Sender: ipsec-approval@neptune.tis.com
> Precedence: bulk
> Content-Length: 2851
> X-Lines: 55
>
> Cliff Stoll's talk here at Crypto '96 mentioned that crypto is all
> about trust, and that trust comes from a process of suspicion,
> followed by scrutiny, followed by trust if no problems are found. You
> can also see this as a Quality Assurance procedure.
>
> Given the current state of IPSEC key agreement protocols, I am
> thinking it would be prudent to run a competition for people to
> scrutinize some candidate key agreement protocols (e.g. Photuris,
> SKIP, ISAKMP/Oakley, and whatever comes out of the smoke-filled room).
> I have a serious concern that we'll end up standardizing on a protocol
> that has not had the scrutiny required to validate its security. For
> this audience I need not point out that if the key agreement protocol
> is insecure or subvertible, it doesn't matter how strong our packet
> encryption is, nor how solid our public-key infrastructure is.
>
> I'm particularly concerned that Photuris has not had recent scrutiny,
> that ISAKMP/Oakley is sufficiently complex and new that it has not
> been fully defined or analyzed, and that the smoke-filled protocol, if
> any, will of course be new and need critical examination.
>
> EFF has recently decided that they want to help my S/WAN efforts to
> deploy IPSEC technology widely and rapidly. I'm thinking of funding
> prizes that EFF would offer for protocol problems found and posted to
> the IPSEC mailing list. The kinds of things that would qualify as
> "problems" include:
>
> * Revealing session keys or parts thereof to observers or attackers
> * Revealing private keys or parts thereof to observers or attackers
> * Enabling session keys to be forced to known or partly-known values
> * Inability to scale to daily use on the entire Internet
> * Revealing user identities to observers (if user keying is involved)
> * Failure to provide perfect forward secrecy for packet traffic
> * Enabling traffic to move in the clear which should be encrypted
> * Designs that are trivial to circumvent or bypass
>
> My current thought is that the "best" problems will win more money and
> glory, but that everyone who finds a legitimate problem (in the
> judges' opinion) will get some money and glory out of it.
>
> I hope that we can do something similar for some of the reference
> implementations, once the protocols are nailed down.
>
> There might be big money for the protocol authors here -- they can
> define buggy protocols and then collect by pointing out the problems!
> But I think the increased general scrutiny is worth that risk.
>
> Does anyone have objections to this kind of quality assurance process?
>
> Please give me your reactions and suggestions about this idea.
> Suggestions for a set of standards to judge the protocols against would
> be particularly useful. Also suggestions on the appropriate sizes,
> numbers, and categories of prizes, and potential judges.
>
> John Gilmore
> 'an equal opportunistic encryptor'
>
Message-Id: <3.0b11.32.19960823114911.00a68238@pop3hub.is.chrysler.com>
Reply-To: rgm3@chrysler.com
X-Sender: rgm3@pop3hub.is.chrysler.com
X-Mailer: Windows Eudora Pro Version 3.0b11 (32)
Date: Fri, 23 Aug 1996 11:58:14 -0400
To: Alan.Monday@corp.sun.com, ipsec@TIS.COM, gnu@toad.com
From: Robert Moskowitz <rgm3@chrysler.com>
Subject: Re: Idea: Prizes for protocol problems in key agreement
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
At 10:00 AM 8/22/96 -0700, Alan Monday-Internet Commerce Group wrote:
>I like this idea. I would add to the "problems" list:
>
> * Designs that can't be used for secure multicast applications
> * Designs that support Key Escrow
> * Designs that have only partial implementation
Designs that invalidate Key Escrow (in otherwords, escrow me all you want,
it does no good)?
Is this possible? It seems that man in the middle attacks are all that is
left to Key Escrow for some of these?
Is that adequate? If the key escrowers see that they have to launch man in
the middle attacks to see anything is this raising the cost enough to vastly
limit its use?
Robert Moskowitz
Chrysler Corporation
(810) 758-8212