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

[<[e-mail]>]

There has been a fair amount of support for experimental, 
when I look back over the thread. Assuming the authors could 
live with this, we could proceed, despite some clear and 
absolute "never-never-never votes". TLS WG could then lead 
the next generation of the privacy debate - moving privacy 
beyond black/white strong pairwise encryption claim into 
being a protocol for asserting "agreed limits for privacy 
expectations". This would enable SSL to get on with higher 
value transactions, and move beyond "SSL is great for $1000 
e-commerce - that is assured by visa cards anyways". I know 
in my industry this _is_ being called for, where the 
transactions are generally 500,000USD or more, and involve a 
whole slew of regulated activities and licensed parties who 
required higher assurance from https RECORDS than we have 
addressed to date.

I do think we would have to go back to basics tho. if the 
work item is accepted - starting with a requirement analysis 
and call for (competing) protocol designs - designs that can 
take into account wider understanding of various 
privacy/data-protection/data-retention regulatory regimes 
that must be taken into account.

And, we must distinguish between TLS Evidence and TLS 
Authorization. The spec as-is currently is a design that 
says to me: "create an infrastructure that enforces 
mandatory data retention in the US, controlling 
communication capabilities at the router based on testing 
for "voluntary" optin to that policy regime. If the 
challenged party rejects the policy optin, deny 
communications - to show the evidence retention subpoena is 
being complied with". This apparent ultimate focus of the 
current concept (TLS Authorization) needs to be separated 
out of the TLS Evidence. A separate work item should be 
sought, to justify a place for working on TLS 
Authorization - a control plane protocol that clearly 
distinguishes itself from TLS Evidence (a data plane 
service).

By starting with requirements, we would get back to 
(technical) evidence and its relationship to an enhanced 
privacy service, addressing such as the role of sessionid 
cache data retention, the new ticket data retention (and the 
role of MS key wrapping) and - similarly - 
ciphertext/cleartext data retention. Several other topics 
would probably need to get included.

If the work item is accepted, this could be some of the 
underlying work that a section of the working group would 
need to address and reduce to issue/requirement form., Then, 
folks can worry about which protocol elements shall 
represent/control/enforce/store information, at which layer: 
https-v2/higgins, or TLS1.x.


----- Original Message -----
From: "Peter Gutmann" <[e-mail]>
To: <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, January 26, 2007 6:21 PM
Subject: Re: [TLS] Please discuss: 
draft-housley-evidence-extns-00<

> "Omirjan Batyrbaev" <[e-mail]> writes:
>
>>And what it takes to be Experimental RFC?
>
> See http://www.ietf.org/u/ietfchair/info-exp.html, in 
> particular the
> Guidelines section which explain the Rules section:
>
> # If the IETF may publish something based on this on the 
> standards track once
>  we know how well this one works, it's Experimental. This 
> is the typical case
>  of not being able to decide which protocol is "better" 
> before we have
>  experience of dealing with them from a stable 
> specification. Case in point:
>  "PGM Reliable Transport Protocol Specification" (RFC 
> 3208)
>
> # If the document contains implicit or explicit 
> success/failure criteria, and
>  it's clear that the outcome can be used as the basis for 
> a recommendation to
>  the IETF community, it's Experimental. Case in point: RFC 
> 1797 "Class A
>  Subnet Experiment" which led to RFC 1879 "Class A Subnet 
> Experiment Results
>  and Recommendations"
>
> Peter.
> 

_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls