Subject: [quicwg/base-drafts] Invariants does not support public signatures on version negotiation (#1246)

From: MikkelFJ <[email-masked]>
Date: Wed, 21 Mar 2018 07:09:48 -0700

Invariants do not allow for future public signatures on the version negotation packet.

Specific versions can of course add their packets, but it would be better if the version negation packet had room for a signature that future versions could evaluate.
Doing this later in the handshake reduces the defense against handshake attacks from man-on-the-side.

The connection ID swaps the source and destination in the server transmitted vneg packet. This adds a reasonable defense against off-path attacks but makes it impossible to use the source ID for a server signature.

A simple solution would be allow the server to replace part of the source id with a public signature while preservering at least 64 octests from the client. This leaves 144 - 64 = 80 octets for a public signature. Ed25519 signatures are 64 octets - which then leaves room for an additional 80 - 64 = 16 octest for a public key identifier. Ed25519 might turn out to be weak and longer signatures would then be required. Therefore an alternative propososal would be to allow a server to append a signture after the version list. This requires a length field at the start of the version list.

NOTE: the algorithm should be left unspecified - but reserving 80 octets would allow future versions some room.

I would prefer adding a length field and allow for future data.

Quote invariant draft 01: 

>  Version Negotiation packets do not use integrity or confidentiality
   protection.  A specific QUIC version might authenticate the packet as
   part of its connection establishment process.

-- 
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/1246

---

From: Mike Bishop <[email-masked]>
Date: Wed, 21 Mar 2018 18:17:27 +0000 (UTC)

This seems to be the issue you were targeting with the solution you suggested in #1247.

-- 
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/1246#issuecomment-375045715

---

From: MikkelFJ <[email-masked]>
Date: Wed, 21 Mar 2018 18:28:20 +0000 (UTC)

Not quite - this is a concern for early auth the other is a concern for extensions - one could solve the other.

-- 
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/1246#issuecomment-375049211

---

From: Marten Seemann <[email-masked]>
Date: Thu, 22 Mar 2018 02:44:16 -0700

Is this related to #630?
Maybe we can solve both by adding a length field to the Long Header.

-- 
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/1246#issuecomment-375236447

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Mar 2018 09:48:11 +0000 (UTC)

@marten-seemann, yes, but the implied fix for #630 does not necessarily alter the invariants.

-- 
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/1246#issuecomment-375237563

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 26 Mar 2018 05:16:22 +0000 (UTC)

This was [discussed in London](https://github.com/quicwg/wg-materials/blob/master/ietf101/minutes.md#invariants-1), and there seemed to be a strong sense int he room that we didn't want to do this. Further comments?

-- 
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/1246#issuecomment-376048741

---

From: MikkelFJ <[email-masked]>
Date: Mon, 26 Mar 2018 13:12:10 +0000 (UTC)

I originally had two issues, one was extensibility and the other was the related public signing in future versions. I tend to agree that extensible vneg can get messy fast, but the lack of any hook to sign such messages is also unfortunate. I would likely create a non-standard extension.

Ian has mentioned that we could use a different version number for future vnegs - which is a decent approach. However, I believe something must be mentioned about this in the invariants. For example that clients may opt to ignore version 0 vnegs in favor of a future defined version when and if one such is defined. Lacking that it should adhere to version 0. Servers likewise.

-- 
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/1246#issuecomment-376160501