Re: [TLS] TLS1.2 vs TLS1.0

[[e-mail] (Martin Rex)]

Paterson, Kenny wrote:
> Hi
> 
> On 21 May 2013, at 14:47, Martin Rex wrote:
> 
> > The alleged (confidentiality) problems that have been demonstrated so far
> > are about design-flawed communication peers that require an attacker
> > to be able to insert data into the beginning of the TLS-protected
> > communication an repeat the request a few thousand times (or more)
> > in order to perform plaintext recovery on allegedley confidential
> > data that the attacked communication peer willingly inserted into
> > the same TLS channel following the data provided by the attacker.
> 
> This is an incorrect representation of the known attacks on
> confidentiality (as I understand them, at least).
> 
> - The attacker-injected data does not have to be at the start of the
>   TLS-protected communication.
> - The peer-inserted data does not have to follow the attacker-provided data.

True.  Technically, attacks (on CBC) become possible whenever the attacker
can force data of his choice to be processed along with a block of unknown
data under the same block cipher key and observe differences in the
resulting behaviour.

Being able to insert plaintext before the unknown data can be used to
attack the senders encryption oracle (what BEAST did), which may allow
blackholing the resulting output in order to avoid alarm bells
going off on the peer (original receiver).

For the more generic attacks on CBC-Padding using the receivers decryption
oracle it would be sufficient if the attacker can entice the client to
repeat essentially the same request (i.e. with the same interesting data
at a known or predictable position) sufficiently often (typically a few
thousand to a few million times), then rearranging the network data
that the receiver is going to process will be sufficient.  The large
number of failed reciever-side processing might eventually set off
receiver-side alarm-bells.


> 
> > Datagram TLS (DTLS) is another can of worms, because it has an unreasonable
> > requirement to ignore unlimited amounts of MAC-failing DTLS records on a
> > DTLS connection, but that is a defect from which the stream-oriented
> > regular TLS protocols do not suffer.
> 
> True. Though the spec for DTLS does allow DTLS implementations to
> terminate a connection in the event of errors. 
> 
> It's just that most (all?) implementations don't.


Now that you mention it, I hadn't noticed that DTLS gives actual two
_different_ guidances (MAY abort on MAC error and MUST discard records
with MAC error are mutually exclusive)

http://tools.ietf.org/html/rfc4347#section-4.1.2.1

   4.1.2.1  MAC  (last paragraph):

   In general, DTLS implementations SHOULD silently discard data with
   bad MACs.  If a DTLS implementation chooses to generate an alert when
   it receives a message with an invalid MAC, it MUST generate
   bad_record_mac alert with level fatal and terminate its connection
   state.

http://tools.ietf.org/html/rfc4347#section-4.1.2.5

   4.1.2.5  Anti-replay  (last paragraph):

   If the received record falls within the window and is new, or if the
   packet is to the right of the window, then the receiver proceeds to
   MAC verification.  If the MAC validation fails, the receiver MUST
   discard the received record as invalid.  The receive window is
   updated only if the MAC verification succeeds.


-Martin