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

Martin Rex <martin.rex@sap.com> Thu, 11 January 2007 23:06 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H590I-0007mu-Sm; Thu, 11 Jan 2007 18:06:38 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H590H-0007mo-91 for tls@ietf.org; Thu, 11 Jan 2007 18:06:37 -0500
Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H590F-00076a-Sy for tls@ietf.org; Thu, 11 Jan 2007 18:06:37 -0500
Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id AAA12942; Fri, 12 Jan 2007 00:06:31 +0100 (MEZ)
From: Martin Rex <martin.rex@sap.com>
Message-Id: <200701112306.AAA04887@uw1048.wdf.sap.corp>
Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00 - use to
To: DPKemp@missi.ncsc.mil
Date: Fri, 12 Jan 2007 00:06:30 +0100
In-Reply-To: <FA998122A677CF4390C1E291BFCF5989066776E6@EXCH.missi.ncsc.mil> from "Kemp, David P." at Jan 11, 7 05:20:03 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
X-SAP: out
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: martin.rex@sap.com
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

Kemp, David P. wrote:
> 
> -----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.

The incentive factor.

Creating TLS Evidence has a significant higher cost that persisting it,
and as it is somewhere between fully unclear to impossible to interpret
the signed contents programmatically, there is a certain likelyhood
that someone how goes through the effort to create it will want to
persist it.  Remember, if it was _just_ about signature verification,
you could either use a secure channel bindings approach or just "sign"
a secure random challenge, depending on your exact requirements.

Although I generally dislike channel bindings, I think they are
a much better fit than TLS Evidence (at least for the IETF).

If you can get management to approve the cost of having it
after having convinced them how useful and valuable digital
signatures on the entire communications  may turn out to be
(e.g. for lawsuits), that management might want that
expensive TLS Evidence to be retained/archived.


Probably everyone will agree that retaining a full network level
trace is most often a waste of resources.  Unfortunately,
the TLS Evidence blob is an all-or-nothing thingy with the lowest
possible signal-noise-ratio.


-Martin


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