Subject: [quicwg/base-drafts] Make SNI more clearly mandatory (#3326)

From: Martin Thomson <[email-masked]>
Date: Tue, 07 Jan 2020 21:46:40 -0800

To avoid conflicts, this includes what appears to be the generally-agreed #3323.

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

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

-- Commit Summary --

  * Require QUICv1
  * Make host specification more precise

-- File Changes --

    M draft-ietf-quic-http.md (18)
    A draft-ietf-quic-tls.xml (3042)
    A draft-ietf-quic-transport.xml (8992)
    A h (5843)
    A metadata.min.js (1)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3326.patch
https://github.com/quicwg/base-drafts/pull/3326.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/3326

---

From: ekr <[email-masked]>
Date: Wed, 08 Jan 2020 05:51:52 -0800

Something seems to have gone wrong with ```git add``` here.

-- 
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/3326#issuecomment-572063977

---

From: ekr <[email-masked]>
Date: Wed, 08 Jan 2020 05:54:29 -0800

ekr commented on this pull request.

> @@ -312,11 +317,14 @@ an explicit port.
 
 ## Connection Establishment {#connection-establishment}
 
-HTTP/3 relies on QUIC as the underlying transport.  The QUIC version being used
-MUST use TLS version 1.3 or greater as its handshake protocol.  HTTP/3 clients
-MUST indicate the target domain name during the TLS handshake. This may be done
-using the Server Name Indication (SNI) {{!RFC6066}} extension to TLS or using
-some other mechanism.
+HTTP/3 relies on QUIC version 1 as the underlying transport.  The use of other
+QUIC transport versions with HTTP/3 MAY be defined by future specifications.
+
+QUIC version 1 uses TLS version 1.3 or greater as its handshake protocol.
+HTTP/3 clients MUST support a mechanism to indicate the target host to the
+server during the TLS handshake.  Unless an alternative mechanism for indicating
+the target host is used, clients MUST use the Server Name Indication (SNI)
+{{!RFC6066}} extension to TLS if the target host is a DNS name.

Maybe
"If the server is identified by a DNS name, clients MUST send the Server Name Indication (SNI) ... extension to TLS unless an alternative mechanism for indicating the server is available"

Note that we'll want to carefully word this to avoid requiring SNI when doing QUIC with mDNS candidates for WebRTC.

-- 
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/3326#pullrequestreview-339876987

---

From: Mike Bishop <[email-masked]>
Date: Wed, 08 Jan 2020 08:50:55 -0800

MikeBishop approved this pull request.

I like @ekr's wording, but the content looks sound.

-- 
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/3326#pullrequestreview-340001152

---

From: David Schinazi <[email-masked]>
Date: Wed, 08 Jan 2020 10:23:04 -0800

DavidSchinazi commented on this pull request.

 

@ekr Do you think WebRTC would use HTTP/3? I was somewhat expecting WebRTC to build something directly over QUICv1, not over HTTP/3?

-- 
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/3326#discussion_r364375027

---

From: David Schinazi <[email-masked]>
Date: Wed, 08 Jan 2020 10:27:22 -0800

According to [RFC 6066](https://tools.ietf.org/html/rfc6066#section-3):
> "HostName" contains the fully qualified DNS hostname of the server,
> as understood by the client.

Should we replace "DNS name" with "fully qualified DNS hostname"?

-- 
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/3326#pullrequestreview-340056588

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 08 Jan 2020 11:21:17 -0800

RyanAtGoogle commented on this pull request.

 

In general, I don't think clients know if the hostname of the server in the URL is fully qualified or not, so the "as understood by the client" part seems important.

-- 
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/3326#discussion_r364400575

---

From: ekr <[email-masked]>
Date: Wed, 08 Jan 2020 14:56:49 -0800

On Wed, Jan 8, 2020 at 10:22 AM David Schinazi <[email-masked]>
wrote:

> *@DavidSchinazi* commented on this pull request.
> ------------------------------
>
> In draft-ietf-quic-http.md
> <https://github.com/quicwg/base-drafts/pull/3326#discussion_r364375027>:
>
> @ekr <https://github.com/ekr> Do you think WebRTC would use HTTP/3? I was
> somewhat expecting WebRTC to build something directly over QUICv1, not over
> HTTP/3?
>
Oh, yes. I missed which document this was in.

> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/pull/3326?email_source=notifications&email_token=AAIPLINHXJVVGSN4A4G5ZJ3Q4YKX7A5CNFSM4KEDE2WKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCRCNCNQ#discussion_r364375027>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAIPLIK34YQZLQWRQR7M5TDQ4YKX7ANCNFSM4KEDE2WA>
> .
>

-- 
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/3326#issuecomment-572298035

---

From: Martin Thomson <[email-masked]>
Date: Wed, 08 Jan 2020 17:53:03 -0800

martinthomson commented on this pull request.

 

Yeah, I don't think that the WebRTC case applies here, though as a general caution it is worth bearing in mind.  ESNI might be modeled as an alternative that is OK on those terms, but if the information is deliberately withheld on the basis of privacy in a specific context, then this requirement could be problematic.  I would expect an update to this document to be necessary in that case.

> "If the server is identified by a DNS name, clients MUST send the Server Name Indication (SNI) ... extension to TLS unless an alternative mechanism for indicating the server is available"

This says something subtly different logically.  I had the ordered list:

1. if alternative, use that
2. if domain name, use SNI
3. else, don't bother

This says:

1. if domain name,
   a. if alternative, use that
   b. else, use SNI
2. else don't bother

I'm OK with that, but I want to recognize the subtle distinction.  On balance, it's a good distinction because it avoids levying requirements for identification of non-domain names, but I wanted to highlight that to be sure that we all agree that is the intent.

-- 
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/3326#discussion_r364527949

---

From: Martin Thomson <[email-masked]>
Date: Thu, 09 Jan 2020 01:21:27 -0800

@martinthomson pushed 1 commit.

93f05af754967fb1a314a33a9417bfaf1afc73dd  Make host specification more precise

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3326/files/cd927637b6c8153974f44212b6d052567f02ab36..93f05af754967fb1a314a33a9417bfaf1afc73dd