Re: Request for Authenticated but not Encrypted Traffic

[Michael Tuexen <[e-mail]>]

> On 3. Oct 2022, at 23:59, Martin Duke <[e-mail]> 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.
Using SCTP-AUTH you can choose which part of the protocol data you want to
be authenticated.

Best regards
Michael
> 
> (Which is not to say that the suggestions to making QUIC work in this use case are unworkable)
> 
> On Mon, Oct 3, 2022 at 11:38 AM Lucas Pardue <[e-mail]> wrote:
> Hi Phillip,
> 
> On Mon, 3 Oct 2022, 19:13 Phillip Hallam-Baker, <[e-mail]> 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 <[e-mail]> wrote:
> Hi Behcet,
> 
> 
> On Mon, Oct 3, 2022 at 5:56 PM Behcet Sarikaya <[e-mail]> 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
> 
>