Hi Ilari, Hi Ekr, a few remarks inline:
~snip~
>>>> - The handshake retransmit scheme doesn't seem to work that
>>>>> well with post-handshake auth, and even less well with
>>>>> session tickets.
>>>> Why do you think so? Of course, unreliable transports creates
>>>> inconvenience; is it that what you are referring to?
>>>
>>> DTLS assumes handshake messages are reliable, and that reliability is
>>> implemented via handshake messages ACKing one another.
>>>
>>> - Session tickets have no ACK at all.
>>>
>>
>> DTLS 1.3 should add an ACK, IMO.
>
> Yeah, not going to work without. And I presume something might be
> needed for dynamic reauth too...
I was wondering about one design decision regarding the ack.
If we don't use the epoch instead of the KeyUpdate then there is only
one other message that does not have an ack, namely the NewSessionTicket
message. (I might be worthwhile to think about why the server can send
it at any time and why it isn't sent as part of the regular handshake
instead. This would make the issue with acks potentially go away.)
The post-handshake authentication with the CertificateRequest comes with
an ack (even though it may be delayed), namely Certificate,
CertificateVerify, and Finished (and in case of a decline with a
certificate and a finished). Would it be worthwhile to ack them as well
due to the potential delay caused by user interaction?
Let us say that we provide an ack for the NewSessionTicket message then
it is sufficient to specify a very simple ack, namely one that is
defined as: struct {} Ack;
If we also ack the post-handshake authentication then it is necessary to
include some identifier in the Ack message to indicate which message is
acked.
What are your thoughts about this?
>
>>> - CertificateRequest can have very slow ACK.
>>> - KeyUpdate has no real ACK (and isn't idempotent either).
>>>
>>
>> Yes, I think we should remove KeyUpdate for DTLS 1.3 and just use epoch
>> instead.
I believe that using epoch for updating the cryptographic keys is pretty
much like a key update. Essentially, we are talking about taking the
epoch value from the incoming packet and then figuring out what security
context is applicable. Correct?
An alternative design would be to require the receiver of a KeyUpdate to
return a KeyUpdate as well. This would then constitute a flight.
Wouldn't this be better?
>
> How many special epochs we need?
>
> 0 => Unencrypted messages
> 1 => 0-RTT control messages (just one finished[1]!)
> 2 => 0-RTT data messages
> 3 => primary handshake
> 4 => application data
> 5-N => rekey connection
I guess you want to introduce these different epoch values and associate
them with different phases during the handshake since the TLS 1.3 key
derivation is more sophisticated than the TLS 1.2 version.
Is this correct?
Ciao
Hannes
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
