Re: Request for Authenticated but not Encrypted Traffic

[Martin Duke <[e-mail]>]

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.

(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
>>>
>>>
>>>
>>