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

From: <[email-masked]>
Date: Fri, 26 Jan 2007 10:31:07 -0800

I don't see any choice. TLS Evidence has to become a work 
item. This is not to say I support the particular technical 
approach: but the initiative is appropriate, addressing with 
technical means both data retention (corporate wiretapping 
obligations) and the way in which regulated ESIGN sites are 
applying https and SSL in practice.

----- Original Message -----
From: <[email-masked]>
To: "Steven M. Bellovin" <[email-masked]>
Cc: "Omirjan Batyrbaev" <[email-masked]>; <[email-masked]>
Sent: Thursday, January 11, 2007 12:49 PM
Subject: Re: [TLS] Please discuss: 
draft-housley-evidence-extns-00<

>> In any event, your analysis and conclusions are wrong.

I've been following up the claim. Specifically, the claim 
that its all wrong (the implication being its peter 
bullshit...) And the facts are more interesting that I first 
thought - mostly because of some new features of IE7 (and 
vista).

I've (re)found two https sites that require custom 
https-plugins or custom https browsers. Each have 
(ESIGN-citing) site policies that assert that the 
plugin/custom-app is the "secure signing device" required by 
ESIGN. One uses a MSN Money plugin to web-browser (or the 
MSN Money application), and the other example used a 
scripted quicktime plugin. Both, plugins interacted with 
(regulated) financial sites, where specific policies were 
disclosed concerning "writings".

Of course, the whole thrust of ESIGN was to define that 
records (such as electronic signature (including the digital 
variety)) can constitute "writings" - despite the 17th 
Century laws being phrased in old-fashioned media terms 
(paper, pens, handwriting, etc). The (legal) nature of any 
writing, ESIGN variants included, continues to demand that 
they must be reduced to tangible form; that requirement does 
not go away, for electronic records/signatures.

In the case of SSL-based signatures, from custom https 
plugins (with their assured trust models and CAs etc), that 
form has to be the server-side audit trail itself - the 
packets, the TCP fragments, the SSL ciphertext, its 
cleartext handshakes, or the http data within. TLS Evidence 
is on the right track, as are other means of exploiting the 
SSL handshake to preserve (and optionally secure) the 
"recordation" act.

One of the cuter features of the modern IE7 browser, and 
vista OS, concerns its support for handling the trusted 
path. One notes from sites that exploit Microsoft own 
CardSpace (federation) layer 5/6/7 identity technology that 
certain critical security operations can now CONTROL the UI: 
presumably to ensure the trust path policy control is in 
effect.

On non-vista reference monitors, IE7 also provides a lower 
assurance version of the same path property. It allows 
HTML/javascript to control the webpage UI, specially. Here, 
something that looks like a "Popup" can be visualized by the 
browser engine instance, whose own rendering backgrounds the 
main page post its page-level rendering. This 
"backgrounding" prevents one from interacting with the 
details material (in any normal sense). Upon clicking the 
http(s) button link in the only party of the page that is 
not-backgrounded, end-user control is resumed - allowing one 
to interact with the page. This all represent a nice "secure 
signing device" in its own right, contrasting with earlier 
generations of plugin-based soft-signing devices. Whether 
the control release the UI based on the response from the 
server or not (e.g. a signed xml msg, or a new https 
sessionid value with a receipt-mac within), is a matter for 
further investigation.

Of course, "secure signing" device is a legal convention, 
not a technical security claim; it is that which merely 
satisfies the legal definitions in ESIGN. It embodies what 
lawyers require when addressing the obligation to ascertain 
the intent of the parties and their consumer consent, when 
using electronic signatures in important transactions 
requiring "writing protocols".

I don't see any choice. TLS Evidence has to become a work 
item. This is not to say I support the particular technical 
approach: but the initiative is appropriate, addressing with 
technical means both data retention (corporate wiretapping 
obligations) and the way in which regulated ESIGN sites are 
applying https and SSL in practice. 

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

---

