Subject: [quicwg/base-drafts] Handshake packets and is_retransmittable (#526)

From: Lars Eggert <[email-masked]>
Date: Tue, 16 May 2017 07:03:11 -0700

The definition of `is_retransmittable` only talks about packets that are containing various frame types. But it should also talk about handshake packets requiring retransmission, because otherwise the pseudo code for `OnPacketSent` never calls `SetLossDetectionAlarm`. 

(Or a call to `SetLossDetectionAlarm` needs to be explicitly added for 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/526

---

From: Lars Eggert <[email-masked]>
Date: Tue, 16 May 2017 07:08:35 -0700

Or is there an implicit assumption that handshake packets will always carry stream-0 data?

-- 
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/526#issuecomment-301793947

---

From: ianswett <[email-masked]>
Date: Tue, 16 May 2017 15:01:33 -0700

Yes, handshake packets must always carry stream-0 data.  I can clarify that.

-- 
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/526#issuecomment-301928547

---

From: janaiyengar <[email-masked]>
Date: Tue, 16 May 2017 17:03:17 -0700

(sorry, didn't see Ian's response.)

-- 
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/526#issuecomment-301947985

---

From: janaiyengar <[email-masked]>
Date: Tue, 16 May 2017 17:02:52 -0700

Yes, since all handshake data is carried in STREAM frames, they will be retransmittable by definition. Would it help to clarify this somewhere? 

-- 
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/526#issuecomment-301947912

---

From: Lars Eggert <[email-masked]>
Date: Tue, 16 May 2017 22:49:19 -0700

I tripped over this, because my implementation currently doesn't have stream-0 data in the handshake packets (since I am still looking for a TLS lib that has a suitable API). I've now addressed this by faking the stream-0 TLS handshake, but a few words on this might be useful.

-- 
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/526#issuecomment-301992198

---

From: Lars Eggert <[email-masked]>
Date: Tue, 16 May 2017 22:49:19 -0700

Closed #526.

-- 
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/526#event-1085354173

---

From: Lars Eggert <[email-masked]>
Date: Tue, 16 May 2017 22:49:23 -0700

Reopened #526.

-- 
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/526#event-1085354211

---

From: MikkelFJ <[email-masked]>
Date: Wed, 17 May 2017 08:02:33 -0700

@larseggert is there a place for a non-TLS profile of QUIC? Chrome is currently using Curve25519+AES-GCM + possibly SHA256/HKDF key derivation logic. This crypto can be implemented in very compact self-reliant code that does not require a complex TLS library and as such may be highly useful for embedded IoT devices. So why not formalize such a profile rather than hack around missing TLS libraries. I'm not suggesting to abandon TLS, but to provide a formal alternative with a much simpler handshake.

-- 
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/526#issuecomment-302119106

---

From: Lars Eggert <[email-masked]>
Date: Wed, 17 May 2017 10:42:07 -0700

@mikkelfj that discussion should happen in a separate ticket. 

(I have no horse in the race with regards to TLS or something else. But I also don't want to implement any crypto code. Ideally, I want to link against a minimal but widely used and audited library that lets me remain in control memory allocation and packet I/O.)

-- 
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/526#issuecomment-302170330

---

From: Mike Bishop <[email-masked]>
Date: Wed, 17 May 2017 11:01:48 -0700

Correct; SChannel is a Windows component, not an open-source library.

@mikkelfj, there is definitely a place, in my opinion.  I wouldn't be surprised to see an IoT-focused working group define a stripped down profile with some other handshake, and several of the issues we've debated around versioning and handshake mechanics are aimed at making TLS replaceable in subsequent work.  However, the alternate profile needs to supply similar properties:  key agreement, parameter transport, etc.  The *definition* of such a profile is explicitly outside the charter of this WG, 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/526#issuecomment-302175712

---

From: MikkelFJ <[email-masked]>
Date: Wed, 17 May 2017 11:12:42 -0700

OK, I'll leave it at that - a new ticket would be out of charter I suppose. Perhaps a wiki page could be useful for coordination? On crypto librariaries I have seen none that matches all of minimal, widely used and audited - but the components I mentioned are readily available with test vectors and can be liftet.

-- 
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/526#issuecomment-302179420

---

From: ianswett <[email-masked]>
Date: Wed, 17 May 2017 11:45:57 -0700

Closed #526.

-- 
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/526#event-1086548130