Subject: [Captive-portals] Magnus Westerlund's Discuss on draft-ietf-capport-api-07: (with DISCUSS)

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Thu, 11 Jun 2020 06:38:40 -0700

Magnus Westerlund has entered the following ballot position for
draft-ietf-capport-api-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-capport-api/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 4.1:

   The API server endpoint MUST be accessed using HTTP over TLS (HTTPS)
   and SHOULD be served on port 443 [RFC2818].

I have another reason than Roman to discuss this particular sentence.

First of all what is the intention of which HTTP version should be supported
here? And which protocol are the port 443 you are recommending, TCP, UDP or
SCTP? This also relates to HTTP/3 as it is getting close to being published, we
can expect that in the future maybe people would like to upgrade to HTTP/3.
Already now I am wondering if the written allow for HTTP/2 over TLS/TCP? Note,
that I am mostly commenting from the perspective if you want to be specific
that it is HTTP/1.1. over TLS/TCP that is the goal. Then this document should
make certain changes in the formulation. If you want to be unspecific and don't
think that will hurt interoperability, then another formulation that the
current is also needed. Likely also a discussion about how a client will figure
out what versions are supported.

And maybe one of the ART ADs can help untangle if RFC 2818 really is the right
normative reference here? Or if it should be RFC 7230 and possibly additional
references for HTTP/2?

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 11 Jun 2020 10:12:03 -0700

> On Jun 11, 2020, at 6:38 AM, Magnus Westerlund via Datatracker <[email-masked]> wrote:
> 