From: Nelson B Bolyard <[email-masked]>
Date: Fri, 26 Jan 2007 10:45:33 -0800

> applying https and SSL in practice.

I still have not heard a convincing case that this stuff belongs in TLS.
There doesn't seem to be consensus in the WG that it belongs in TLS, either.

So far, the arguments for putting this into TLS seem to be:
- we want this to be ubiquitous
- TLS is ubiquitous, and TLS already does crypto, so
- we should shoe-horn this into TLS.

One imagines that the same logic COULD have been used by the SSL/TLS
inventors years ago.  They could have argued:

- we want SSL/TLS to be ubiquitous
- TCP is ubiquitous, and already does transport, so
- we should shoe-horn TLS into TCP.

I'm glad they didn't.  The same objections that one might have to
putting TLS into TCP apply now, to putting signature-based evidence
collection into TLS.

-- 
Nelson B      (mozilla TLS implementor)

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 27 Jan 2007 14:15:08 +1300

>There doesn't seem to be consensus in the WG that it belongs in TLS, either.

I've already pointed this out before, why not make it an Experimental RFC?
That's exactly what they're there for.

Peter.

---

From: "Omirjan Batyrbaev" <[email-masked]>
Date: Fri, 26 Jan 2007 21:01:46 -0500

see:
----- Original Message ----- 
From: "Peter Gutmann" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, January 26, 2007 8:15 PM
Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00<

> That's exactly what they're there for.

Speaking of Experimental RFC - is it allowed to have an Intellectual
Property in them (or not to surender any of it to IETF)? And what it takes
to be Experimental RFC?

-Omirjan

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 27 Jan 2007 15:21:21 +1300

"Omirjan Batyrbaev" <[email-masked]> 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.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sat, 27 Jan 2007 17:18:11 -0500

On Fri, 26 Jan 2007 21:01:46 -0500
"Omirjan Batyrbaev" <[email-masked]> wrote:

> Property in them (or not to surender any of it to IETF)? And what it
> takes to be Experimental RFC?
> 

You never have to surrender intellectual property to the IETF, and you
can include it in an RFC.  *But* -- you must disclose any IP interests
immediately.  See https://datatracker.ietf.org/public/ipr_disclosure.cgi
More generally, see RFC 3979 and 3669.  (Note: those rules apply to
IETF RFCs, whether standards track, Informational, or Experimental.
Contact the RFC Editor for rules on indidvidual submissions.)

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: <[email-masked]>
Date: Sat, 27 Jan 2007 20:51:00 -0800

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" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, January 26, 2007 6:21 PM
Subject: Re: [TLS] Please discuss: 
draft-housley-evidence-extns-00<

---

From: Russ Housley <[email-masked]>
Date: Sun, 28 Jan 2007 02:39:56 -0500

Peter:

The TLS IANA rules require a Standards-Track document to allocate the 
content type number.

Russ

---

From: <[email-masked]>
Date: Sun, 28 Jan 2007 08:26:44 -0800

We need a private range for TLS extensions, then. But, this 
would require IESG review of an update to a standards track 
document. Lets not bother with that lio.

Or, we introduce immediately introduce an extension with 
value .next, whose specification says: anyone can use this 
as a basis for experiment. This Private extension MUST be 
used with a ciphersuite declared in the private range of 
ciphersuites.

Nothing prevents a private community declaring private 
ciphersuite X is identical with RSA_RC4_MD5.

----- Original Message -----
From: "Russ Housley" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, January 27, 2007 11:39 PM
Subject: Re: [TLS] Please discuss: 

> Peter:
>
> The TLS IANA rules require a Standards-Track document to 
> allocate the content type number.
>
> Russ
>

---

From: Martin Rex <[email-masked]>
Date: Mon, 29 Jan 2007 17:20:43 +0100 (MET)

[email-masked] wrote:
> obligations)

As I previously indicated, according to the Danvers Doctrine,
the IETF does not put key-escrow or wire-tapping into its own
protocols.  Labelling it as "corporate" instead of "national"
doesn't make it any better.

