RE: draft-montenegro-httpbis-h2ot-00 question

[Gabriel Montenegro <[e-mail]>]

> This is an interesting piece.  I certainly hope that this is being
> discussed in other venues than just the HTTP working group, in a sense
> it's less valuable for us than others.

Thanks!

Not currently being discussed elsewhere, although we've thought about a couple of groups. Any suggestions? 

The main ideas to encourage HTTP/2 for IoT were presented and discussed a couple of IETF’s ago at a CoRE WG meeting. Even though there were some favorable responses, this group isn’t really chartered to go work on HTTP/2, as they’re very CoAP-centric. The bigger picture is that we should explore a common stack across IoT and other scenarios, so we should not need new WG’s to deal with IoT issues. IoT is the norm and we should get used to it in every working group.

> On the profile section, are there particular aspects to h2 that are
> not particularly well-suited to implementation in constrained devices?
>  Is there anything that implementing h2 has suggested (that maybe
> hasn't already been suggested to this working group?

The focus of the draft is currently on exploring how to use current HTTP/2 for IoT now within the confines of the defined protocol. This is the subject of the profile and implementation sections in the draft. 

One unresolved issue is called out in the security considerations section: one of *the* IoT ciphersuites (TLS_PSK_WITH_AES_128_CCM_8) is disallowed explicitly by HTTP/2:

   Given the security challenges in IoT scenarios, HTTP/2 is assumed to
   use TLS services.  In Internet scenarios, [RFC7540] has clear
   guidance in this respect.  In Constrained network scenarios, the
   guidance for IoT is [I-D.ietf-dice-profile].  However, these are
   currently at odds.  For example, Section 4.2 of
   [I-D.ietf-dice-profile] mandates the ciphersuite
   TLS_PSK_WITH_AES_128_CCM_8 for preshared key-based authentication
   (quite common in IoT deployments).  On the other hand, Appendix A of
   [RFC7540] includes TLS_PSK_WITH_AES_128_CCM_8 in the HTTP/2 Black
   List of disallowed cipher suites, despite it being an AEAD
   ciphersuite.  This is still to be resolved.  The other IoT
   ciphersuite mandated by [I-D.ietf-dice-profile], namely,
   TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (used for both certificate-based
   and Raw Public Key-based authentication) is not on the HTTP/2 Black
   List.

Or is the intent of your question asking what changes in HTTP/2 would make it more amenable to IoT?  One aspect that could reap benefits would be if binary headers came back into the picture. Also, whereas there is plenty of room to negotiate parameters, it would also help if there were some way for both sides to agree on a given profile without incurring in any negotiation. The draft hints that in practice, prior knowledge can be used to this effect. You might recall that we proposed profile negotiation in ALPN a long time ago (which is where the “h2” and “h2c” tokens actually originated, where h2c meant the “constrained” profile). But this didn’t progress, partly because ALPN tokens lead to explosion. At any rate, prior knowledge has been used in massive scale already to bypass ALPN altogether (Twitter). Whereas the draft doesn’t advocate this, it hints that prior knowledge could be used to bypass parameter negotiation. 

But this is a good question. In part, the purpose of issuing this draft is to ask people to think about this question.

Robby may have further thoughts about this...

Thanks,

Gabriel