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

[Martin Rex <martin.rex@xxxxxxx>]

Kemp, David P. wrote:
> 
> -----Original Message-----
> From: Martin Rex [mailto:martin.rex@xxxxxxx] 
> >>
> >> 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).
> 
> You keep saying that, but please explain why data retained by
> "network trace" components that log all levels of the protocol
> stack is not an enemy of perfect forward secrecy.  If data is
> retained, it is retained, regardless of whether a signature
> exists to authenticate that data.

The incentive factor.

Creating TLS Evidence has a significant higher cost that persisting it,
and as it is somewhere between fully unclear to impossible to interpret
the signed contents programmatically, there is a certain likelyhood
that someone how goes through the effort to create it will want to
persist it.  Remember, if it was _just_ about signature verification,
you could either use a secure channel bindings approach or just "sign"
a secure random challenge, depending on your exact requirements.

Although I generally dislike channel bindings, I think they are
a much better fit than TLS Evidence (at least for the IETF).

If you can get management to approve the cost of having it
after having convinced them how useful and valuable digital
signatures on the entire communications  may turn out to be
(e.g. for lawsuits), that management might want that
expensive TLS Evidence to be retained/archived.


Probably everyone will agree that retaining a full network level
trace is most often a waste of resources.  Unfortunately,
the TLS Evidence blob is an all-or-nothing thingy with the lowest
possible signal-noise-ratio.


-Martin


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