Re: [TLS] Initial draft of DH-based key exchange

[Ilari Liusvaara <[e-mail]>]

On Fri, Mar 27, 2015 at 07:33:19PM -0400, Hugo Krawczyk wrote:
> 
> I agree with warnings about total reliance on theoretical analysis or its
> interpretation as demonstrating the absolute lack of attack venues against a
> protocol. Any mathematical model that attempts to capture real-world
> phenomena
> is prone to fail in some circumstances, and this is certainly the case for
> systems of the complexity of TLS and the Internet. Add to this that the
> attacker
> being modeled in the case of cryptography is as malicious as only humans
> can be
> (how do you design an airplane against an insane pilot purposely crashing it
> into the Alps or a building that needs to withstand the impact of a jet
> guided
> by suicide terrorists?) and you can ensure without doubt that no model will
> be
> full proof.

At one level one can consider mathematical idealities. But because real
world affects the assumptions (e.g. that TLS-Extractor outputs have to be
suitable for channel binding), full analysis becomes an impossiblity
(there are probably much nastier real-world assumptions in proving the
security of real-world protocols using TLS).

Also, sometimes even at this level, the answer to "how to protect against
X?" is "you can't". Like TLS (and QUIC) designers realized with replay
resistant 0-RTT.

Then there is real-world implementation. Can't even be reliably modelled.
However, there are many kinds of constructs that are asking for trouble
here. An example might be to first MAC the ciphertext, then pad it with
deterministic rule and finally encrypt the whole thing (TLS block ciphers
anyone?). This is the construct that gave rise to LUCKY 13 and POODLE TLS.

> However, I cannot agree with the unqualified conclusion that
>   "relying on [these models] is a very bad idea".
> Relying on the theoretical models developed and refined over the years is a
> major source of confidence in the soundness of the core design of a
> cryptographic protocol, a core that may miss essential specification and
> implementation details and semantics but that tells us that the very
> foundation
> of the building is sound.  Many things can fail in that building at higher
> levels but not at the most basic foundational cryptographic aspect.
> Moreover,
> contrary to what you indicate, cryptographic analysis while imperfect has
> been
> remarkably successful in predicting attacks, particularly against TLS. This
> is
> the case for CCA attacks against RSA, the essential role of unpredictable
> IVs in
> CBC mode, the shortcomings of mac-then-encrypt, the potential exploits from
> packet compression, etc.  It is true that theoreticians (like me) don't
> always
> have the knowledge or skills to translate the failures demonstrated in our
> proofs into real-world attacks, but the world eventually catches up and
> finishes
> what we started.

Sure, if you have "negative" security result, and it appears it could
apply with primitives used in real world, that is something worth fixing.

My post was about cauntion about "positive" security results.

(Then there is "elusive" result, where one can't prove something either
secure or insecure).

> With respect to the point that
>   "The consequence is that even if some "security proof" says that it is
> okay to
>   simplify system in some way, that simplification might still introduce
>   vulnerabilities.",
> This is of course a possibility. It falls under "keep it simple but not
> simpler"
> principle, but it is in no way a demonstration that simplifications aren't
> important. They are and if they can be founded on formal analysis then the
> better. A simpler protocol is easier to specify, implement and maintain
> (e.g.,
> adopting it to new settings and requirements). Safety margins are necessary
> but
> we need to understand what is their role, or else we will end with
> impractical
> or unnecessarily complex schemes that are likely to fail in many other ways.

I don't think the simplest protocol is optimal. This is because such protcol
likely will have security arising from subtle intreactions, which causes
several undesirable things:
- It is likely hard to analyze (doesn't modularze well).
- It likely can't handle loosening assumptions well.
- Implementation errors tend to have bad consequences.

OTOH, too complex protocol is also very undesirable:
- It is hard to to analyze due to number of things that can go wrong.
- Implementation errors tend to be inevitable.

I think the optimum is at simple side but not at the simplest, having
stregthening at carefully chosen places.
- Easy to analyze (modular structure).
- Minimize chances it breaks horribly on loosening assumptions.
- Minimize chances of implementation error.

And as for implemenation, it should be designed in a way that there are
very few or none tempting shortcuts that compromise security. That includes
minimizing number of checks performed, since each that is needed for
security is a potential vulernability waiting to happen.

If you have strict set of assumptions, correct implementations and can
handle hard proving work, you don't need any security margins here.
Unfortunately, you don't have that, so you need security margin.

And then the question becomes, in what places one puts that security
margin, so it defends against wrong assumptions and implementation errors
and simplifies the analysis the best.

> In the particular case of OPTLS, I strongly believe that it contributes
> significantly to the simplification of TLS 1.3 and to a sound cryptographic
> design (although we need the proofs to move this from a personal belief to
> something others can verify). I am also under the impression that
> implementers
> and specifiers do appreciate the simplification of the protocol, and future
> designers will do as well when coming to evolve the protocol into new
> realities.

It is also very useful for security analysis to modularize, giving
useful results about various parts. Such tends to be very helpful in
generalizing security analysis when it turns out you need looser assumptions.

And, well, the "simplificiations" for implementation I had in mind are
more about encouraging implementations to do the right thing by removing
tempting "shortcuts" like handshake message type info (Java got screwed
over hard by that "shortcut").


-Ilari