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

[Joe Salowey <[e-mail]>]

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