Subject: [Uta] Threat model

From: Ralph Holz <[email-masked]>
Date: Wed, 08 Oct 2014 23:17:54 +0200

Hi,

As an addendum to my last mail, I would like to add that TLS itself does
not have a threat model.

I recall setting up a ML a few years ago where some people joined to
discuss it, but it died quickly. I wouldn't try it again.

Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18010
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 16 Oct 2014 08:49:44 +0000

Ralph Holz <[email-masked]> writes:

>BTW, almost all protocols lack a definition of what they mean by
>"authentication", too. Cas Cremers showed that IPSec authentication is broken
>for a number of definitions, although fortunately not for "the intuitive one"
>and the one it was probably designed for. I suspect the same holds for SSL.

Protocols don't just not define "authentication", they don't even bother
specifying that you should apply it.  For an upcoming article on fault-
injection testing in ;login I looked through the specs for a pile of Internet
security protocols and found that you can create a fully standards-compliant
implementation that looks at a signature or MAC tag, throws it away, and
continues.  An excerpt:

  This problem is widespread among security standards.  The OpenPGP
  specification, which devotes a full fifteen pages to the minutiae of the
  formatting of signatures and signature data, completely omits to tell you
  what exception conditions need to be checked for when processing signatures
  or how to respond to them (the only comment in the standard that I could
  find was a statement that “If a subpacket is encountered that is marked
  critical but is unknown to the evaluating software, the evaluator SHOULD
  consider the signature to be in error” [REF]).  The standards that cover SSH
  are no better, with the sole check that’s required being that “values of
  [Diffie-Hellman parameters] that are not in the range [Diffie-Hellman prime
  size] MUST NOT be sent or accepted by either side” [REF].  As long as an
  implementation checks those parameters, it can ignore the signature validity
  check and be completely standards-compliant.

I was... somewhat surprised at this.

Peter (whose nonstandard implementation checks signatures and MACs and rejects
       the message if the check fails).