Subject: Re: [quicwg/base-drafts] Make ALPN mandatory in QUIC-via-TLS (#2263)

From: MikkelFJ <[email-masked]>
Date: Wed, 02 Jan 2019 02:11:40 -0800

I don't know enough about ALPN, but if QUIC doesn't handle inhouse protocols well without bureaucracy, ALPN will get abused. What about future? decentralised approaches e.g. via DNS records?

-- 
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/2263#issuecomment-450826491

---

From: Victor Vasiliev <[email-masked]>
Date: Wed, 02 Jan 2019 12:26:40 -0800

@martinthomson The general requirement SG, though I assume you'd still have to spell out the TLS specifics in the TLS mapping document.

@kazuho I do not expect the Expert Review requirement to be a particularly strong barrier since from what I understand the bar is "the designated experts do not consider you obviously bogus".  Either way I think we can discuss within TLS working group about relaxing some of those.

-- 
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/2263#issuecomment-450975085

---

From: erickinnear <[email-masked]>
Date: Wed, 02 Jan 2019 20:32:50 +0000 (UTC)

I think requiring some form of explicit protocol negotiation would be good. The TLS draft could potentially be a bit more specific about what that looks like, too, but I agree that we don't want to be too restrictive here. 

In other words, what @martinthomson said above sounds good to me. 

-- 
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/2263#issuecomment-450976714

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 02 Jan 2019 13:15:47 -0800

@martinthomson 
> Would people be OK with "explicit protocol negotiation, such as ALPN"?

SGTM.

@mikkelfj 
> I don't know enough about ALPN, but if QUIC doesn't handle inhouse protocols well without bureaucracy, ALPN will get abused. What about future? decentralised approaches e.g. via DNS records?

I think that the concern will be resolved if we adopt @martinthomson's proposal. You would not be required to send ALPN for example when name resolution with combined protocol negotiation is being used.

-- 
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/2263#issuecomment-450987384

---

From: Martin Thomson <[email-masked]>
Date: Wed, 02 Jan 2019 15:39:52 -0800

The transport doc currently says:

> The cryptographic handshake MUST provide the following properties:
>
> * authenticated negotiation of an application protocol (TLS uses ALPN {{?RFC7301}} for this purpose)

So I think that is fine.  I've opened #2284 to make the ALPN requirement clearer.

As @kazuho says, if you have other means of agreeing on protocol, then you can avoid ALPN.  For instance, a QUIC version that could only be used with one application protocol would be one way.  In the end, you have to be sure that both client and server agree on what protocol they are talking.  I can see how binding to name resolution would work; though I can also see how it might not work (multiple subjectAltNames, failing to communicate SNI properly, coalescing, etc...).

-- 
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/2263#issuecomment-451019198

---

From: Martin Thomson <[email-masked]>
Date: Sun, 06 Jan 2019 14:09:09 -0800

Closed #2263 via #2284.

-- 
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/2263#event-2056478436