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

[Eric Rescorla <[e-mail]>]

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
>