[TLS] Robert Wilton's No Objection on draft-ietf-tls-subcerts-14: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-tls-subcerts-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ -- COMMENT: -- Hi, Thanks for this document. I found section 5.1 on Clock Skew interesting and good to raise, but it was slightly unclear to me on several regards: 1) This text only writes about client clock skew. Isn't it also possible that a poorly maintained server might also suffer clock skew and a client using a delegated-certificate could be similarly affected? 2) It was a bit unclear to me what "The lifetime of the delegated credential should be set taking clock skew into account." was intending. Initially I had read this wondering if the peer should try and calculate the clock skew of the peer and allocate a certificate accordingly. But I presume that the actual intent is that when certificates are generated, the start time should probably be a few minutes in the past, and the certificate expiry should not be set to be exactly 7 days into the future, but perhaps a few minutes less to account for potential skew between clocks? I will leave it to the authors discretion to decide if they want to tighten or clarify this text at all. Regards, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Fwd: New BOF request revision uploaded: bofreq-moskowitz-scvp-validation-request-tls-extension-00
I have submitted the BOF request. The ADs and this workgroup will decide how they want to handle getting this work adopted. Bob Forwarded Message Subject: New BOF request revision uploaded: bofreq-moskowitz-scvp-validation-request-tls-extension-00 Date: Fri, 27 May 2022 05:40:58 -0700 From: IETF Secretariat To: The IAB , The IESG , r...@labs.htt-consult.com Robert Moskowitz has uploaded bofreq-moskowitz-scvp-validation-request-tls-extension-00 See https://datatracker.ietf.org/doc/bofreq-moskowitz-scvp-validation-request-tls-extension/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] SCHC for DTLS
Is there any activity to define SCHC rules for DTLS? I want this for Unmanned Aircraft (UA) Network Remote ID (Net-RID) communications from the UA to the Net-RID Service Provider (SP). See https://datatracker.ietf.org/doc/draft-moskowitz-drip-secure-nrid-c2/ I am compressing ESP traffic using rfc 8750 and: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/ SCHC is negotiated in IKE (and will be in HIP) and SA tables allow the ESP receiver to recognize a SCHC compressed ESP Header and act properly. It is not so simple with DTLS. First UDP is below DTLS, so how do you compress it? The way I see it, SCHC would need to be assigned an IP Protocol type so that the transport processing can start right up with the SCHC rule for UDP and then on to DTLS and then the cipher. Or at least how I see the challenge. So I am looking for any extant work on SCHC for DTLS and/or interest in this activity. The CoAP SCHC work, rfc 8824, dodge DTLS compression. Or that is how I read it. Thanks Bob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] SCHC for DTLS
On Fri, May 27, 2022 at 6:27 AM Robert Moskowitz wrote: > Is there any activity to define SCHC rules for DTLS? > Not to my knowledge. -Ekr > > I want this for Unmanned Aircraft (UA) Network Remote ID (Net-RID) > communications from the UA to the Net-RID Service Provider (SP). > > See > > https://datatracker.ietf.org/doc/draft-moskowitz-drip-secure-nrid-c2/ > > I am compressing ESP traffic using rfc 8750 and: > > https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/ > > SCHC is negotiated in IKE (and will be in HIP) and SA tables allow the > ESP receiver to recognize a SCHC compressed ESP Header and act properly. > > It is not so simple with DTLS. First UDP is below DTLS, so how do you > compress it? The way I see it, SCHC would need to be assigned an IP > Protocol type so that the transport processing can start right up with > the SCHC rule for UDP and then on to DTLS and then the cipher. > > Or at least how I see the challenge. > > So I am looking for any extant work on SCHC for DTLS and/or interest in > this activity. > > The CoAP SCHC work, rfc 8824, dodge DTLS compression. Or that is how I > read it. > > Thanks > > Bob > > ___ > 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
Re: [TLS] Martin Duke's No Objection on draft-ietf-tls-subcerts-14: (with COMMENT)
> On May 23, 2022, at 12:33, Martin Duke via Datatracker > wrote: > > Martin Duke has entered the following ballot position for > draft-ietf-tls-subcerts-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ > > > > -- > COMMENT: > -- > > A question to remedy by ignorance of ASN.1: > > How customary is it for the final standard to use an ASN.1 codepoint from > Cloudflare's private namespace? In other contexts I would expect change > control > to lie with a more public institution. > > Put another way, what would happen if Cloudflare were purchased by EvilCorp > one > day? I believe the WG did discuss switching the OID to the PKIX arc, but an OID is like you age - it’s just a number. Once assigned, nobody can really take it back. As far as common, it happens - I am hesitant to say all the time, but it is not uncommon. There are OIDs for modules, extensions, and algorithms out of company arcs and gov’t arcs. E.g., Digest algorithms: SHA*-> Gov’t x25519, x448, Ed25519, Ed448 (RFC 8410) -> Thwate arc. TAMP (RFC 5934) -> Gov’t Arc. I am sure there are more. spt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Martin Duke's No Objection on draft-ietf-tls-subcerts-14: (with COMMENT)
Sounds good to me, thanks! On Fri, May 27, 2022 at 9:22 AM Sean Turner wrote: > > > > On May 23, 2022, at 12:33, Martin Duke via Datatracker > wrote: > > > > Martin Duke has entered the following ballot position for > > draft-ietf-tls-subcerts-14: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > > for more information about how to handle DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ > > > > > > > > -- > > COMMENT: > > -- > > > > A question to remedy by ignorance of ASN.1: > > > > How customary is it for the final standard to use an ASN.1 codepoint from > > Cloudflare's private namespace? In other contexts I would expect change > control > > to lie with a more public institution. > > > > Put another way, what would happen if Cloudflare were purchased by > EvilCorp one > > day? > > I believe the WG did discuss switching the OID to the PKIX arc, but an OID > is like you age - it’s just a number. Once assigned, nobody can really take > it back. As far as common, it happens - I am hesitant to say all the time, > but it is not uncommon. There are OIDs for modules, extensions, and > algorithms out of company arcs and gov’t arcs. E.g., > > Digest algorithms: SHA*-> Gov’t > x25519, x448, Ed25519, Ed448 (RFC 8410) -> Thwate arc. > TAMP (RFC 5934) -> Gov’t Arc. > > I am sure there are more. > > spt > > > > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
