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

From: Peter Williams <[email-masked]>
Date: Tue, 19 Dec 2006 23:23:13 -0800

http://tech.groups.yahoo.com/group/ssl-talk/message/4767from a while ago.

> From: [email-masked]> To: [email-masked]; [email-masked]> Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00> Date: Wed, 20 Dec 2006 00:00:47 -0600> CC: > 
_________________________________________________________________
Type your favorite song.  Get a customized station.  Try MSN Radio powered by Pandora.
http://radio.msn.com

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

---

From: Peter Williams <[email-masked]>
Date: Wed, 20 Dec 2006 00:19:06 -0800

> > S A.> > Defining cipher suites with key lengths attached to them> > isn't hte TLS way.> > In this case, using poor crypto actually hurts your partner if you're the> one whose going to repudiate with evil intent. That's reversed from the> normal TLS model, and why TLS Evidence is stringent where TLS historically> has been able to be loose. Parties need to protect themselves by demanding> what they consider to be strong asymmetric crypto.
 
This one is funny. Both positions are untenable, cryptopolitically.
 
SSL was born with a 40-bit keylength-restricted ciphersuite-spoon in its mouth.  SSL became 
_world_ famous only because a Frenchman broke Netscape's low-end implementation in 3 days 
(overcoming low entropy seeding in the low end 40bit RC4 case), splashing the story all over the 
Wall Street Journal.
 
SSLv3 formalised protocols for creating ephemeral keys with "longer" length, provided that 
the resulting secrets  were provably bound to only  a particular connection - to compromise
with _legal enforcement regulations governing less restricted longer asymmetric keys lengths.
 
