Re: [Model-t] Considerations for modern COMSEC protocol design

[Joachim Fabini <[e-mail]>]

thanks EKR for the concise summary. Some minor
additions/comments/thoughts on the traffic analysis paragraph and on e2e
aspects below.

On 2/17/20 6:06 PM, Eric Rescorla wrote:
> As promised...
> 
> -Ekr and Chris
> 
> [...]
>
> TRAFFIC ANALYSIS
> RFC 3552; Section 3.2.1 describes how the absence of TLS or other
> transport-layer encryption may lead to obvious confidentiality
> violations against passive attackers. However, recent trends in
> traffic analysis indicate encryption alone may be insufficient
> protection for some types of application data [1]. Encrypted traffic
> metadata, especially message size, 

In addition, message timing, -sequence, -patterns are the features most
useful and commonly available whenever attacking encrypted (and
potentially aggregated) protocol traffic. Worth mentioning...

> can leak information about the
> underlying plaintext. DNS queries and responses are particularly
> at risk given their size distributions. Recent protocols account
> for this leakage by supporting padding, either generically in the
> transport protocol (QUIC and TLS), or specifically in the application
> protocol (EDNS(0) padding option for DNS messages).

Time synchronization protocols can be mentioned here as a use case, too.
Currently none of the existing TS protocols is adequately protected
against timing attacks (assumptions concerning link diversity typically
fail whenever the attacker is well-positioned, e.g., on the majority of
the system's few access links). And timing becomes crucial for many systems.

Moreover, the accuracy of (today's) network-based timesync depends on
deterministic message patterns, sizes and timing. Consequently (a) any
attempt to secure/obscure these messages impairs on timesync accuracy
and (b) timesync messages can be spotted easily within encrypted traffic
(even including IPsec-tunneled timesync, despite TFC and obscuring
traffic - references on request).

At least a note could be added that subliminal channels do exist and
should be considered when designing (security) protocols. I'll try to go
into more detail with the malware draft.

Finally, somebody mentioned during Friday's telco that "we don't know
who provides security". Imo this is where the threat landscape changed
most since 2003. RFC3552 does not even include the definition of an
endpoint (imo because by the time of writing it was too obvious what's
meant). Security frameworks, containers, virtual guests, clouds, etc.,
changed the rules of the game. They help but their transparency can be
painful in a security context.

So it boils down to a (again, imo) central question that the CLESS
endpoint taxonomy draft tackles to a certain extent: "what does
end-to-end mean"?

Is it meaningful/mandatory that future protocol/framework security
specifications are forced to make explicit what their perception or
concept of end-to-end is? Rewording this slightly: Users and
applications should have a right to identify/query which underlying
layers provide (e2e) security, i.e., where e2e security really ends.
And, in addition, which layers/frameworks/etc. (either local or remote)
sit in between and could break end-to-end security without being noticed.

br Joachim