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

[[e-mail] (Martin Rex)]

Eric Rescorla wrote:
> Martin Rex <[e-mail]> wrote:
> >
> > Paterson, Kenny wrote:
> > >
> > > 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.

Silently discarding it     = proceed as if you had not received it

non-silently discarding it = log an error and proceed as if you had not
                             not received it

Terminating the connection with an alert means "processing it".

So yes, there is a contradiction.

-Martin