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

[Eric Rescorla <[e-mail]>]

On Tue, May 21, 2013 at 7:37 AM, Martin Rex <[e-mail]> wrote:

> Paterson, Kenny wrote:
> > Hi
> >
> > On 21 May 2013, at 14:47, Martin Rex wrote:
> > > 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.
>

Hmm.... I'm not sure these are contradictory.

If you get a packet with a MAC error you MUST discard the packet (i.e.,
not process it.) You may either *silently* discard it (i.e.., proceed as if
you had not received it) or terminate the connection with an alert.

-Ekr