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

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: martin.rex@sap.com> Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00> To: mark@redphonesecurity.com> Date: Wed, 20 Dec 2006 19:46:39 +0100> CC: tls@ietf.org> > 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> TLS@lists.ietf.org> https://www1.ietf.org/mailman/listinfo/tls
_________________________________________________________________
Get into the holiday spirit, chat with Santa on Messenger.
http://imagine-windowslive.com/minisites/santabot/default.aspx?locale=en-us