RE: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to

"Kemp, David P." <DPKemp@missi.ncsc.mil> Thu, 11 January 2007 22:20 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H58HL-0006aP-07; Thu, 11 Jan 2007 17:20:11 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H58HJ-0006aE-I6 for tls@ietf.org; Thu, 11 Jan 2007 17:20:09 -0500
Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H58HH-0005Zs-9K for tls@ietf.org; Thu, 11 Jan 2007 17:20:09 -0500
Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id l0BMK4Gs012532 for <tls@ietf.org>; Thu, 11 Jan 2007 17:20:04 -0500 (EST)
Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Thu, 11 Jan 2007 17:20:04 -0500
Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Jan 2007 17:20:04 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to
Date: Thu, 11 Jan 2007 17:20:03 -0500
Message-ID: <FA998122A677CF4390C1E291BFCF5989066776E6@EXCH.missi.ncsc.mil>
In-reply-to: <200701112103.WAA03004@uw1048.wdf.sap.corp>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to
Thread-Index: Acc1xBWnsPUE/8FASISg4OATp6OduAABe6ZQ
From: "Kemp, David P." <DPKemp@missi.ncsc.mil>
To: tls@ietf.org
X-OriginalArrivalTime: 11 Jan 2007 22:20:04.0666 (UTC) FILETIME=[A4BBE1A0:01C735CE]
X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-14930000
X-TM-AS-Result: : Yes--7.339800-0-2-1
X-TM-AS-Category-Info: : 2:0.000000
X-TM-AS-MatchedID: : 147018-150567-139006-700073-139010-703366-702726-701618-701738-704034-702715-701827-708634-700833-702131-701455-106230-701305-121155-701220-702150-700975-703334-710375-703364-707361-703546-703788-703589-701927-121709-703076-704032-148050-20040
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc:
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org


-----Original Message-----
From: Martin Rex [mailto:martin.rex@sap.com] 
>>
>> In security, perfect has always been the enemy of the good.
>
> Perfect forward secrecy is an enemy of TLS Evidence, and
> I prefer the former by a significant margin. (I mean Perfect Forward
> Secrecy as a design goal of the entire system, not only as
> an isolated characteristic in the threat model for a particular
> network link).

You keep saying that, but please explain why data retained by
"network trace" components that log all levels of the protocol
stack is not an enemy of perfect forward secrecy.  If data is
retained, it is retained, regardless of whether a signature
exists to authenticate that data.

--------------
6.2. Storage Considerations

   Parties that choose to preserve a plaintext record of Application
   Data or Handshake Protocol messages for evidence verification at a
   later time must ensure must ensure that this data is not
   inappropriately disclosed by employing suitable physical protection
   or cryptographic mechanisms that are at least as strong as the
   selected TLS ciphersuite.

---------------

That's true enough, but isn't it just as true that parties that
choose to preserve plaintext records of *normal TLS sessions*
must apply the same level of protection?  When evaluating
secrecy as a design goal of the entire system, the same operating
policies (what data is stored where and for how long) must be
applied to signed evidence and to unsigned evidence, otherwise
a comparison between TLS extension and unextended TLS is
meaningless.

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls