Hi Ilari, a few remarks inline:
On 07/06/2016 04:47 PM, Ilari Liusvaara wrote:
> On Wed, Jul 06, 2016 at 02:34:07PM +0200, Hannes Tschofenig wrote:
>>
>> 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.)
>
> Being part of regular handshake is problematic, since those are assumed
> to be tickets, and as such one needs the dynamic PSK key. But the dynamic
> PSK key includes the entiere handshake up to Client Finished. And this
> can't really be changed (or things start going badly wrong).
>
> So the minimum time to send some tickets is 4th flight, whereas normal
> handshake is only 3 flights.
Was just an idea. The TLS 1.2 ticket mechanism was also transmitted
during the handshake.
>
>> 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.
>
> Certificate requests have context identifiers...
I was more thinking about including the HandshakeType to distinguish the
ack for a NewSessionTicket from an ack to a CertificateRequest.
>
>> 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?
>
> Yeah.
>
>> 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?
>
> I don't think this works, because KeyUpdate is not idempotent (causes
> problems if reply is lost) and worse yet, because of potential desyncs
> with the main data flow (IP packet reordering!).
Maybe it should be made idempotent...
>
>>> 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?
>
> Each listed one essentially corresponds to one key connection can use:
>
> - Unencrypted (CH/SH/HRR)
> - 0-RTT handshake key (Finished)
> - 0-RTT data key (0-RTT appdata)
> - Handshake key (Encrypted Extensions to Client Finished)
> - Application key from initial traffic_secret_0.
> - Application key from traffic_secret_N (N>0).
>
Thanks. Makes sense.
Ciao
Hannes
>
>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