A bit in a certificate allowed servers to arm servers to offer longer length ciphersuites,
where only "export-accredited CAs" could issue such certs, whose assurance of authorized
issuer was tested/proved within the https process. (we got audited by the export authorities
for compliance against the required assurance standards we had promised; it wasn't pleasant.)
 
TLS from IETF itself standardized elements of ciphersuites SPECIFICALLY with key-length 
limited RSA! (more export legal _enforcement_ protocol design)
 
Conclusions:- 
 
SSL protocol design has always been about proving stuff, in both the cryptographic
and legal sense of meeting administrative law requirements (export regs). There is a 
perpetual clash here, between two classes of issues which collide in crypto-politics yet also
converge in that the both require the provability of the same assertions.
 
See, that had to be a silver lining in all the work to enforce export regulations, using crypto. 
We can now cite it, as endorsed, historical legal practice concerning TLS Protocol - by the 
executive branch of the US Federal Govt. no less!
 
Peter
_________________________________________________________________
Get into the holiday spirit, chat with Santa on Messenger.
http://imagine-windowslive.com/minisites/santabot/default.aspx?locale=en-us

---

From: Peter Williams <[email-masked]>
Date: Wed, 20 Dec 2006 00:45:25 -0800

> Why should we consider digital evidence a hard problem, a crypto protocol> problem, a TLS problem? One crucial issue was raised by Steven Kent last> year: the problem of the recording the signer's intent. Just to be clear,> "signer's intent" problems include not only the challenge of recording> something intangible, or the possibility that garbage data was signed, but> also claims that the system that created the digital signature was subverted> - or used with an intention to defraud. I'm a newcomer to this party, but I> don't think any previous standard solves this problem (I don't count the NR> bit as solving the problem). Let us know...
 
You have to be very careful in your crypto claims; NR has semantics limits. Its very 
easy to modulate the record length in TLS's fragmentation process to convey and recover 
certain cleartext signals communicated over the sideband of record lengths. 
 
Record length headers are not encrypted  normally in TLS, unless one has take specific 
precautions to tunnel one session output properly within the record layer of another, whose 
fragmentation engine and message queue handler blinds timing channels. Its  quite easy with 
telnet-s for example to use these covert channels to  signal actual patterns in the users typing 
behavior/errors, which are is characteristic of people (and their state of mind!) as is their use of 
a morse key.
 
And what precisely was the irrefutable intent established using crypto proofs, when
we contrast that with the sideband TLS evidence of their typing behaviour? asks competing 
counsel?
 
Ask a person who had to listen to morse, in their military communications careers. They
could tell what mood the person was in, after a while
 
!

---

From: Peter Williams <[email-masked]>
Date: Wed, 20 Dec 2006 08:22:55 -0800

Stefan:
 
Mark Brown is making a case, using legal argumentation style, for changing the charter, postulating a new "stasis of definition". 
Its a refined form of argument we dont use in IETF, mostly cos uz programmas dunno howzit dun, tho it is seen in usenet culture
still. The essay was beautifully crafted. It gives good reasons for changing the way we think. It will fail, tho; given IETF's inbred
war mentality. Rhetoric vs political regimes found on wars-on-X: these  never go together in the same argumentation
bed.
 
If we assume the Zarefsky-ian teaching on handling claims and evidence in uncertain arguments (like the internet! not 
cryptography! not! TPM's limited concepts of technical evidence), the work certainly-might be *effectively* handled 
in WS-SX  forum within OASIS. There, much of the same architecture and mechanisms as SSL considered are being revisited,
without DARPA dogma and DoD legacy issues, and within a revised set of functions for the upper layers of the stack. It would be a
good fit, perhaps only because of IETF's angst over the NR topic - which I got nicely tied in the consciousness to the associated possibility
of it becoming an easy basis for mandatory key escrow (via certs.). Its also "application layer" (where the single app layer 
got split into 7 sublayers doing communication protocols, to be true!). Its also not US centric, which is important for the next
generation internet.
 
The new "socket" is perhaps what the web architect's intended: the URI! (and the strongly-named URI! with secureConversation's 
rendition of SSL handshakes).
 
That new socket can have mandatory spying and recording built in, for all I care. Just, now, grandma will know 
it and accept it,  socially; she will not be part of a social structure founded on deception. She can then even benefit from 
its flip side: NR (or probative internet evidence (PIE), or whichever new moniker becomes established)

Peter.

> From: [email-masked]> To: [email-masked]; [email-masked]; [email-masked]> Date: Wed, 20 Dec 2006 15:00:32 +0000> Subject: RE: [TLS] Please discuss: draft-housley-evidence-extns-00> CC: > Then we can avoid the legal discussion of NR that has already started, which I don't think belong here. Whether this turns out to be used as evidence is completely up to the applications using this technology and should be totally out of scope for this document.> > > Stefan Santesson> Senior Program Manager> Windows Security, Standards

---

From: Peter Williams <[email-masked]>
Date: Wed, 20 Dec 2006 11:20:58 -0800

Nah, Martin. This layering is not the real issue in debate. Its not the crux of the design controversy.
The crux is actually sociopolitical and similar to that which I argued about, years ago, unsuccessfully 
(and alone, sob!) against the Netscape/MISSI line.
 
The power of SSL/TLS is in its commodity status, as a universal bearer, having public repute, and public trust. 
Everyone will want to tag on (pun) to that: e.g. my own Connection-NR argument. What matters is adoption, and 
Peter even proposed a theory of reliance explaining the causes of adoption (and non-adoption of the IETF stuff). 
Even got one of my Phd examiners to go red in the face with rage during the oral, before giving it a grade of 
"miserable fail (with total prejudice)".
 
Now that was fun!

> From: [email-masked]> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00> To: [email-masked]> Date: Wed, 20 Dec 2006 19:46:39 +0100> CC: [email-masked]> > Mark Brown wrote:> > > > After pointing out this unsolved problem for constructors of digital> > evidence, Kent then affirmed the convention of delegating this seemingly> > intractable problem to the application layer. "Signing things for> > non-repudiation is usually an application-layer issue..."> > Correct.> > Choose between CMS & S/MIME, signed XML and maybe GSSAPI-IDUP> if you're looking for standards how to put digital signatures> on actual content, rather than TLS, who has a option to use> a digital signature as a proof for possession of a private> key as a method for online authentication.> > > > (http://www3.ietf.org/proceedings/05nov/tls.html ) Which is a pretty> > sensible approach, I think. But to be perfectly honest, isn't "application> > layer" here a code word for "let them figure it out, we're not going to> > waste any more time on this problem"?> > > > But now TLS Evidence can solve the "signer's intent" problems, and it> > requires two parties, implying a network protocol connecting two parties.> > TLS Evidence can NOT solve the signer's intent problems, it is in the> worst possible position to do so, right above the bits-on-the-wire.> > Most protocol stacks have several protocol layers in between, carrying> data that is produced by software rather rather than users and users> never get to know what amounts of protocol framing and auxiliary data> the different layers of the software stack are going to put in there.> They don't even know whether, when they are shown a popup window> with "OK" and "Cancel", what will be sent over the communication> channel -- is it "OK", or "0" or "0xff3456ab" or "button 0x200".> The signer's intent is extremely sensitive to the context,> and TLS has nothing to do whatsoever with the UIs -- which are> going to have a significant impact on the users intent.> And user shouldn't have to know or care about that.> > If users are expected to digitally sign actual meaningful content> rather than producing evidence for possession/knowledge of a (private) key,> then they better know every single bit that gets signed.> > IMHO TLS MUST NOT have access to keying material that vouches for> anything else than "private key present". The purpose of TLS is online> authentication, and the users private key is used to process> arbitrary data as seen fit by the underlying authentication protocol.> > > I'm firmly opposed to the TLS Evidence proposal.> > > > > > 2. What if in the scenario above the transmission is the acceptance of a> > relatively small contract that, in its fine print, grants a huge amount of> > intellectual property rights to the military? And later the contractor> > wants to repudiate the signature, claiming that the transaction was a> > forgery?> > If you need a contract sign, just do it. There have been perfectly> working schemes to do contracts for centuries. Many do not require> computers or the internet, and everyone knows how to handle them.> You certainly do not need TLS contortions in order to do contracts.> > Think about what you propose: you're seriously suggesting that> click-through-licenses are a good idea. I'm violently opposed to> this. Fortunately German jurisdiction has been considering> click-through licenses nul and void, and I certainly do not> want that to change.> > > Think about the much more dangerous use of this. Currently there> are public forums operated by big companies (Microsoft,Google,etc.)> and at least some of them have "terms of use" (subject to change> without prior notice) which is supposed to transfer your IP to> them for everything that you write/post/upload. > > Click-through licenses are evil, and I don't want to see an> IETF working group pushing click-through licensing scheme.> > > >> > If only the high-assurance server signed the evidence then the> > contractor can say that someone else initiated that transaction,> > and the burden of proof rests on the military.> > As I mentioned, we don't have to reinvent the wheel -- the world> has been successfully doing contracts before the internet, and> with concepts every adult is accustomed to.> > > I don't know how you think applications are being built today,> but the application area that I know keeps adding protocol> layers between the wire-level and the presentation layer> (what the user really gets to see) like crazy.> TLS is just above the network layer, hidden under several> abstractions and resource-managed by the middleware.> > When the middleware feels like it (or when there's some> network hickup) the network connection may be dropped and> the TLS connection interrupted. Depending on the> protocol layers in the middleware and the requirements> of the application, the communication channel will> be automatically reconnected and the TLS secure channel> automatically re-established, transparent and unnoticed> by the "application" in many scenarios.> > > -Martin> > _______________________________________________> TLS mailing list> [email-masked]> https://www1.ietf.org/mailman/listinfo/tls