Review of draft-modadugu-dtls-short-00
Dondeti, Lakshminath <ldondeti <at> qualcomm.com>
2006-03-05 08:06:48 GMT
understand a few things in the DTLS-SHORT spec., and have some questions for my
* 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
* 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
* 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.
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
* 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?
* 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?
implicit header (IH):
The list of fields to be excluded does not inlcude
the epoch field. Please explain.
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.
* 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:
// New field
sequence_number; // New
order in Section 6 is as follows:
Why is the order
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
* 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
Why "first"? Can there be more than one record in the
* 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
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
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.
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?
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?
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.
Thanks in advance for your response.
TLS mailing list
TLS <at> lists.ietf.org