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

["Kemp, David P." <[e-mail]>]

There is no contradiction - in both sections a record with a bad MAC MUST be discarded.

4.1.2.1 specifies two subcases of discarding: do nothing else (silently discard) or discard then alert/terminate).  Those subcases do not conflict with 4.1.2.5.

I disagree with the SHOULD in 4.1.2.1, because that says the IETF disapproves of generating fatal alerts.  Unless there is good justification for saying applications SHOULD NOT alert and terminate, the SHOULD should be MAY.

Logging is independent of processing, not a third alternative.  Silently discard (with or without logging) is one processing action, and alert and terminate (with or without logging) is the other.  "Bad MAC discard without logging" is not a separate action from "Bad MAC discard with logging".  "Bad MAC discard" is a single action with some level (debug/info/error) that may or may not result in a log record being generated.

Dave

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Eric Rescorla
Sent: Wednesday, May 22, 2013 9:30 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: [TLS] TLS1.2 vs TLS1.0




On Wed, May 22, 2013 at 5:51 PM, Martin Rex <[e-mail]> 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".
	


Unsurprisingly, I don't agree with this interpretation.

-Ekr