Subject: [quicwg/base-drafts] Signaling TLS handshake failure (#272)

From: Martin Thomson <[email-masked]>
Date: Wed, 08 Feb 2017 13:52:04 -0800

This needs to be written down.  I think that the best outcome would be to include BOTH a TLS alert and a QUIC error code (in a CONNECTION_CLOSE frame).

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

---

From: ianswett <[email-masked]>
Date: Wed, 08 Feb 2017 17:10:26 -0800

I don't know if there's an open issue for this, but I think the only frames we want to send unencrypted are stream frames for stream 1 and ack frames.  Those we believe are necessary and even ack frames have special rules, as we've discussed.

We could send an unencrypted connection close frame, but I'm having a hard time seeing cases when a TLS alert wouldn't be better.   And in other cases, a public reset is sufficient.

-- 
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/272#issuecomment-278515567

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 08 Feb 2017 17:41:44 -0800

CONNECTION_CLOSE should definitely be allowed. There are any number of insane things a client could do which would cause the server to want to tear down the connection. When this happens, it's very valuable for the client to see the error code from the server. 

-- 
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/272#issuecomment-278520982

---

From: Martin Thomson <[email-masked]>
Date: Wed, 08 Feb 2017 18:43:22 -0800

@ianswett, there's lots of *text* on the point of what can be unencrypted, and some issues on the finer points (like the issue around acknowledgments).

As you say, the TLS alert is going to be useful for diagnosis if nothing else, but if we are to maintain our layering, we need a CONNECTION_CLOSE as well.  Luckily, they can both be carried in a single packet.

-- 
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/272#issuecomment-278530875

---

From: ianswett <[email-masked]>
Date: Wed, 08 Feb 2017 18:56:52 -0800

I may be missing it, but when I skimmed and searched in the transport draft, I couldn't find anywhere it said what frame types may be sent without encryption.

I'm happy to have both TLS alerts and connection closes if they're useful.  Ryan reminded me there have been some cases when unencrypted connection close errors were able to provide valuable insight to debug an issue.

-- 
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/272#issuecomment-278532788

---

From: Martin Thomson <[email-masked]>
Date: Wed, 08 Feb 2017 19:07:53 -0800

The TLS draft has all that text.  Currently.

-- 
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/272#issuecomment-278534306