Re: Request for Authenticated but not Encrypted Traffic

[Behcet Sarikaya <[e-mail]>]

Hi Martin,

On Mon, Oct 3, 2022 at 4:59 PM 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.
>
>
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.

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