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.
> 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 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!).
> > 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).
-Ilari
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