> disclosed concerning "writings".

Where is your problem?

I think that is an appropriate approach.
We have been shipping a frontend signing component with our
App frontends for 10 years.

TLS Evidence would only be a very small fraction of a solution,
and the problems it creates are magnitudes harder than the small
fraction of the problem it claims to solve.

Providing the plugin(s), even for several different platforms
is easy.  Builing up a PKI, securely issuing PKI credentials
to users and providing a trusted visualization device are
the difficult things.  TLS Evidence doesn't solve any of
that, but adds many serious new problems.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 29 Jan 2007 17:24:46 +0100 (MET)

> That's exactly what they're there for.

I'm violently opposed to that.

TLS Evidence has many problems that are beyond fixing, because of
how it is architected and probably because it needs these for
its hidden agenda.

All suggestions of how to use TLS Evidence in the applications space
are so ridiculously lame that I definitely do not want to see
TLS Evidence issued as an RFC, not even Informational.

-Martin

---

From: <[email-masked]>
Date: Mon, 29 Jan 2007 10:28:32 -0800

Sorry Galileo, said the Roman Inquisition: "Experiments must 
be pre-authorized by those with appropriate wisdom."

Heliocentrism, indeed. Ridiculously lame idea. Who knows 
where that one will lead... censure that thesis, along with 
all other protesting theses! Never let them even start to 
"follow the money" [renaissance/watergate]

We have to move on. Class C student Peter has his hands on 
$100 RIP2-capable 802.11i/802.1X gigabit 
router/switches/bridge/SPIfirewall, doing radius and EAP-TLS 
over PPPoE, with hardware IPSEC & GRE tunneling support. He 
and 14 year old Abdul Rahman XXVIth, son of the supermarket 
owner where they are sold, are both having fun configuring 
them to work with the TPM EAP-TLS module in their birthday 
Vista PCs, doing everything that research students were 
doing 10 years ago to (slowly) get higher assurance out of 
commodity technology - created mostly by that "evil" DoD 
hidden agenda: its COTS policy.

We cannot stop the experimenting. And should not try. Yes, 
there are lots of hidden agendas. What's new? They didn't 
stop us transforming PEM into the full spectrum key 
management world(s) that SSL now enjoys, did they? Start 
with grassroot-organized (crappy) security in software, and 
allow stepup to hardware assurance when some agenda has 
enough motivate to bother funding it, in some form. In that 
social process, educate a million users to administer the 
concepts ... and take charge of privacy issues for 
themselves, refining the  privacy concepts till they are 
workable - and no longer religious. Quite where it will all 
lead, we should not worry: a few million well-educated, 
empowered, well-fed people will sort that out for 
themselves.

Ive been attempting to move the debate away from some 
well-intentioned, but nontheless dubious protocol design, 
onto: could we perhaps just address the core 17th centry 
concepts that one author has indicated are behind the 
initiative, please: address the undeniable, "evidentiary" 
value of TLS _records_?

One assumes that the hidden agendas of those C17th law 
makers have worked themselves out by now.

Its pointless denying server-side sessionid caches are being 
raided, by police. Its pointless denying ethereal is used to 
decrypt stored streams. Its pointless denying that the SSL 
architecture facilitates such semi-covert practices, that 
are now mainstream; it has since day 1. What we CAN opt to 
do is turn it all around, and now do something useful with 
it (that also regularizes those actual practices, through 
normal social debate).

Now we can lead, or suppress. You get to chose your role, 
Inquisitor or Galileo, in the role play.

To: "Peter Gutmann" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, January 29, 2007 8:24 AM
Subject: Re: [TLS] Please discuss: 
draft-housley-evidence-extns-00<

---

From: Martin Rex <[email-masked]>
Date: Mon, 29 Jan 2007 19:58:35 +0100 (MET)

> hidden agenda: its COTS policy.

High assurance at that level is a non-issue for everyone except those
secret cellar dwellers.

