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

[Eric Rescorla <[e-mail]>]

On Tue, Feb 18, 2020 at 3:39 AM Joachim Fabini <[e-mail]>
wrote:

> 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...
>

Yes, I agree with this.



> > 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.
>

Hmm.... What do you think protocol designers would do with this information?
Every modern comsec protocol I am familiar with has zillions of bits that
can
be freely chosen, and though there's been a bunch of work on deransomization
I don't think we're ready to change that.



> 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.


This seems like a kind of normative statement that 3552 generally strove to
avoid, and I think should remain out of scope here. I think it would be a
good
idea to explain that the endpoint you are talking to now is probably really
distributed, but I don't think we should be taking a position on the users
rights vis-a-vis that.

-Ekr