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

[Martin Rex <martin.rex@xxxxxxx>]

Stefan Santesson wrote:
> Martin Rex wrote:
> > A well engineered approach would not use a shotgun approach to
> > security, but instead a tailored design that meets exactly
> > the needs of the application, can be used for programmatically
> > checking consistency an can create digital tamper-resistant
> > proofs of transactions that contain all and only the necessary
> > information that is necessary
> 
> Yes, don't we all wish we had that. Especially that we could agree on
> what "all and only the necessary information that is necessary" is.

You got me wrong.

> >                                -- in which case it will be
> > possible make it conforming with individual, case-specific
> > legal and buisiness requirements.

Instead of having to redesign and rewrite the entire application protocol
stack for every use case in order to accomodate what data will and
will not become part of the TLS Evidence, one can make it a configuration
option for the customer in the application.  So all of the attributes
that the backend wants to get signed will be tagged as such in
the request from the backend to the frontend.  Auxiliary information
will go untagged and not be included in the signature.  Because
the app knows what it wants signed, it can actually verify that it
receives what it is looking for.


> 
> Another 10 years will pass before we get there unfortunately.
> In the meanwhile we will continue to conduct business based on
> passwords and totally spoofable security.

A data-agnostic TLS-Evidence is still spoofable because of a lack
of assurance of the participating software components.


>
> In security, perfect has always been the enemy of the good.

Perfect forward secrecy is an enemy of TLS Evidence, and
I prefer the former by a significant margin. (I mean Perfect Forward
Secrecy as a design goal of the entire system, not only as
an isolated characteristic in the threat model for a particular
network link).


-Martin

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