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

[[e-mail] (Martin Rex)]

Martin Rex wrote:
> 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.


For comparison, look at the more elaborate discussion in the successor
DTLS document:
  http://tools.ietf.org/html/rfc6347#section-4.1.2.7

   4.1.2.7.  Handling Invalid Records

   Unlike TLS, DTLS is resilient in the face of invalid records (e.g.,
   invalid formatting, length, MAC, etc.).  In general, invalid records
   SHOULD be silently discarded, thus preserving the association;
   however, an error MAY be logged for diagnostic purposes.
   Implementations which choose to generate an alert instead, MUST
   generate fatal level alerts to avoid attacks where the attacker
   repeatedly probes the implementation to see how it responds to
   various types of error.

Where you can see the two variants of discarding ("silently" and logging
an error) that preserves the association, and the behaviour
"Implementations which choose to generate an alert instead", being
explicitly characterized as distinct to discarding.



btw. there is another contradiction within rfc4347 section 4.1.2.1 MAC
between paragraph 3 and 4 (which is reproduced in rfc6347):

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

   Note that one important difference between DTLS and TLS MAC handling
   is that in TLS MAC errors must result in connection termination.  In
   DTLS, the receiving implementation MAY simply discard the offending
   record and continue with the connection.  This change is possible
   because DTLS records are not dependent on each other in the way that
   TLS records are.

   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.

Paragraph 3 says "MAY simply discard the offending record and continue
with the connection", whereas paragraph 4 says "DTLS implementations
SHOULD silently discard data with bad MACs.".

You can not use two distinct imperatives (MAY and SHOULD) for the
very same behaviour, that is a contradiction.  You can only use one
or the other.

Maybe the document (co-)authors should be using the "MAY WISH TO"
http://tools.ietf.org/html/rfc6919#section-6 keyword instead
of the rfc2119 SHOULD in paragraph 4 of rfc4347 section 4.1.2.1.  ;-)

There are some folks in the IETF security area (in particular over
at PKIX) that feel very strongly about SHOULDs.


-Martin