The only purpose that it may serve is either abusive or
locking out (free and OpenSource) competition from entire markets.

One of the most serious security problems that we have on the
internet today is phising and trojaning.  TLS Evidence is going
to make that only worse.

An adequate solution to the Ecommerce stuff would be a standardized
application-level information exchange protocol for transfering
signature request, signed content and signature verification and
trusted / highly assured visualization&signing devices somewhere
between a mobile phone and OLTP (i.e. <$50).  That is the cheapest
and most foolproof approach, and will leave the PC software platform
entirely open for development and competition for everyone.

The rest of the COTS PCs and software will continue its constand
feature creep, and remain bug-ridden and virus&worm plagued for
more than a decade.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 29 Jan 2007 21:03:47 +0100 (MET)

[email-masked] wrote:
> management world(s) that SSL now enjoys, did they?

But that is very far from what really happened.

The IETF didn't transform PEM into PKI.  SPKI was an IETF approach,
but it seemed to have died down (OpenPGP and SSH do their own formats).

What happened was, that after the OSI communication protocols had
failed miserably in the marketplace, many of the participants of
the OSI/ISO standards organization started staffing IETF working
groups and with pretty complete Proposals (X.509, SSL, S/Mime)
and tried to prevent the IETF from killing further of their existing
work as well.

A lot of stuff in PKI X.509 is complex bloat and burden, and impairs
interoperability for political or business model purposes, and not
for its technical merit.

One of the cumbersome legacy problems resulting from this approach are
the X.500 distinguished names, which are equally unusable for humans
and software.

The XMLsig guys seemed to have realized that problem too far down the road
(stringified distinguished names may be pretty to look at, but close to a
dead-end road for futher PKI processing), so the SubjectKeyIdentifiers
had to be invented and retrofitted later.

-Martin

---

From: Russ Housley <[email-masked]>
Date: Mon, 29 Jan 2007 15:55:17 -0500

>had to be invented and retrofitted later.

You look at the world differently than me, and that is okay, but I 
feel a need to correct this historical inaccuracy.

Subject key identifiers were added to CMS by me.  They were not in 
PKCS #7 as specified by RSA Labs.  They first appeared in 
draft-ietf-smime-cms-10.txt in December 1998.  They were added in 
recognition that the combination of issuer name and serial number was 
quite large.

This was long before XMLDSIG effort got under way.  The -00 draft 
XML-Signature Requirements document appeared in June 1999.

Russ

---

From: "Peter Williams" <[email-masked]>
Date: Mon, 29 Jan 2007 14:45:13 -0800

all i can really do to respond to that, apart from arguing too recent history, is to cite my actual operational choices today.

i have about 100 users a second doing federated logon, using saml blob exchanged between the two endpoint. Today, i sign/verify the saml using xmldig, as it makes an evidentiary record. I could configure the servers to use tls to exchange the same saml blob, unsigned. But today i lose the evidentiary semantics that the xmldig handshake adds to my audit trail.

