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

[Joachim Fabini <[e-mail]>]

On 2/18/20 3:27 PM, Eric Rescorla wrote:
> 
> 
> On Tue, Feb 18, 2020 at 3:39 AM Joachim Fabini
> <[e-mail] <mailto:[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
>     >
>     > [...]
>     > 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?

I suppose your question concerns just the last sentence?

The former statements on time synchronization should warn protocol
designers that they must not rely on the timing of messages and that
encryption/security does not help in this respect, either.
In Industry and in the academic community it is a common misbelief that
encryption helps against timing attacks (can reference several
publications relying on such assumptions). People are not aware of this
pitfall and it is fair to warn.

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

Still: the less degrees of freedom protocol designers provide in their
freely selectable bits, the better. My concern is not so much about
end-to-end subliminal channels, but about the zillions intermediate
layers between pretended "end-to-end" and the actual security layer below.

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

No need to involve users. The advise to protocol designers could be as
simple as: minimize the number of layers between the application that
needs end-to-end security and the actual {encryption/integrity
protection} layer. The fewer uncertainty factors there are in between,
the better.

>From a purely academic perspective I'd love to have a traceroute-kind
mechanism that allows users/applications to trace e2e all layers,
modules, frameworks involved in an e2e communication. But I guess this
truly exceeds the scope of model-t. ;)

thanks,
Joachim