Hi Behcet, On Wed, Oct 5, 2022 at 4:00 PM Behcet Sarikaya <[email protected]> wrote:
> Hi Martin, > > On Mon, Oct 3, 2022 at 4:59 PM Martin Duke <[email protected]> > wrote: > >> I'm late to this discussion, but if the need is a protocol that delivers >> streams without encryption, SCTP (or SCTP over UDP) is a reasonably >> well-vetted choice that would appear to meet the requirements. It >> certainly sounds superior to asking people to invent a new protocol. >> >> > Exactly. The requirement to have the payload encrypted seems to be the > reason why Quic was connected to HTTP over TLS. > I am not sure for IoT such a requirement could be defended in every use > case. > RFC 7258 / BCP 188 [1] was published in 2014. It describes how " Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible." QUIC provides a secure transport protocol that is consistent with BCP 188. Some approaches proposed in this thread, where explicit trusted parties can participate, are also consistent. Other suggestions would seem not to mitigate pervasive monitoring attacks. I'm not sure why people are so insistent to link QUIC to HTTP(S). HTTP and TLS are independent protocols. TLS provides a protected bytestream that can be used by many types of application protocols. QUIC uses parts of TLS as a security component [2], such as ClientHello messages, but details are different. For instance, QUIC protects individual packets rather than providing a TLS record layer. QUIC provides a multiplexed bytestream abstraction for application protocols to use. The datagram extension provides an unreliable message abstraction. Many types of application can leverage these abstractions. People are doing this and those design have nothing to do with HTTP. QUIC does not provide, nor enforce, anything to do with HTTP semantics [3] or HTTP syntax(wire format). Cheers Lucas [1] https://www.rfc-editor.org/rfc/rfc7258 [2] https://www.rfc-editor.org/rfc/rfc9001 [3] https://www.rfc-editor.org/rfc/rfc9110 > (Which is not to say that the suggestions to making QUIC work in this use >> case are unworkable) >> >> > +1 > > Behcet > >> On Mon, Oct 3, 2022 at 11:38 AM Lucas Pardue <[email protected]> >> wrote: >> >>> Hi Phillip, >>> >>> On Mon, 3 Oct 2022, 19:13 Phillip Hallam-Baker, <[email protected]> >>> wrote: >>> >>>> I think we have to actually build a prototype of a transactional-first >>>> transport, then build some applications over it and only then look to see >>>> whether/how we might re-use QUIC. >>>> >>>> That is how I originally worked on HTTP, I build applications using >>>> HTTP as a transport, one of which was the first Webmail service, those >>>> allowed me to discover the need for content length and start working on >>>> connection keepalive and framing. >>>> >>>> And we need to build any such system around the capabilities of modern >>>> programming languages which support threads and asynchronous methods. >>>> Otherwise we just end up trapped in subordination type interactions and >>>> don't progress beyond RPC. >>>> >>>> What I am saying is, let me build something, then take a look at it and >>>> tell me if/how to build it using QUIC. >>>> >>> >>> In case I was unclear, I think building something and revisitng later >>> sounds like a good approach. Look forward to seeing your progress >>> >>> In the meantime, and tangentially, I think its important to we provide a >>> consistent reminder that QUIC is very unopinionted about the applications >>> on top. This has been the case for years. I suspect many application >>> protocols that already exist would straightforwardly map to QUIC. We have >>> RFCs that do this, many I-Ds either individual or adopted by WGs, and I'm >>> aware of many protocol mappings that are defined outside the IETF - either >>> openly documented or private. >>> >>> Should future evolution of QUIC provide opportunity for alternative >>> (re)mappings that people think would be useful, that is entirely possible >>> and supported. Extension like that should probably also add a section that >>> extends the applicability document to aid designers and implementers. >>> >>> Cheers >>> Lucas >>> >>> >>> >>>> >>>> On Mon, Oct 3, 2022 at 1:19 PM Lucas Pardue <[email protected]> >>>> wrote: >>>> >>>>> Hi Behcet, >>>>> >>>>> >>>>> On Mon, Oct 3, 2022 at 5:56 PM Behcet Sarikaya <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Christian, >>>>>> >>>>>> I quickly glanced through RFC 9250 which defines DoQ and references >>>>>> ALPN in RFC 7301. >>>>>> Agree with Philip that DoQ does not define something that is >>>>>> independent of HTTP. >>>>>> >>>>>> Will it come one day, we don't know? >>>>>> Behcet >>>>>> >>>>> >>>>> DoQ is an application mapping over QUIC. ALPN is an extension to TLS. >>>>> DoQ might use a transactional model that maps to bidirectional streams but >>>>> that is the full extent of similarities to HTTP; there is no normative >>>>> dependency. >>>>> >>>>> RFC 9000 was written carefully to describe the interface that >>>>> application-data-bearing streams can provide to applications. This is not >>>>> related to HTTP, QUIC is independent of HTTP. Indeed, QUIC on its own >>>>> means >>>>> pretty much nothing. It needs an application mapping protocol. The >>>>> recently-published applicability draft, RFC 9308 [1], is specifically >>>>> written to aid designers or implementers of such mappings. Randy might >>>>> find >>>>> RFC 9308 informative if wishing to pursue QUIC as a transport substrate >>>>> for >>>>> the OT application layer traffic. >>>>> >>>>> Cheers >>>>> Lucas >>>>> >>>>> [1] - https://www.rfc-editor.org/rfc/rfc9308.html >>>>> >>>>> >>>>> >>>>
