Re: [TLS] [POSSIBLE SPAM] Re: Collisions (Re: Nico's suggestions - Re: Consensus Call:

Marsh Ray <marsh@extendedsubset.com> Tue, 11 May 2010 20:22 UTC

Return-Path: <marsh@extendedsubset.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0ADE28C15B for <tls@core3.amsl.com>; Tue, 11 May 2010 13:22:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.774
X-Spam-Level:
X-Spam-Status: No, score=-0.774 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_20=-0.74]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YG8oMh7Ax0RP for <tls@core3.amsl.com>; Tue, 11 May 2010 13:21:53 -0700 (PDT)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 374723A6AA2 for <tls@ietf.org>; Tue, 11 May 2010 13:19:24 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1OBvv5-0005k2-Pg; Tue, 11 May 2010 20:19:12 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 9D788631D; Tue, 11 May 2010 20:19:10 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX18wj2WXcpUuofrcQmDwBstxMx7RXJh6C0w=
Message-ID: <4BE9BBC0.8070808@extendedsubset.com>
Date: Tue, 11 May 2010 15:19:12 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2
MIME-Version: 1.0
To: "Kemp, David P." <DPKemp@missi.ncsc.mil>
References: <20100510221531.GC9429@oracle.com><201005111339.o4BDdoYQ009725@fs4113.wdf.sap.corp> <20100511152153.GF9429@oracle.com> <201005111803.o4BI3fhO006065@stingray.missi.ncsc.mil> <4BE9AFA9.5070607@extendedsubset.com> <201005112005.o4BK54qO014241@stingray.missi.ncsc.mil>
In-Reply-To: <201005112005.o4BK54qO014241@stingray.missi.ncsc.mil>
X-Enigmail-Version: 1.0.1
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] [POSSIBLE SPAM] Re: Collisions (Re: Nico's suggestions - Re: Consensus Call:
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 May 2010 20:22:03 -0000

On 5/11/2010 3:04 PM, Kemp, David P. wrote:
> If there is a script to FTP a bunch of files, and one of the files
> fails, then either a human or a manifest-understanding application needs
> to notice the error and retry.  FTP itself doesn't have to be as
> persistent about recovery as wget, but something above it needs to be.

> How would FTPS with a cache collision induced failure be different?

I think that's the right question for us to be asking.

One way in which things are different is that this proposal introduces
the caching of long-term data. We have to ensure that a one-time
drive-by attacker cannot use the feature to cause the caching of
something that might adversely affect some unrelated operation in the
future.

We should also be careful to prevent data leaks. There is the potential
that server 'a' could engineer a probing collision to determine if
you've previously connected to server 'b'.

- Marsh