Subject: [quicwg/base-drafts] TLS alert no_application_protocol is not always possible (#3580)

From: Andrew Macedonia <[email-masked]>
Date: Tue, 14 Apr 2020 11:50:08 -0700

Sec 8.1. of the quic-tls draft states that, if an application protocol is not negotiated, endpoints MUST immediately terminate the connection with a no_application_protocol TLS alert (QUIC error code 0x178).

For additional security, some TLS implementations choose to hide the exact reason for a handshake failure, and only issue a handshake_failure alert instead. The QUIC layer obtaining the "true alert" may be difficult or impossible.

Maybe the requirement to send no_application_protocol should be a SHOULD instead.

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Apr 2020 17:41:45 -0700

This is probably fine as the reason is observable.  It is true that some TLS alerts are hidden, but that is generally because that leaks private information.  But here the information is public, or at least shared by client and server.

Is the concern that this is potentially sent in an Initial frame?  Because that shouldn't be necessary, or even possible.

-- 
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/3580#issuecomment-613751098

---

From: Andrew Macedonia <[email-masked]>
Date: Wed, 15 Apr 2020 09:43:56 -0700

I'm not concerned with the security implications, or lack thereof, of sending no_application_protocol. My main concern is that we, and other implementations, will be non-compliant with the draft because we have no choice but to send a general handshake_failure alert in this case. Our TLS implementation doesn't allow us to choose which alerts are converted to handshake_failure before being reported to QUIC; it's all or nothing.

-- 
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/3580#issuecomment-614150446

---

From: Martin Thomson <[email-masked]>
Date: Wed, 15 Apr 2020 16:21:14 -0700

I'm not sure that I'm following this: you are sending a QUIC CONNECTION_CLOSE frame, not a TLS alert.  Our stack makes the appropriate CONNECTION_CLOSE directly without talking to TLS.

-- 
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/3580#issuecomment-614327406

---

From: Andrew Macedonia <[email-masked]>
Date: Thu, 16 Apr 2020 08:09:03 -0700

I'm referring to the error code field in the QUIC CONNECTION_CLOSE frame. In the case of a crypto error, the QUIC error code for handshake failure is 0x128. The QUIC error code for no application protocol is 0x178. The draft mandates that we send 0x178.

In our stack, TLS does the ALPN parsing and if there is a TLS alert, QUIC converts it to a CONNECTION_CLOSE with the reported error code; TLS alert 0x28 for handshake_failure, 0x78 for no_application_protocol. Due to TLS converting all alerts during the handshake to handshake_failure, we end up sending a QUIC CONNECTION_CLOSE frame with 0x128, instead of 0x178.

-- 
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/3580#issuecomment-614712587

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 16 Apr 2020 08:26:07 -0700

I believe what you are asking is already catered for. The requirement for the failure case is MUST close, and the most appropriate error code is defined.

[Draft 27 Section 11 says](https://tools.ietf.org/html/draft-ietf-quic-transport-27#section-11)
```
   The most appropriate error code (Section 20) SHOULD be included in
   the frame that signals the error.  Where this specification
   identifies error conditions, it also identifies the error code that
   is used; though these are worded as requirements, different
   implementation strategies might lead to different errors being
   reported.  In particular, an endpoint MAY use any applicable error
   code when it detects an error condition; a generic error code (such
   as PROTOCOL_VIOLATION or INTERNAL_ERROR) can always be used in place
   of specific error codes.
```

-- 
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/3580#issuecomment-614722375

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 16 Apr 2020 08:31:34 -0700

To follow up with a way to resolve this. I don't believe we need to change any normative language and so this is not a design issue. I'll leave it to editors' discretion on whether there is any editorial work required to address the original concern.

-- 
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/3580#issuecomment-614725441

---

From: Martin Thomson <[email-masked]>
Date: Thu, 16 Apr 2020 15:29:16 -0700

I'm still stuck on how the TLS code needs to be involved in this.  Our code generates the alert, but does so [in QUIC-specific code](https://github.com/mozilla/neqo/blob/aa63c20cfb6afa5cebe678726215c98bd8122001/neqo-transport/src/connection.rs#L1765-L1769).

-- 
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/3580#issuecomment-614929473

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 16 Apr 2020 16:16:27 -0700

@martinthomson I think the problem is due to how certain implementation handles ALPN.

In case of H2O, we handle ALPN in our _on_client_hello_ callback, that is invoked by picotls (https://github.com/h2o/h2o/blob/master/src/main.c#L356). At this point, the call stack is H2O (application) -> quicly (QUIC stack) -> picotls (TLS stack) -> _on_client_hello_ (application callback).

In this type of design, if the TLS stack is going to determine the error code (or change the error code returned from a callback), then it would be impossible (or difficult) for the QUIC stack to send the appropriate code.

-- 
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/3580#issuecomment-614944134

---

From: Martin Thomson <[email-masked]>
Date: Thu, 16 Apr 2020 16:47:30 -0700

I see.  I hope that the application isn't the callback code, but that quicly is involved in this somehow; otherwise, you have just made H2O responsible for fulfilling QUIC requirements that you might assume quicly would be responsible for.

In general, I would assume that you have access to QUIC transport state in your callback from the TLS stack.  Let's say that you choke on the ALPN.  You cause TLS to issue a generic alert (which is fine, as Lucas points out).  At some later point that alert is going to hit QUIC code again so that it can be translated to a QUIC alert.  If you can save the reason from the callback (presumably you need this capability to save transport parameters) then you can construct the right message.

Of course, that's complicated.  The generic alert is fine.

-- 
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/3580#issuecomment-614953736

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 16 Apr 2020 16:59:48 -0700

FWIW this particular error code is the one I've seen the most of during interop. So I will make the observation that anyone building a stack that causes an ALPN failure to not be exposed, is going to cause a lot of problems for future QUIC as a generic transport layer. 

-- 
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/3580#issuecomment-614958253

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 16 Apr 2020 20:28:33 -0700

@martinthomson 
> I hope that the application isn't the callback code, but that quicly is involved in this somehow; otherwise, you have just made H2O responsible for fulfilling QUIC requirements that you might assume quicly would be responsible for.

Yeah I think my preference goes to not having an abstraction layer in our QUIC protocol stack for hiding TLS handshake protocol API. I'd argue that the intent of using TLS in QUIC is to reuse TLS including its extensions when possible. Requiring (or recommending) a QUIC stack to provide abstraction for those extensions (that happen at the handshake protocol level) reduces that benefit.

That said, I think we agree that in this particular case a generic alert is fine, and that what we need at most is an editorial improvement.

-- 
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/3580#issuecomment-615017711

---

From: martinduke <[email-masked]>
Date: Fri, 17 Apr 2020 11:18:01 -0700

I agree that the normative requirements are fine. It would be good to expose the specific ALPN error, and we can make the necessary TLS change to detect this properly.

However, "generic TLS alerts" are a user-configurable setting, and we're reluctant to just override customer preference just because it's in a CONNECTION_CLOSE instead of a TLS Alert.

Moreover, when the TLS WG gets around to encrypting the ALPN, it is not clear that exposing this error is so benign anymore.

-- 
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/3580#issuecomment-615392681

---

From: Lucas Pardue <[email-masked]>
Date: Sat, 18 Apr 2020 05:48:54 -0700

>Moreover, when the TLS WG gets around to encrypting the ALPN, it is not clear that exposing this error is so benign anymore.

Will ESNI/ECHO define a way to protect the confidentiality of such TLS alerts?

-- 
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/3580#issuecomment-615863425

---

From: ekr <[email-masked]>
Date: Sat, 18 Apr 2020 06:45:16 -0700

On Sat, Apr 18, 2020 at 5:48 AM Lucas Pardue <[email-masked]>
wrote:

> Moreover, when the TLS WG gets around to encrypting the ALPN, it is not
> clear that exposing this error is so benign anymore.
>
Not with the current designs, but we've been discussing encrypting more, in
which case maybe?

-Ekr

—
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/3580#issuecomment-615863425>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAIPLIJFZLU4C24YXTXZZEDRNGOS7ANCNFSM4MH7AOMQ>
> .
>

-- 
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/3580#issuecomment-615874336