This is an interesting point. In my interpretation, this text does apply to HTTP/1.1 over TLS/TCP,
HTTP/2 over TLS/TCP, and HTTP/3 over QUIC (which uses TLS for encryption, still uses port 443,
and still maintains the URI scheme of https://).

> normative reference here? Or if it should be RFC 7230 and possibly additional

Looking at RFCs like the one for DoH, https://www.rfc-editor.org/rfc/rfc8484.html <https://www.rfc-editor.org/rfc/rfc8484.html>, RFC 2818 is still
the reference for https:

over HTTP
   [RFC7540] using https [RFC2818] URIs (and therefore TLS [RFC8446]
   security for integrity and confidentiality).

My suggestion is that we can reword the sentence in question here to:

  The API server endpoint MUST be accessed over HTTP using an https URI [RFC2818],
  and SHOULD be served on port 443.

Does that work for everyone?

Thanks,
Tommy

> 
> 
> 
> 
> 
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals

---

From: Barry Leiba <[email-masked]>
Date: Thu, 11 Jun 2020 16:00:15 -0400

Your suggested rewording works for me, modulo one question:
Might it be better to say, "SHOULD use the default https port", rather
than giving the port number here?  Or perhaps, if you really want to
say "443", make it, "SHOULD use the default https port, 443."

Barry

On Thu, Jun 11, 2020 at 1:12 PM Tommy Pauly
<tpauly=[email-masked]> wrote:
> Looking at RFCs like the one for DoH, https://www.rfc-editor.org/rfc/rfc8484.html, RFC 2818 is still
> the reference for https:
>
> over HTTP

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 12 Jun 2020 13:55:48 +1000

Just jumping in here, apologies if I don't have all context:

> On 11 Jun 2020, at 11:38 pm, Magnus Westerlund via Datatracker <[email-masked]> wrote:
> 

It's generally bad practice for an API to specify a version of HTTP.

> current is also needed.

I think what's desired is to say that the URL accessed must have a HTTPS scheme and a default port, not that communication happen over any specific wire format.

> Likely also a discussion about how a client will figure

Why would it be different than any other use of HTTP?

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 12 Jun 2020 14:43:19 +0000

Hi,

I fully understand the simplicity from one perspective to not define the
version of HTTP. And I think the proposed language was an improvement. Using
default port I think has an advantage due to the multi transport protocol
nature we have here. 

On the question about versions I think it has likely interesting
implications for CAPPORT implementations. I expect that servers will
actually be deployed and potentially not be upgraded after having been
installed in a network over significant times in some cases. This will force
the clients to actually support the full set of HTTP protocols to support to
ensure interoperability over many networks. I guess this is similar for
other deployments of HTTP beyond the web. 

Cheers

Magnus Westerlund

> -----Original Message-----
> From: Mark Nottingham <[email-masked]>
> Sent: den 12 juni 2020 05:56
> To: Magnus Westerlund <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; captive-
> [email-masked]; Martin Thomson <[email-masked]>; draft-ietf-
> [email-masked]
> Subject: Re: [Captive-portals] Magnus Westerlund's Discuss on draft-ietf-
> capport-api-07: (with DISCUSS)
> 
> > First of all what is the intention of which HTTP version should be
> > supported here? And which protocol are the port 443 you are
> > recommending, TCP, UDP or SCTP? This also relates to HTTP/3 as it is
> > getting close to being published, we can expect that in the future maybe
> people would like to upgrade to HTTP/3.
> 
> > Already now I am wondering if the written allow for HTTP/2 over
> > TLS/TCP? Note, that I am mostly commenting from the perspective if you
> > want to be specific that it is HTTP/1.1. over TLS/TCP that is the
> > goal. Then this document should make certain changes in the
> > formulation. If you want to be unspecific and don't think that will
> > hurt interoperability, then another formulation that the current is also
> needed.
> 
> I think what's desired is to say that the URL accessed must have a HTTPS
> scheme and a default port, not that communication happen over any specific
> wire format.
> 
> > Likely also a discussion about how a client will figure out what
> > versions are supported.
> 
> Mark Nottingham   https://protect2.fireeye.com/v1/url?k=3a8ff1cb-
> 642f338e-3a8fb150-86b568293eb5-26a118f7c2d94334&q=1&e=d25e7a4c-
> f7e3-4e34-a054-2498def27e05&u=https%3A%2F%2Fwww.mnot.net%2F

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 15 Jun 2020 09:15:09 -0700

Thanks all for the input. The text in our working copy now reads:

The API server endpoint MUST be accessed over HTTP using an https URI {{!RFC2818}}, and SHOULD use the default https port.

(https://capport-wg.github.io/api/draft-ietf-capport-api.html#name-api-connection-details <https://capport-wg.github.io/api/draft-ietf-capport-api.html#name-api-connection-details>)

> On Jun 12, 2020, at 7:43 AM, Magnus Westerlund <magnus.westerlund=[email-masked]> wrote:
> 
> Hi,
> 

As a client implementer, I think this is both entirely standard and entirely necessary. Any device that is currently interacting with a user-facing captive portal needs to support generic browser-style webpages, which means that support for older versions HTTP for compatibility reasons is a necessity. I agree with Mark that the text here shouldn’t specify anything about the wire format version, since it has no requirements on capabilities specific to HTTP/2, HTTP/3, etc.

Best,
Tommy
>> From: Mark Nottingham <[email-masked] <mailto:[email-masked]>>
>> To: Magnus Westerlund <[email-masked] <mailto:[email-masked]>>
>> Cc: The IESG <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; captive-
>> [email-masked] <mailto:[email-masked]>; Martin Thomson <[email-masked] <mailto:[email-masked]>>; draft-ietf-
>> [email-masked] <mailto:[email-masked]>
>> Mark Nottingham   https://protect2.fireeye.com/v1/url?k=3a8ff1cb- <https://protect2.fireeye.com/v1/url?k=3a8ff1cb->
>> f7e3-4e34-a054-2498def27e05&u=https%3A%2F%2Fwww.mnot.net <http://2fwww.mnot.net/>%2F
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/captive-portals <https://www.ietf.org/mailman/listinfo/captive-portals>

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 18 Jun 2020 20:12:15 -0700

Hi Magnus,

I’ve published the proposed text in the -08 version of the draft: 

https://datatracker.ietf.org/doc/html/draft-ietf-capport-api <https://datatracker.ietf.org/doc/html/draft-ietf-capport-api>

Please take a look, and update your evaluation if it looks good!

Best,
Tommy

> On Jun 15, 2020, at 9:15 AM, Tommy Pauly <tpauly=[email-masked]> wrote:
> 
>> On Jun 12, 2020, at 7:43 AM, Magnus Westerlund <magnus.westerlund=[email-masked] <mailto:magnus.westerlund=[email-masked]>> wrote:
>> 
>> Hi,
>> 
>>>> On 11 Jun 2020, at 11:38 pm, Magnus Westerlund via Datatracker
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>