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

["Kyle Hamilton" <aerowolf@xxxxxxxxx>]

On 1/5/07, Stefan Santesson <stefans@xxxxxxxxxxxxx> wrote:
> If we leave the concept of evidence out of scope and leave it to the lawyers to worry about, is there any technical merits?
>
> There is one that I think we should consider. If a client or a server want to ask its opponent to sign a portion of data, is there any alternative solutions that would work cross platforms.

Sure, if you want to define a protocol for it and not "embrace and
extend" the way that Microsoft is so fond of doing.

> PKCS#7/CMS or XML digsig is not an answer as it only provides signature format, it does not deal with the request and response logic.

...and this is a problem how?  Dealing with this in the network layer
(since TLS is supposed to look like the network layer to its clients)
is COMPLETELY not the correct way to do it -- perhaps a standardized
and hardened HTTP-like protocol, but even that is outside of the realm
of the TLS working group.  "I want this signed" is an
application-transport mechanism, not a network mechanism.  (No matter
that MS implemented "signed CIFS" and "signed RPC", those standards
aren't available cross-platform.)

> Going higher up closer to the application requires standardization of solutions based on vendor specific interpretation languages such as Java or .NET.

No, it requires standardization of solutions based on the protocol
communication.  Implementation of the protocol can be done in Java or
C# (.NET isn't a language, it's a runtime) or C++ or whatever is
appropriate for the implementation.  The Internet is
computer-language-agnostic -- it's recognized as "existing" simply
because implementation cannot be done without it, but if it was
reliant on C then you wouldn't be able to use Visual Basic,
Javascript, Jscript, VBscript, Java, C#, C++, or anything other than C
to write your Internet applications.

> The balance is a delicate problem. But I'm sure that if there is a solution that is technically sound from a protocol perspective, then there will be a way to implemented in a sufficiently secure way for many usages.

IF (there is a solution AND that solution is technically sound AND
that solution fits into the TLS layer) THEN (it may be implemented).
I cannot see it occurring, though.

> As to the security discussion earlier, a very common way to eliminate the insecure DMZ is to publish the web server from a secure front end firewall holding and/or controlling the TLS keys. Unless you can hack that firewall you won't get to the keys or the server app side of the information flow. In any case, just because there is a way to implement a solution badly, does not mean that there is no good way to do it.

"a secure front end firewall holding and/or controlling the TLS keys"...

...you've just defined "DMZ".

Let's look at this from the viewpoint of "how can you prove that the
firewall is secure, and has no available attacks against it other than
DoS?"  Or, better yet, let's look at this from the viewpoint of "how
can I prove that my firewall is more secure than IIS?"

> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards

...and as an aside, it's this type of tunnel vision and complete
idiocy which has earned Microsoft, quite rightly, the derision of
security professionals.  NONE of the proposed attacks have been
addressed, and these example attacks have all been "off the cuff"
examples.  It is axiomatic that we're not thinking of all possible
attacks, we're just bringing up the barest scratches of things that
make this proposal completely impossible.

Your suggestion of "secure firewall that controls the keys" is
laughable at best and dangerous at worst -- the entire point of a
firewall is to have a layer that provides no other function than to
protect what is behind it.  And even then, what is behind the firewall
can be attacked and subverted.  It merely limits the attack vectors; a
firewall does not make attacks impossible.

-Kyle H

(yes, I know this is a relatively incendiary missive.  I realize that
IIS's security, and the security of the underlying operating system,
have increased exponentially since Windows NT 4.  I realize that
Microsoft has made great strides toward reducing attack vectors.  But
I also realize that if attack vectors aren't nipped in the bud, they
WILL be implemented, and they WILL cause problems for millions of
users, with monetary outlay in the trillions of dollars before they're
fixed.  It is this which drives me to come down so hard on someone who
holds an office which cannot afford to make these kind of mistakes.)

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