Re: [TLS] Application-Layer Protocol Settings
On Mon, Jul 20, 2020 at 10:42 PM David Benjamin wrote: > On Mon, Jul 20, 2020 at 5:00 PM Lucas Pardue > wrote: > >> >> That makes sense but I guess I don't see the point in defining a new >> thing that contains frames that are never sent on streams. That is, if >> these are connection settings, just send the payload. Unframed extended >> settings might get you there, if you can find a way to encapsulate >> conventional settings inside them, then all the better. >> > > Could you elaborate on this a bit? I'm probably just failing to parse, but > I'm not sure which alternative you're suggesting here. (Ah, the wonders of > email.) > > David > I was trying to accommodate HTTP/2 and HTTP/3 in one breath, which is why my intent was probably unclear. Basically, if ALPS relies on frames for per-protocol settings then it has to accommodate the differences in frame format between HTTP/2 and HTTP/3. In the examples from the ALPS and Client Reliability proposals, the H2 frame needs to populate the frame header and it pick stream 0, which doesn't exist until the connection is actually made, so seems a bit kludgy. In H3, frames don't have the stream ID so you avoid the problem above. So my thought was to basically do away with the notion of protocol-specific frames in ALPS, and instead define the a common payload format that perhaps looks something like bishop-extended-settings [1], a series of Type-Length-Value (but without any frame headers). This would allow you to encode the old and new settings in a single format, rather than needing to delineate things via frames. [1] - https://tools.ietf.org/html/draft-bishop-httpbis-extended-settings-01#section-3.1.1 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Application-Layer Protocol Settings
On Tue, Jul 21, 2020 at 8:22 AM Lucas Pardue wrote: > > On Mon, Jul 20, 2020 at 10:42 PM David Benjamin > wrote: > >> On Mon, Jul 20, 2020 at 5:00 PM Lucas Pardue >> wrote: >> >>> >>> That makes sense but I guess I don't see the point in defining a new >>> thing that contains frames that are never sent on streams. That is, if >>> these are connection settings, just send the payload. Unframed extended >>> settings might get you there, if you can find a way to encapsulate >>> conventional settings inside them, then all the better. >>> >> >> Could you elaborate on this a bit? I'm probably just failing to parse, >> but I'm not sure which alternative you're suggesting here. (Ah, the wonders >> of email.) >> >> David >> > > I was trying to accommodate HTTP/2 and HTTP/3 in one breath, which is why > my intent was probably unclear. Basically, if ALPS relies on frames for > per-protocol settings then it has to accommodate the differences in frame > format between HTTP/2 and HTTP/3. In the examples from the ALPS and Client > Reliability proposals, the H2 frame needs to populate the frame header and > it pick stream 0, which doesn't exist until the connection is actually > made, so seems a bit kludgy. In H3, frames don't have the stream ID so you > avoid the problem above. > > So my thought was to basically do away with the notion of > protocol-specific frames in ALPS, and instead define the a common payload > format that perhaps looks something like bishop-extended-settings [1], a > series of Type-Length-Value (but without any frame headers). This would > allow you to encode the old and new settings in a single format, rather > than needing to delineate things via frames. > > [1] - > https://tools.ietf.org/html/draft-bishop-httpbis-extended-settings-01#section-3.1.1 > Ah, gotcha. The thinking was the settings were ALPN-specific anyway, so we may as well define them however is more idiomatic for the protocol. This means we automatically can make existing H2 and H3 settings more reliable. Settings values can also be updated over the course of the connection, so using frames keeps continuity there. But, yeah, a separate key/value syntax would work too. (A small correction, the current Client Hint Reliability proposal allows ACCEPT_CH to be sent in application data too. Maybe the frontend realizes the origin's ACCEPT_CH preferences have changed and wants to notify existing connections. Though I don't consider this feature important. I doubt most folks, if anyone, will bother with this. Mostly that's how a SETTINGS or EXTENDED_SETTINGS value already would have worked, so I figured the semantics ought to be compatible in case EXTENDED_SETTINGS is revived.) David ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Application-Layer Protocol Settings
I guess you could have protocol-specific numbers and protocol-independent syntax? Or you could allocate numbers in yet another number space for all the existing settings. The latter seems like a lot of fuss, and the former is kinda weird. At that point you may as well get a protocol-specific blob (as in the draft) so the protocol library can reuse their preferred parsing routines. On Tue, Jul 21, 2020 at 4:22 PM Victor Vasiliev wrote: > How would this work with regular SETTINGS? HTTP/2 and HTTP/3 have > disjoint setting number spaces, and it's unclear to me whether there's any > significant overlap between those. > > On Tue, Jul 21, 2020 at 11:49 AM David Benjamin > wrote: > >> On Tue, Jul 21, 2020 at 8:22 AM Lucas Pardue >> wrote: >> >>> >>> On Mon, Jul 20, 2020 at 10:42 PM David Benjamin >>> wrote: >>> On Mon, Jul 20, 2020 at 5:00 PM Lucas Pardue < lucaspardue..2...@gmail.com > wrote: > > That makes sense but I guess I don't see the point in defining a new > thing that contains frames that are never sent on streams. That is, if > these are connection settings, just send the payload. Unframed extended > settings might get you there, if you can find a way to encapsulate > conventional settings inside them, then all the better. > Could you elaborate on this a bit? I'm probably just failing to parse, but I'm not sure which alternative you're suggesting here. (Ah, the wonders of email.) David >>> >>> I was trying to accommodate HTTP/2 and HTTP/3 in one breath, which is >>> why my intent was probably unclear. Basically, if ALPS relies on frames for >>> per-protocol settings then it has to accommodate the differences in frame >>> format between HTTP/2 and HTTP/3. In the examples from the ALPS and Client >>> Reliability proposals, the H2 frame needs to populate the frame header and >>> it pick stream 0, which doesn't exist until the connection is actually >>> made, so seems a bit kludgy. In H3, frames don't have the stream ID so you >>> avoid the problem above. >>> >>> So my thought was to basically do away with the notion of >>> protocol-specific frames in ALPS, and instead define the a common payload >>> format that perhaps looks something like bishop-extended-settings [1], a >>> series of Type-Length-Value (but without any frame headers). This would >>> allow you to encode the old and new settings in a single format, rather >>> than needing to delineate things via frames. >>> >>> [1] - >>> https://tools.ietf.org/html/draft-bishop-httpbis-extended-settings-01#section-3.1.1 >>> >> >> Ah, gotcha. The thinking was the settings were ALPN-specific anyway, so >> we may as well define them however is more idiomatic for the protocol. This >> means we automatically can make existing H2 and H3 settings more reliable. >> Settings values can also be updated over the course of the connection, so >> using frames keeps continuity there. But, yeah, a separate key/value syntax >> would work too. >> >> (A small correction, the current Client Hint Reliability proposal allows >> ACCEPT_CH to be sent in application data too. Maybe the frontend realizes >> the origin's ACCEPT_CH preferences have changed and wants to notify >> existing connections. Though I don't consider this feature important. I >> doubt most folks, if anyone, will bother with this. Mostly that's how a >> SETTINGS or EXTENDED_SETTINGS value already would have worked, so I figured >> the semantics ought to be compatible in case EXTENDED_SETTINGS is revived.) >> >> David >> > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Application-Layer Protocol Settings
As I understood things in ALPS, each application protocol has its own settings so I don't see there being too much problem with the disjoint number spaces. It is a bit fussy but it avoids having to rework existing stacks to parse frames that don't belong to any streams. From the stacks that I'm experienced with, frame parsing and stream state are wrapped tightly. Unless you mean that you expect an endpoint to use parsing primitives to parse a frame, which seems like it would duplicate things. Instead just having unframed settings that carry properties of a yet-to-be-fully-instantiated endpoint connection seems something to have less impact. But of course YMMV. Cheers Lucas ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05
Hi, It's now six and a bit months later. It's true those have been very distracting months for us all but when are we hoping to progress this draft? S On 12/05/2020 10:59, Stephen Farrell wrote: > > Hi, > > It's now four and a bit months later. It's true those have > been very distracting months for us all but when are we > hoping to progress this draft? > > Thanks, > S. > > On 06/01/2020 15:16, Stephen Farrell wrote: >> >> Hi all, >> >> I've just submitted -06 that (I think/hope:-) addresses >> the issues in Ben's preliminary AD review. >> >> So the ball's back in Ben's court until he finds more >> stuff that needs fixing or starts IETF LC:-) >> >> Cheers, >> S. >> >> >> ___ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> >> ___ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] draft-ietf-tls-dtls-connection-id-07 / IANA connection_id
Dear list, are there any news about the draft-ietf-tls-dtls-connection-id and the IANA registration of the connection_id? According https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id the draft expired on April 23, 2020 and according https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml the assigned value expired on 2020-07-02. I still very interested in this extension, it makes coap over dtls 1.2 a very powerful technology for the cloud and NB IoT. Currently two pending threats are discussed, see the PRs in https://github.com/tlswg/dtls-conn-id . One of both is in my opinion a general one using UDP, several countermeasures are discussed, including RRC. Let me add, that in my opinion, it's also about to chose cid for the right use-case, and not generally. That would mostly eliminated the DDoS threat, if the use-case doesn't offer an amplification. The other one requires in my opinion a remark about not using the option of RFC 6347 to generate an alert on invalid MACs, if the cid is used. Potentially, if of any interest at all, an additional remark about AES-CBC, the CID length and "lucky 13" maybe added, though the cid changes the 13. For me this looks much more, that the authors are too busy with other work and not that this draft doesn't make sense anymore. Therefore I would appreciate, if the temporary IANA registration for the connection_id could be extended by an additional year. Best regards Achim Kraus ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
