Subject: FW: New Version Notification for draft-bishop-httpbis-sni-altsvc-02.txt

From: Mike Bishop <[email-masked]>
Date: Thu, 24 May 2018 21:55:55 +0000

Ben reminded me that a lot of the suggestions we've incorporated into the GitHub version of this document hadn't made it back to an official draft.  If you haven't looked at this lately, please give it another read so we can incorporate any feedback prior to Montreal.

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Thursday, May 24, 2018 2:51 PM
To: Mike Bishop <[email-masked]>
Subject: New Version Notification for draft-bishop-httpbis-sni-altsvc-02.txt

A new version of I-D, draft-bishop-httpbis-sni-altsvc-02.txt
has been successfully submitted by Mike Bishop and posted to the IETF repository.

Name:		draft-bishop-httpbis-sni-altsvc
Revision:	02
Title:		The "SNI" Alt-Svc Parameter
Document date:	2018-05-24
Group:		Individual Submission
Pages:		9
URL:            https://www.ietf.org/internet-drafts/draft-bishop-httpbis-sni-altsvc-02.txt
Status:         https://datatracker.ietf.org/doc/draft-bishop-httpbis-sni-altsvc/
Htmlized:       https://tools.ietf.org/html/draft-bishop-httpbis-sni-altsvc-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-bishop-httpbis-sni-altsvc
Diff:           https://www.ietf.org/rfcdiff?url2=draft-bishop-httpbis-sni-altsvc-02

Abstract:
   HTTP Alternative Services provides a mechanism for an origin to
   declare that its content is accessible via some other combination of
   host, port, and protocol.  In the process of using such an
   alternative, an observer can identify that the client is requesting
   resources from a particular hostname.

   This document extends HTTP Alternative Services, in combination with
   Secondary Certificate Authentication, to enable clients not to
   disclose the origin to which they intend to connect.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Kari Hurtta <[email-masked]>
Date: Tue, 29 May 2018 18:34:34 +0300 (EEST)

I may have missed something, but is this consistent ?

3.3.  Omitting SNI
https://tools.ietf.org/html/draft-bishop-httpbis-sni-altsvc-02#section-3.3

|   Suppose a client has received the following Alt-Svc entry for
|   sensitive.example.com in the past:
|
|   h2="alternative.example.com:443";ma=2635200;persist=true;sni=""

<...>

|   If the supplied certificate does not cover sensitive.example.com, or
|   is not valid, the client will terminate the connection.

However

2.  The "sni" Alt-Svc Extension
https://tools.ietf.org/html/draft-bishop-httpbis-sni-altsvc-02#section-2

says

|   If the certificate is not valid for the origin's hostname, the client
|   MUST NOT make requests to any origin corresponding to this
|   certificate.  In this case, the client SHOULD send a
|   "CERTIFICATE_REQUEST" frame including an SNI extension indicating the
|   origin which published the alternative service immediately upon
|   connecting.

Should client send "CERTIFICATE_REQUEST" frame for sensitive.example.com 
if supplied certificate was valid for alternative.example.com.

Situtation is different if there was no sni="" at all.

Or what I have missed?

/ Kari Hurtta

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 29 May 2018 11:52:19 -0400

> if supplied certificate was valid for alternative.example.com.

Yes, this is an error in the example text.  Thanks for the close reading!
This should be easy to fix.