Subject: [TLS] What's the proper alert for sequence wrap.

From: Andrew Fan <[email-masked]>
Date: Thu, 18 Jan 2007 15:01:40 +0800

Hi,

The RFC4346 says:

      Sequence numbers are of type uint64 and may not
      exceed 2^64-1.  Sequence numbers do not wrap.  If a TLS
      implementation would need to wrap a sequence number, it must
      renegotiate instead.

In a implementation, if one does not want to support sequence number 
wrap with renegotiation, a fatal alert should be sent to peer if the 
sequence number exceed. Or if one side receive a wrapped sequence 
number, a fatal alert also should be sent to peer. However, I don't find 
proper alert descriptions for both read and write sequence number exceed 
cases.

Any suggestions?

Thanks,
Andrew

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

---

From: Mike <[email-masked]>
Date: Thu, 18 Jan 2007 09:38:30 -0800

Practically speaking, you don't ever need to worry about this.
Even if you send a billion records every second, it would take
584 years to wrap the sequence number.

Mike

---

From: <[email-masked]>
Date: Thu, 18 Jan 2007 13:09:43 -0800

I'm ill with nausea today, and probably thinking less 
straight than ever. But here goes.

---------------

Lets assume we are in a connectionless environment, and the 
bearer is Not UDP/IP.  Its just ethernetv2. Assume we are 
NOT supported by a connectionless upper layer stack

We handshake according to the author's scheme in DTLS, 
setting up classical duplication detect windows and out of 
order queues.

(NB DTLS REQUIRES us to operate in application space, note, 
to implement the intent of the designers. Why?... cannot I 
make a (trusted) socket implementation even if the bearer 
was UDP?)

Lets say, the DTLS sender is a switch working with BPDUs 
send 2**s packets a second (s) on a ramp, and it now loses 
2**s-1 sequence numbers in that same second (s) due to a 
faulty MAC hardware engine.  That is, the switch generates 
the frame and then just throws it away detecting the mac 
error in its ASICs, as the speed of at line speed ~10G. 
Thus, in practice it actually communicates 1 frame a second 
(with seq_number 2**s-1) on the wire

And, the world of hardware being as strange as it is, the 
receiver now happens to receives seq_number 2*64 (known as 0 
in some circles) in the same epoch, and flood of good frames 
with increasing sequence numbers.

Now doesn't the DTLS just recognize 0 as already received, 
and discard it?h
Ok, for commercial systems, I'm assuming unrealistic 
windows, bit stores, queue length etc. But, if I then 
receive a frame whose sequence_number I have not previously 
received, I just accept it don't I?

That is, in *this* context it didn't "wrap" did it?

--------

This is all interesting tho. There is also the TFTP approach 
to SSL over UDP with a reasonable reliability mechanism from 
tftp itself, and the EAP-TLS with its built in 
fragmentation/retry process, including now the record_layer 
(as EAP-TLS now has its privacy mode for sending user id to 
the radius server).

I'm not sure why DTLS has such a grudge against RC4.

, ----- Original Message -----
From: "Mike" <[email-masked]>
To: "tls mailing list" <[email-masked]>
Sent: Thursday, January 18, 2007 9:38 AM
Subject: Re: [TLS] What's the proper alert for sequence 
wrap.

>> In a implementation, if one does not want to support 
>> sequence number wrap with renegotiation, a fatal alert 
>> should be sent to peer if the sequence number exceed. Or 
>> if one side receive a wrapped sequence number, a fatal 
>> alert also should be sent to peer. However, I don't find 
>> proper alert descriptions for both read and write 
>> sequence number exceed cases.
>>
>> Any suggestions?
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 18 Jan 2007 13:14:45 -0800

<[email-masked]> writes:
> Lets assume we are in a connectionless environment, and the bearer is
> Not UDP/IP.  Its just ethernetv2. Assume we are NOT supported by a
> connectionless upper layer stack
>
> We handshake according to the author's scheme in DTLS, setting up
> classical duplication detect windows and out of order queues.
>
> (NB DTLS REQUIRES us to operate in application space, note, to
> implement the intent of the designers. Why?... cannot I make a
> (trusted) socket implementation even if the bearer was UDP?)

There's no reason you can't use DTLS that way.

> Lets say, the DTLS sender is a switch working with BPDUs send 2**s
> packets a second (s) on a ramp, and it now loses 2**s-1 sequence
> numbers in that same second (s) due to a faulty MAC hardware engine.
> That is, the switch generates the frame and then just throws it away
> detecting the mac error in its ASICs, as the speed of at line speed
> ~10G. Thus, in practice it actually communicates 1 frame a second
> And, the world of hardware being as strange as it is, the receiver now
> happens to receives seq_number 2*64 (known as 0 in some circles) in
> the same epoch, and flood of good frames with increasing sequence
> numbers.
>
> Now doesn't the DTLS just recognize 0 as already received, and discard
> it?h
> Ok, for commercial systems, I'm assuming unrealistic windows, bit
> stores, queue length etc. But, if I then receive a frame whose
> sequence_number I have not previously received, I just accept it don't
> I?

If you assume that DTLS is using an infinite replay window, yes, it
treats this as a replay. That's why you can't allow the sequence
number to wrap on the sender side, because it creates ambiguity/aliasing.

> I'm not sure why DTLS has such a grudge against RC4.

Because it's very difficult to make RC4 work properly in an
out-of-order delivery mode, which we learned to our distress
with WEP.

-Ekr

---

From: "Omirjan Batyrbaev" <[email-masked]>
Date: Fri, 26 Jan 2007 16:16:04 -0500

Hi,

How in practice does a SSL/TLS server assigns the new session IDs?
Say, does it increment the older session ID?
-Omirjan

---

From: Mike <[email-masked]>
Date: Fri, 26 Jan 2007 14:15:56 -0800

> Say, does it increment the older session ID?

In my server the first 32 bits are the UNIX time() and the
remaining 28 bytes are random.  I include the time to make
it easy to expire old sessions.

Mike