Re: [TLS] Final (hopefully) issues with DTLS 1.2

[Sean Turner <[e-mail]>]

Can we have comments back by the 8th?  That way if we need to make 
changes we can get them in before the submission deadline on the 11th.

spt

On 7/3/11 8:58 PM, Eric Rescorla wrote:
> I have now submitted draft -06, which (I believe) matches Nikos's
> version number fix.
>
> As Nikos objected to giving the CCS a sequence number and nobody spoke up for
> it, I left it as-is and added a warning. I would mildly favor adding
> one, but I don't
> think the change is appropriate absent support from the WG which has not yet
> been observed. If people believe that this change is appropriate, please speak
> up. Otherwise I believe we are done.
>
> Best,
> -Ekr
>
> On Tue, Jun 14, 2011 at 9:41 AM, Joe Salowey<[e-mail]>  wrote:
>> The open issue is with respect to the version number that Nikos raised.  Eric is working on text along the lines of Nikos' recommendation of fixing the version number.
>>
>> Joe
>> On Jun 9, 2011, at 6:29 AM, Sean Turner wrote:
>>
>>> Does anybody else have thoughts about this?  I'd really like to be able to put this draft to bed.
>>>
>>> spt
>>>
>>> On 5/23/11 9:19 AM, Eric Rescorla wrote:
>>>> Following up on Prague, here is the new text for the 2MSL and the
>>>> record sequence number issues:
>>>>
>>>>
>>>>
>>>> MSL:
>>>> 4.1.
>>>>     Note that because DTLS records may be reordered, a record from epoch
>>>>     1 may be received after epoch 2 has begun. In general,
>>>>     implementations SHOULD discard packets from earlier epochs, but if
>>>>     packet loss causes noticeable problems MAY choose to retain keying
>>>>     material from previous epochs for up to the default MSL specified for
>>>>     TCP [TCP] to allow for packet reordering. (Note: the intention here
>>>>     is that implementors use the current guidance from the IETF for MSL,
>>>>     not that they attempt to interrogate the MSL the system TCP stack is
>>>>     using.)  Until the handshake has completed, implementations MUST
>>>>     accept packets from the old epoch.
>>>>
>>>>     ...
>>>>
>>>> 4.2.4.
>>>>     In addition, for at least twice the default MSL defined for [TCP],
>>>>     when in the FINISHED state, the node which transmits the last flight
>>>>     (the server in an ordinary handshake or the client in a resumed
>>>>     handshake) MUST respond to a retransmit of the peer's last flight
>>>>     with a retransmit of the last flight. This avoids deadlock conditions
>>>>
>>>>
>>>>
>>>>
>>>> Record Sequence Number:
>>>>     When responding to a HelloVerifyRequest the client MUST use the same
>>>>     parameter values (version, random, session_id, cipher_suites,
>>>>     compression_method) as it did in the original ClientHello.  The
>>>>     server SHOULD use those values to generate its cookie and verify that
>>>>     they are correct upon cookie receipt.  The server MUST use the same
>>>>     version number in the HelloVerifyRequest that it would use when
>>>>     sending a ServerHello.  Upon receipt of the ServerHello, the client
>>>>     MUST verify that the server version values match. In order to avoid
>>>>     sequence number duplication in case of multiple HelloVerifyRequests,
>>>>     the server MUST use the record sequence number in the ClientHello as
>>>>     the record sequence number in the HelloVerifyRequest.
>>>>
>>>> ...
>>>>
>>>>     When the second ClientHello is received, the server can verify that
>>>>     the Cookie is valid and that the client can receive packets at the
>>>>     given IP address.  In order to avoid sequence number duplication in
>>>>     case of multiple cookie exchanges, the server SHOULD use the record
>>>>     sequence number in the ClientHello as the record sequence number in
>>>>     its initial ServerHello. Subsequent ServerHellos will only be sent
>>>>     after the server has created state and MUST increment normally.
>>>>
>>>> I believe this matches what I said in Prague, but any objections to
>>>> this in concept or the way I've written it up.
>>>>
>>>>
>>>> Finally, I've been rethinking the issue of the interaction of the
>>>> ChangeCipherSpec and the handshake sequence numbers. In Prague I
>>>> suggested not changing this and just putting a note in the spec that
>>>> one had to be careful, but at this point I am thinking it might be
>>>> better to simple suck up the change and put a message sequence number
>>>> in the CCS. This removes the need to consult the handshake state
>>>> machine in order to deal with reordering, though not in order to
>>>> determine whether the CCS is at the appropriate place in the handshake
>>>> (in order to detect misbehaving or malicious behavior early).  The
>>>> downside for this is that it's a difference from TLS, but it seems
>>>> like fairly easy code--though I admit I haven't tried to code it up. I
>>>> don't think either way represents a security issue, but doing it this
>>>> way means that we won't need to be as careful in the future about
>>>> having the state machine be completely deterministic prior to the CCS,
>>>> which seems like the Right Thing. Comments?
>>>>
>>>> -Ekr
>>>> _______________________________________________
>>>> TLS mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>
>>> _______________________________________________
>>> TLS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>