if i had tls evidence, i could use the tls variant binding, passing the saml blob in a ticket (peter's solution, today, leveraging existing stds) or in a tls evidence exchange of some form, tomorrow.

-----Original Message-----
From:	"Martin Rex" <[email-masked]>
Sent:	Monday, January 29, 2007 8:03 PM
To:	"[email-masked]" <[email-masked]>
Cc:	"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject:	Re: [TLS] Please discuss: draft-housley-evidence-extns-00<

-Martin

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 29 Jan 2007 17:53:00 -0500

-----Original Message-----
From: Martin Rex [mailto:[email-masked]]

> The IETF didn't transform PEM into PKI.  SPKI was an IETF
> approach, but it seemed to have died down (OpenPGP and SSH
> do their own formats).

Both PEM and S/MIME are email security applications
that use an infrastructure, as opposed to local interaction,
for key and identity management.  Neither PGP keys (in the
days of keysigning parties, before keyservers) nor SSH keys
qualify as "infrastructure" products generated by public
utilities and consumed by the public.  SPKI is not an
identity-based PKI at all, it is a privilege management
scheme that uses keys as principals.  The claim that PEM
was not the sole IETF predecessor of PKIX (and S/MIME)
is based on what sequence of events and RFCs?

> What happened was, that after the OSI communication protocols
> had failed miserably in the marketplace, many of the participants
> of the OSI/ISO standards organization started staffing IETF
> working groups and with pretty complete Proposals (X.509, SSL,
> S/Mime) and tried to prevent the IETF from killing further of
> their existing work as well.

The idea that RSA's PKCS-7, on which RSA's trademarked
S/MIME was based before being submitted to the IETF, originated
with OSI/ISO, is simply bizarre.  Same for Netscape's SSL.
What planet are you living on? 

> A lot of stuff in PKI X.509 is complex bloat and burden,
> and impairs interoperability for political or business model
> purposes, and not for its technical merit.
>
> One of the cumbersome legacy problems resulting from this
> approach are the X.500 distinguished names, which are equally
> unusable for humans and software.

Do you believe that DNS names, RFC822 names and IP addresses
are reasonably usable by humans and software?
Do you believe that the X.509 Subject Alternative Name extension
is politically-motivated bloat with no technical merit?

Certainly X.500 directory names based on a legacy DIT
are cumbersome.  But the X.509 syntax permits both simple and
complex names to be represented as appropriate to the business
at hand.  It is a failure of imagination among profile authors,
not IETF's use of X.509 syntax, that results in difficult
distinguished names.  An "E" distinguished name, by itself,
is perfectly reasonable, as is (for its intended purpose) a
DN composed of C's, O's and OU's.  Mixing them together
creates a truly unpalatable mishmash, but X.509 cannot be
blamed for that any more than rope can be blamed for capital
punishment.

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 30 Jan 2007 13:20:10 +1300

Martin Rex <[email-masked]> writes:

>TLS Evidence has many problems that are beyond fixing, because of how it is
>architected and probably because it needs these for its hidden agenda.

Just for the record I agree that TLS Evidence is Wrong for all the reasons
already given, I was just trying to find some middle path.

Peter.

---

From: Martin Rex <[email-masked]>
Date: Tue, 30 Jan 2007 03:14:57 +0100 (MET)

> feel a need to correct this historical inaccuracy.

OK, I'm sorry.  Thanks for the clarification.
I just happend to read (parts) of the XMLsig spec and the
WebServices Security spec, and from one spec to the other,
issuer&serial for identifying the signer cert was basically
deprecated and subject key identifers were pushed significantly.

The problem with distinguished names is that they don't have a
canonical encoding, so while a binary issuer&serial still works
as a unique database key, the printable ones created by XMLsig
don't.

> recognition that the combination of issuer name and serial number was 

Distinguished usually aren't that long.

(well, unless stupid CAs are involved that treat the name a digital
 junkyard and put stuff in there that really doesn't belong there.
 When one of our customers wanted to get an SSL cert renewed,
 one particular (susidiary) of a well-know CA choked severely
 on the name components which it had added...)

Admittedly, a fixed short length for a subject key id looks attractive.
Unfortunately, they're not unique (re-newed and cross-certs), and
when you don't have the cert matching a subject keyid, you don't
have the slightest clue where to start looking.  Significant
added complexity with moderate added value.

> XML-Signature Requirements document appeared in June 1999.

The original XMLsig specification seems to prefer Issuer&Serial
for identifying the signer cert -- however due to the stringification
of the issuer name, lookup of the signer cert becomes somewhat difficult,
which might be the reason why WS-Security uses the subject key id
(and includes the entire cert). 

-Martin

---

From: Russ Housley <[email-masked]>
Date: Tue, 30 Jan 2007 20:35:42 -0500

>(and includes the entire cert).

Many, many things in XMLDSig are based on CMS SignedData.  The 
authors consulted with me several times during the development of the 
specification.

The issues that you raise are unique to XMLDSig.  They are not issues in CMS.

Russ