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

["Christopher Wood" <[e-mail]>]

On Tue, Feb 18, 2020, at 6:27 AM, Eric Rescorla wrote:
> 
> 
> 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.

+1, though let's not get carried away. (The list can grow to thousands of features.)

> >  > 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
> 
> -- 
> Model-t mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/model-t
>