Subject: [quicwg/base-drafts] Define the use of generic TLS alerts (#3601)

From: Martin Thomson <[email-masked]>
Date: Mon, 27 Apr 2020 21:46:59 -0700

This was already permitted by the transport document, but it was not
adequately explained.  The example that tripped us up was ALPN, which
has received a bit of attention here.

Closes #3580.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3601

-- Commit Summary --

  * Define the use of generic TLS alerts

-- File Changes --

    M draft-ietf-quic-tls.md (29)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3601.patch
https://github.com/quicwg/base-drafts/pull/3601.diff

-- 
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/pull/3601

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 27 Apr 2020 23:17:24 -0700

@kazuho commented on this pull request.

> @@ -1567,12 +1573,13 @@ QUIC requires that the cryptographic handshake provide authenticated protocol
 negotiation.  TLS uses Application Layer Protocol Negotiation (ALPN)
 {{!ALPN=RFC7301}} to select an application protocol.  Unless another mechanism
 is used for agreeing on an application protocol, endpoints MUST use ALPN for
-this purpose.  When using ALPN, endpoints MUST immediately close a connection
-(see Section 10.3 in {{QUIC-TRANSPORT}}) if an application protocol is not
-negotiated with a no_application_protocol TLS alert (QUIC error code 0x178, see
-{{tls-errors}}).  While {{!ALPN}} only specifies that servers use this alert,
-QUIC clients MUST also use it to terminate a connection when ALPN negotiation
-fails.
+this purpose.
+
+When using ALPN, endpoints MUST immediately close a connection (see Section
+10.3 of {{QUIC-TRANSPORT}}) if an application protocol is not negotiated with a
+no_application_protocol TLS alert (QUIC error code 0x178, see {{tls-errors}}).
+While {{!ALPN}} only specifies that servers use this alert, QUIC clients MUST
+use error 0x178 to terminate a connection when ALPN negotiation fails.

Am I correct to read that this MUST requires a client that receives a no_application_protocol alert to respond with a no_application_protocol alert?

I am not sure if that aligns to what we have now. At the moment, the provisions that we have is that an endpoint that receives CONNECTION_CLOSE MAY respond with a CONNECTION_CLOSE, using NO_ERROR if appropriate (https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-10.3-7).

Based on that, I think what we need here is MAY rather than MUST, and think that NO_ERROR is more appropriate (assuming that we do not have a principle of an endpoint that receives a CONNECTION_CLOSE frame carrying an error echo the error code it has received). Or it might make sense to just drop the last sentence.

-- 
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/pull/3601#pullrequestreview-401526081

---

From: Mike Bishop <[email-masked]>
Date: Tue, 28 Apr 2020 11:43:37 -0700

@MikeBishop commented on this pull request.

I think this is intended to apply to the case when a server does not include an ALPN extension.  If the client receives an alert, ALPN isn't really the thing that failed -- the handshake is.

-- 
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/pull/3601#discussion_r416841101

---

From: Mike Bishop <[email-masked]>
Date: Tue, 28 Apr 2020 11:46:36 -0700

```suggestion
10.3 of {{QUIC-TRANSPORT}}) with a no_application_protocol TLS alert (QUIC
error code 0x178, see {{tls-errors}}) if an application protocol is not negotiated.
```
"close a connection with... if..." makes it clearer which phrase the "with" applies to.

-- 
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/pull/3601#pullrequestreview-402115147

---

From: David Schinazi <[email-masked]>
Date: Tue, 28 Apr 2020 12:06:42 -0700

@DavidSchinazi commented on this pull request.

 The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT generate
 alerts at the "warning" level.
 
+QUIC permits the use of a generic code in place of a specific error code; see
+Section 11 of {{QUIC-TRANSPORT}}. For TLS alerts, this includes replacing any
+alert with a generic alert, such as handshake_failure (0x128 in QUIC).
+Endpoints might use a generic error code to avoid possibly exposing

should this might be a MAY?

-- 
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/pull/3601#pullrequestreview-402128775

---

From: Martin Thomson <[email-masked]>
Date: Tue, 28 Apr 2020 15:48:25 -0700

@martinthomson pushed 1 commit.

475242d0c9ca9e32113c90859748c7adf577fdfc  Tweaks from review

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3601/files/b41c848f281bda976192136c6281185808c5e021..475242d0c9ca9e32113c90859748c7adf577fdfc