Re: Missing requirements

Hi Charles,

In message <9605232038.AA07380@mordred.sware.com>, Charles Watt writes:
> [ ... ]
> This does not work against a stream cipher that incorporates feedback of the 
> resulting ciphertext into the key stream.  Such ciphers are vulnerable if 
> you reuse the key, but require much more sophisticated techniques to break.
> Arguing whether such techniques classify as differential cryptanalysis is 
> at best nitpicking.
> [ ... ]
> To quote ISO 8072, the Transport Service Definition, connectionless mode
> transmission occurs "without any requirement to maintain any logical
> relationship among multiple transport-service-data-units".  Sounds like
> UDP to me.  To which ISO model were you referring?
> 
> Regardless, if there is no extra complexity associated with making the
> protocol appropriate for UDP, what are your objections to doing so?
> Nitpicking about terminology that isn't even relevant to the topic of
> discussion is an annoying waste of time.

Yes, I do some nitpicking at times.  (I think it's important to get
our terminology straight in order to think clearly and communicate
effectively.)  You're right that a cipher in CFB mode does not suffer
from the simple reorigination attack that a true stream cipher does,
though the more sophisticated attacks that you allude to are still not
differential cryptanalytic attacks.  Typically CFB is used for cases
where self-synchronization is needed to limit the effects of
transmission errors (not a requirement w/ TLS traffic, since except
for malicious packets we can assume that the CRCs will work okay); we
also don't need error propagation, since we separately check the MAC
on the data.

There are attacks that are possible (if we allowed the same keys to be
used for different sessions) that are simpler than differential
cryptanalytic attacks.  Certainly applications where a few gibberish
blocks are tolerated (true for some data formats where there are
fields that are "don't care" or unused by the viewing application,
e.g., comment text fields in various image formats) are potentially at
risk: using the same key for multiple sessions would open us up to
replay attacks -- because MAC computation only depend on the record
sequence numbers (and the common MAC key and the current record's
data), if the record boundary happens in one of these "don't care"
fields then an attacker may substitute records from a different
session (but the same record number) into the current session: the
substituted data would MAC-check okay, and the cipher will
self-synchronize and as long as the "don't care" region is large
enough (a block or so) the substituted data would also decrypt okay.

This is not a problem for rebroadcasting the same pre-encrypted /
pre-MACed data, of course, since there's only one data stream.

Oh, thank you for correcting my mistake wrt ISO OSI terminology --
I've been thinking that that particular TSAP is just a thinly veiled
NSAP and such trivial interface pass-throughs doesn't "count".  (It's
been about 10 years since I looked carefully at ISO OSI RM.)

As for whether I have objections about UDP, the point of my messages
was that I -don't- object to making the protocol usable for UDP, just
that we need to examine the complexity-versus-functionality
trade-offs.  I don't think it's a "given" that we should (or should
not) support datagrams.  Others on this list had objected to the
Microsoft STLP strawman, which was basically SSLv3 with PCTv2
extensions -- mainly datagram support and the ability to
pre-encrypt/MAC data for low security data distribution applications
such as (Web-based) bulk/multimedia data distribution -- because of
disagreements over the trade-offs.  I like the bulk data distribution
feature, though I'd prefer if HMAC was retained.  The datagram support
isn't bad either, though as I had pointed out in a previous message,
the interaction of rekeying and datagram support hadn't been
completely thought out.

For your applications, Charles, would STLP suffice?  This would be a
useful (though single) data point wrt what the consumers of the TLS
protocol design want.

-bsy

--------
Bennet S. Yee		Phone: +1 619 534 4614	    Email: bsy@cs.ucsd.edu

Web:	http://www-cse.ucsd.edu/users/bsy/
USPS:	Dept of Comp Sci and Eng, 0114, UC San Diego, La Jolla, CA 92093-0114

Received on Monday, 27 May 1996 17:57:49 UTC