RE: [TLS] Please discuss: draft-housley-evidence-extns-00 (resend)

Stefan Santesson <stefans@microsoft.com> Thu, 21 December 2006 12:47 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxNKy-0005Zv-NB; Thu, 21 Dec 2006 07:47:52 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxNKx-0005Zq-F5 for tls@ietf.org; Thu, 21 Dec 2006 07:47:51 -0500
Received: from smtp-dub.microsoft.com ([213.199.138.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxNKv-0004WB-Tp for tls@ietf.org; Thu, 21 Dec 2006 07:47:51 -0500
Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.0.685.24; Thu, 21 Dec 2006 12:47:47 +0000
Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Thu, 21 Dec 2006 12:47:46 +0000
From: Stefan Santesson <stefans@microsoft.com>
To: Mark Brown <mark@redphonesecurity.com>, "tls@ietf.org" <tls@ietf.org>
Date: Thu, 21 Dec 2006 12:47:45 +0000
Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00 (resend)
Thread-Topic: [TLS] Please discuss: draft-housley-evidence-extns-00 (resend)
Thread-Index: Accjr+HsSWE6R2eZR0SIMuOXIpaeHwAAn9+gACTeRuAAAMk8IAAEMZKwACh0vHA=
Message-ID: <A15AC0FBACD3464E95961F7C0BCD1FF01AFB9FB5@EA-EXMSG-C307.europe.corp.microsoft.com>
References: <009201c7245b$192dbc00$6801a8c0@rps.local>
In-Reply-To: <009201c7245b$192dbc00$6801a8c0@rps.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0770535483960d190d4a0d020e7060bd
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

Mark,

> Thanks for your helpful comments.  I don't agree entirely with you,
> specifically your position that signatures are (must be?) application
> level constructs

I don't think I ever said that. I said that evidence is formed in an application context.

> Would the TLS WG be willing to extend the
> charter for evidence even if a large part of the discussion was hosted
> by a lawyer community and could take some time to hash out?
>

My vote is NO.

The legal and technical side of this can and must be separated. If the legal side wants to present some requirements for security properties, fine. But a security protocol must be defined on technical grounds for the security properties it brings. The technical community in IETF is quite capable of that. It is not capable of determining what a lawyers will accept or not accept in the hundreds of legal systems around this globe.

I agree with Ari, this protocol has potential, but only if we can isolate it to the technical discussion.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: Mark Brown [mailto:mark@redphonesecurity.com]
> Sent: den 20 december 2006 18:20
> To: tls@ietf.org
> Cc: Stefan Santesson; 'EKR'
> Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00
> (resend)
>
> Stefan, (resend, to tls@ietf.org, with additions to the first
> paragraph)
>
> Thanks for your helpful comments.  I don't agree entirely with you,
> specifically your position that signatures are (must be?) application
> level
> constructs, but you're probably in the majority on this issue.  My
> opinion
> is based on personal experience though.  I am working on a router
> project
> that uses TLS Evidence and Authorizations at the TLS level only:
>
> http://www.navysbir.com/06_1/215.htm
>
> The router works below the application-level and aims at high assurance
> under Common Criteria, e.g. EAL6.  Its design and implementation has
> been
> and will continue to be carefully scrutinized.  This project does not
> depend
> on "signer's intent" though, and perhaps intent is what you locate at
> the
> application level?
>
> I think you're right about this: the wisest choice may be to wait and
> see
> how things pan out in the legal community, and not try to extract a
> final
> answer from them too soon.  Would the TLS WG be willing to extend the
> charter for evidence even if a large part of the discussion was hosted
> by a
> lawyer community and could take some time to hash out?
>
> For those of you who are interested in the legal aspect of "evidence",
> I am
> currently engaged in conversation with the American Bar Association's
> Information Security Committee listserv.  If you would like to enter
> that
> discussion, please let me know.
>
> The ABA ISC discussion has recently rehashed the use of the term
> "evidence"
> with respect to TLS Evidence.  To summarize that discussion as fairly
> as I
> can, I think as long as one spells evidence with a lowercase "e" and
> not as
> Evidence or EVIDENCE the lawyers on the ISC listserv are comfortable
> with
> the term.  I also plan to work closely with the ABA Digital Evidence
> Project
> over the next year as well, and my first project with DEP is to hash
> out
> terms together.
>
> The following is a snippet -- really, a teaser -- for those of you with
> some
> inclination to join the ABA ISC group:
>
> (mark)
> > The TLS definition of "evidence" is unstated to allow it to flex with
> the
> > prevailing
> > definition in the legal world (this decade's definition or the
> next's).
> >
> > You say the definition of evidence is anything that can be "thrown
> into
> > the
> > pot", which seems reasonable to me.
> >
> (Steven Teppler)
> > > First, what is unknown is the definition of "evidence" as the
> technical
> > > protocol means it.  In the legal world, anything can be, and
> usually
> > > thrown
> > > into the pot as, evidence.  How is this specie of evidence
> different
> > from
> > > other evidence?
> >
> (mark)
> > TLS Evidence does not claim some special privilege e.g. being
> > non-repudiable.  It's just evidence like everything else in the pot.
> The
> > specter of duress is never eliminated, for example.  How could it be?
> > Neither does TLS Evidence claim any special privileges to magically
> gain
> > affirmatives to any of the following:
> >
> (Steven Teppler)
> > > Is EG'd evidence automatically admissible?  Does it
> > > automatically exclude contradictory digital data or testimony?
> Does it
> > > generate enough evidence to survive a summary judgment motion?
> Does it
> > > satisfy a burden of production?  Burden of persuasion?  If so, why
> isn't
> > > some modifier, such as "trusted evidence" or "summary judgment
> > eliminator"
> > > used?
> >
> (mark)
> > No thank you!  If a court chose to admit TLS Evidence into a trial
> then
> > that
> > court could examine it as a record like anything else.  The TLS
> Evidence
> > draft standard _only_ defines a minimum technical standard for
> security
> > measures including cryptographic/equality tests which must be passed
> > before TLS Evidence is "born".
>
> Best regards,
>
> mark


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