[TLS] Re: Review of draft-modadugu-dtls-short-00

[nagendra modadugu <[e-mail]>]

Hi Lakshminath,

Thanks for your review and apologies for the delay in 
responding.  My comments inline:

> I didn't understand a few things in the DTLS-SHORT spec., and have some questions for my clarification.
> 
> * Length field:
> 
> From the description, negotiating the length field is clear, but not
> how it affects the Record format.  Is the field completely eliminated
> and if so is an application layer length field assumed to be reused
> with the encoding specified?  Reusing another SEQ number might be ok,
> but I am not sure whether the specified encoding can always be imposed
> on the said SEQ number.  Any insight into this would be helpful.

When the length field is completely eliminated, only one record is
transmitted per UDP packet -- the record length is then inferred
from the UDP packet length.

> * Length field verification:
> 
>  Are you suggesting that a receiver try various guesses on the SEQ
>  number and try them out with MAC verification?  Do you plan to specify
> any limitations on the number of attempts?

Yes, that's the idea.  We should have a limit (to the end of the replay window?)
but haven't entirely worked through that yet.  Any ideas would be welcome.

> * Frequency of change cipher spec:
>  Ok, before I go into this, I am confused about the mapping between 2B
> epoch + 6B SEQ in DTLS vs. the various possible combinations of
> lengths for epoch and SEQ numbers in the table in DTLS-SHORT and the
> note "without shortening the actual sequence number."  Perhaps I am
> just dense, an explanation will help.
>
> If in fact the shorter epoch, SEQ combinations are going to be used,
> does it mean there is a ChangeCipherSpec every 2^14 records in the
> smallest epoch+SEQ number case?

I'll add some text to the document to elaborate on this point.  It's
only the 'on-the-wire' representation that is shortened -- the sequence
number range is not reduced compared to DTLS.

> * Version field:
> 
> I have a naive question here (perhaps all of these are naive).  If the
> version field is indeed "mostly redundant" why not just remove it from
> the main DTLS spec?  Perhaps that field is in there for DTLS is TLS
> look-alike reasons?

Precisely.  We didn't want to make changes that were not necessary.

> * Length field:
> 
> Is the length field redundant because it can be calculated from length
> fields from elsewhere in a UDP packet, as long as there is only one
> record per fragment?

Yes.

> * implicit header (IH):
> 
> The list of fields to be excluded does not inlcude the epoch field.
> Please explain.

Writer error.

> If the SEQ and/or epoch fields are not included, could you explain how
> to maintain those in the presence/absence of application layer (e.g.,
> RTP) numbers.

Without:
If there's no packet loss or reordering you can just use a simple
counter of packets.  If you get a packet that doesn't make sense,
you search around the expected sequence number until you get
something that does decrypt/verify properly and then you update
your "next" estimator.

With:
The application code can give a "hint" about the offset between
the application sequence # and the DTLS sequence number.  Then
you just use the procedure above.  That make sense?

> * Order of DTLS header fields in Section 6 (probably just editorial):
> 
> I am confused by the order of fields in Section 6 and its impact on
> the processing steps.
> 
> The original order of DTLS fields is as follows:
> 
>         ContentType type;
>         ProtocolVersion version;
>         uint16 epoch;               // New field
>         uint48 sequence_number;       // New field
>         uint16 length;
> 
> The order in Section 6 is as follows:
> 
>       Content type
>       Version
>       Length
>       Sequence Number
> 
> Why is the order changed?
> 
> Perhaps it is an error?  It's probably just editorial as I can't think
> of any impact on processing steps as we are dealing with fixed
> headers.

Editorial error.

> * IH processing:
> 
> "The initial value of ESN (the expected sequence number) is set to 1 +
> (sequence number of the Finished message record), which should be the
> sequence number of the first application data record."
> 
> Why "first"?  Can there be more than one record in the packet?

The reference is to the first application record in the connection -- right
after the finished.

> * Trial decryption process:
> 
> Bear with me as I walk through the record receipt processing.  I see
> three cases: a record with Case 1) excluded the DTLS header, but
> encrypted from the beginning of the application layer header, or Case
> 2) a full DTLS header, or Case 3) excluded DTLS header and unencrypted
> application layer header (e.g., RTP, RTCP, or it could be anything
> really).

> Case 3 could be interesting as I wonder whether there are any
> collisions between the DTLS header and another application layer
> header.  Another thing that comes to my mind is that there is no
> reason to stop a future application to come up with a payload
> structure that matches the above.  Perhaps it doesn't matter (I
> haven't worked through the possibilities in my mind), or to make
> things simple, DTLS-SHORT can be ruled out for such an application.
>
>
> Dealing with cases 1 and 2 only, the receiver could try to parse the
> first 13 bytes as a DTLS header:
>  If the type matches allowed ContentTypes, it can sanity check the
> version, sequence number and length (just in case encrypted text
> matches the type field or something), decrypt using the sequence
> number as the IV (assuming counter mode), verify the MAC and if all is
> well pass the record up to the next layer.
>
> If that fails, the receiver might try to parse the record as an RTP
> header (or other APP-Layer header); in case of RTP, it can extract the
> RTP-SEQ number from there, figure out the IV, verify the MAC and if
> all goes well, accept the record.  One corner case here is a burst
> loss of 2^16 or so records and that makes things slightly interesting.
> I'd assume a few guesses on the IV (e.g., IV =
> higherOrderBits||RTP-SEQ, higherOrderBits+1||RTP-SEQ) could be tried.

> If those two steps fail, another short cut might be to have a local
> policy that for a given DTLS connection, the record MUST contain
> either a DTLS header or a known APP-Layer header.  That might allow
> the receiver to simply discard the packet without any further
> processing.

Sounds reasonable -- though as you point out, an application may already
know which kind of records are expected.

> Without such policy-based processing, an adversary may simply put
> random bits at the beginning of the record to confuse the receiver.
> The concept of trying all sequence numbers based on a replay window
> might be very expensive.  First, that could mean generating as many
> keystreams as the length of the replay window, and second, even that
> might not be sufficient if you want to consider the possibility of
> records to the right side of the replay window.  Wouldn't it be a lot
> of processing without a definitive result?  In other words, if an
> application layer sequence number (a la RTP) is not present, is it
> possible that receivers might discard perfectly legitimate packets
> (assuming an adversary drops or a burst length -- L = replay window
> size -- packets) until one with an explicit DTLS header arrives?

Yes, that could happen, but in general if you're seeing really large
amounts of packet loss, something pathological has happened in any case.

The bottom line here is that I'm not sure it's that important an attack.
Remember that you can generally force peers to chew up a lot of CPU in
lots of ways.  But, as you say, there are policies to defend against
this sort of thing.

> I guess I would conclude that the encrypted MAC semantics of TLS/DTLS
> makes this difficult for the generic case.  Have you considered
> defining an extension to change that?

HMAC-SHA1 is about the same speed as AES-CTR, so we're not looking
at that dramatic a speedup even with EtA.  I wouldn't think it's
worth the effort of changing.

> Editorial: Step 5 in the processing steps in the I-D needs
> clarification.  Why "prepend" an application_data header with a
> sequence number?  What does that mean?  That's not how the sender
> prepares the record.

Bad writing.  Parse this as "Prepend (an application_data header with
sequence number ESN) to the record."

Thanks,
nagendra


_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls