Subject: [quicwg/base-drafts] ClientInitial is special (#627)

From: ekr <[email-masked]>
Date: Tue, 13 Jun 2017 01:24:16 -0700

The motivation for this issue is: What happens if you receive a ServerCleartext packet that contains SH but *doesn't* contain the acknowledgement for CI? Should you eventually retransmit CI? This doesn't make sense, but the protocol suggests you should.

We could just make it an exception, but I think we might want to go bigger. Specifically, I propose we take the data in ClientInitial out of stream 0 and make it special data. It is anyway because it can't be fragmented, has to be padded, etc. Then the client's second flight would go in stream 0 at offset 0.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/627

---

From: MikkelFJ <[email-masked]>
Date: Tue, 13 Jun 2017 02:38:29 -0700

Related question - why does the client send end of handshake in a cleartext packets after receiving server handshake, except for retransmission of earlier packets no longer needed.

QUIC TLS draft section 4.1:

>  @C QUIC STREAM Frame(s) <0>:
        (EndOfEarlyData)
        {Finished}

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/627#issuecomment-308062519

---

From: ekr <[email-masked]>
Date: Tue, 13 Jun 2017 02:55:12 -0700

It avoids double-encryption of the TLS handshake packets.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/627#issuecomment-308066802

---

From: MikkelFJ <[email-masked]>
Date: Tue, 13 Jun 2017 03:33:30 -0700

> It avoids double-encryption of the TLS handshake packets.

I may get the following wrong, as I haven't studied everything in detail yet, but my take is, ignoring 0RTT:

If the server was required to only respond with a single packet, and double encryption was acceptible (which I think is not problem at all), then the handshake could have the form:

@c ClientInitial ->
<-c ServerInitial
@1-> stream 0{EndOfEarlyData, Finished}, Optionally other streams ->

No ACKS in server to client, no acks in client to server.

If these initial packets are made special, as you suggest with ClientInitial, we can also drop packet numbering of these.

This also avoids the issue with ACKS of untrusted packets during handshake: https://github.com/quicwg/base-drafts/issues/624

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/627#issuecomment-308075737

---

From: MikkelFJ <[email-masked]>
Date: Tue, 13 Jun 2017 03:38:35 -0700

In addition, I suggest that ServerInitial sends reflects the Client Connection ID (CCID) and ALSO sends a new Server Connection ID (SCID). This uniquely links the client request to the server response, and also handles Stateless Retry and Version Negotiation packet responses if these do the same thing, mirroring CCID except these other packets won't have a SCID. In addition, this would avoid having to rely on the uniqueness of a 5-tuple for setting up and maintaining connection state.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/627#issuecomment-308076853

---

From: ekr <[email-masked]>
Date: Tue, 13 Jun 2017 03:42:20 -0700

"If the server was required to only respond with a single packet..."

This is not a reasonable assumption. Certificates regularly push you over the MTU.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/627#issuecomment-308077605

---

From: MikkelFJ <[email-masked]>
Date: Tue, 13 Jun 2017 03:46:55 -0700

> This is not a reasonable assumption. Certificates regularly push you over the MTU.

Could this not also happen to client certificates when server requires auth?

Could certs be seperate from Diffie-Hellman?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/627#issuecomment-308078615

---

From: ekr <[email-masked]>
Date: Tue, 13 Jun 2017 04:02:23 -0700

> Could this not also happen to client certificates when server requires auth?

Yes.

> Could certs be seperate from Diffie-Hellman?

They are. Client certificates are sent in the second flight.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/627#issuecomment-308081785

---

From: MikkelFJ <[email-masked]>
Date: Tue, 13 Jun 2017 04:13:16 -0700

> They are. Client certificates are sent in the second flight.

So in principle this could also apply to server certs, and then you could have fully protected packets except for the initial key exchange.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/627#issuecomment-308083958

---

From: MikkelFJ <[email-masked]>
Date: Tue, 13 Jun 2017 04:26:42 -0700

It would also deal with #597,#608 - especially if CCID is reflected, and paired with SCID when available, on all unprotected server sent packets.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/627#issuecomment-308086762

---

From: ekr <[email-masked]>
Date: Tue, 13 Jun 2017 04:30:57 -0700

This would add a new type of complexity because the keys that are available after the initial key exchange are not the same as those which are available after the handshake completes.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/627#issuecomment-308087671

---

From: MikkelFJ <[email-masked]>
Date: Tue, 13 Jun 2017 04:56:58 -0700

Is that necessarily so, given stateless retry? And key phase must be handled anyway. I don't want to add complexity though. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/627#issuecomment-308093085

---

From: ekr <[email-masked]>
Date: Tue, 13 Jun 2017 05:17:49 -0700

On Tue, Jun 13, 2017 at 12:56 PM, MikkelFJ <[email-masked]> wrote:

> Is that necessarily so, given stateless retry?
>

It's a property of the TLS handshake.

And key phase must be handled anyway.

Well, it's also complexity at the TLS layer: we don't even export that key

> I don't want to add complexity though.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/627#issuecomment-308093085>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABD1ob8O8-In2lq9FB8GGgFj6vOxo1Kpks5sDnkJgaJpZM4N4JZC>
> .
>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/627#issuecomment-308097503