[OPSAWG]Secdir last call review of draft-ietf-opsawg-tacacs-tls13-10
Reviewer: Russ Housley Review result: Not Ready I reviewed this document as part of the Security Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area Directors. Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Document: draft-ietf-opsawg-tacacs-tls13-10 Reviewer: Russ Housley Review Date: 2024-07-01 IETF LC End Date: Unknown IESG Telechat date: Unknown Summary: Not Ready Major Concerns: Section 3.2.2 says: "Certificate based mutual authentication MUST be supported." I assume that this means that it MUST be supported, but I does not have to be used. However, the next sentence seems to require certificates, Section 3.2.2: With the removal of the reference to [RFC8773], how is the requirement for certificates accomplished while also using external PSKs? I am unaware of any other way to do so. Section 3.2.2 says: "...[RFC7250] must be used in context of [RFC8446]". How is the requirement for certificates accomplished with raw public keys? I am unaware of any way to do so. Minor Concerns: None Nits: None ___ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
Re: [OPSAWG] Secdir early review of draft-ietf-opsawg-tacacs-tls13-07
Doug: > Many thanks for the review, Russ! > > Please see below the initial changes based upon your comments, hopefully they > have met the intent. Please advise if the updates are not addressing what you > had in mind, or for any concerns. > > Best Regards, > > The Authors. > > > From: Russ Housley via Datatracker <mailto:nore...@ietf.org>> > Date: Thursday, 25 April 2024 at 20:32 > To: sec...@ietf.org <mailto:sec...@ietf.org> <mailto:sec...@ietf.org>> > Cc: draft-ietf-opsawg-tacacs-tls13@ietf.org > <mailto:draft-ietf-opsawg-tacacs-tls13@ietf.org> > <mailto:draft-ietf-opsawg-tacacs-tls13@ietf.org>>, opsawg@ietf.org > <mailto:opsawg@ietf.org> mailto:opsawg@ietf.org>> > Subject: Secdir early review of draft-ietf-opsawg-tacacs-tls13-07 > > Reviewer: Russ Housley > Review result: Not Ready > > I reviewed this document as part of the Security Directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the Security Area > Directors. Document authors, document editors, and WG chairs should > treat these comments just like any other IETF Last Call comments. > > Document: draft-ietf-opsawg-tacacs-tls13-07 > Reviewer: Russ Housley > Review Date: 2024-04-25 > IETF LC End Date: Unknown > IESG Telechat date: Unknown > > Summary: Has Issues > > > Major Concerns: > > Section 3.2.2 says: > >Implementations MUST support certificate-based TLS authentication and >certificate revocation bi-directionally for authentication, identity >verification and policy purposes. Certificate path verification as >described in Section 3.2.2.1 MUST be supported. > > I do not understand this paragraph. I suggest that you handle four > topics in separate sentences: > >(1) certificate for the server (for server authentication), >(2) revocation checking of the server certificate by the client, >(3) certificate for the client (for client authentication), >(4) revocation checking of the client certificate by the server. > > The “Policy” purposes is probably over-prescriptive, as > implementations are clearly free to apply policy to any attributes such as > identity and other cert attributes that that bubble up from the transport as > they see fit and so I’ll remove that. > > Otherwise, the intent is that: > > “Certificate based mutual TLS authentication MUST be supported by > implementations along with the provisions of revocation and path verification > from [RFC5280] as described in 3.2.2.1.” > > Does that make sufficient sense? We do have a canonical version: > > “ Certificate based mutual authentication MUST be supported. > >Clients MUST support certificate-based TLS authentication of the Peer > Server. Clients MUST support certificate revocation. > >Servers MUST support certificate-based TLS authentication of the Peer > Client. Servers MUST support certificate revocation. > >Certificate path verification as described in Section 3.2.2.1 MUST be > supported.” > > If this structure is still preferred, or more info is really required, please > advise. > To be a little less verbose, I suggest: ~~~ Certificate based mutual authentication MUST be supported. Each peer MUST validate the certificate path of the remote peer, including revocation checking, as described in Section 3.2.2.1. ~~~ > Section 3.2.2 says: "Pre-Shared Keys (PSKs) [RFC4279] ...". RFC 4279 is > not appropriate for use with TLS 1.3, so it should not be cited here. > > Agreed: Removed that citation. > Thanks. > Section 5.1.2 says: "... servers MAY abruptly disconnect clients that > do." I think this ought to make a stronger recommendation about 0-RTT. > Other profiles for the use of TLS with specific protocols (like > draft-ietf-netconf-over-tls13) completely forbid 0-RTT. > > > > Agreed: changed to MUST. > Thanks. > Section 5.1.4 talks about loading certificate chains. It might also > talk about loading the information needed to perform revocation checks > or the use of OCSP stapling. > > Agreed. We have removed the part about loading the certs from 5.1.4 > into 3.2.2.1, which is now augmented with extra requirements for revocation, > hopefully this should cover: > > “Other approaches may be used for loading the intermediate certificates onto > the client, but MUST include support for revocation. > > For example, details the AIA (Authority Information > Access) extension to access information about the issuer of the certificate > in which the extensi
[OPSAWG] Secdir early review of draft-ietf-opsawg-tacacs-tls13-07
Reviewer: Russ Housley Review result: Not Ready I reviewed this document as part of the Security Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area Directors. Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Document: draft-ietf-opsawg-tacacs-tls13-07 Reviewer: Russ Housley Review Date: 2024-04-25 IETF LC End Date: Unknown IESG Telechat date: Unknown Summary: Has Issues Major Concerns: Section 3.2.2 says: Implementations MUST support certificate-based TLS authentication and certificate revocation bi-directionally for authentication, identity verification and policy purposes. Certificate path verification as described in Section 3.2.2.1 MUST be supported. I do not understand this paragraph. I suggest that you handle four topics in separate sentences: (1) certificate for the server (for server authentication), (2) revocation checking of the server certificate by the client, (3) certificate for the client (for client authentication), (4) revocation checking of the client certificate by the server. Section 3.2.2 says: "Pre-Shared Keys (PSKs) [RFC4279] ...". RFC 4279 is not appropriate for use with TLS 1.3, so it should not be cited here. Section 5.1.2 says: "... servers MAY abruptly disconnect clients that do." I think this ought to make a stronger recommendation about 0-RTT. Other profiles for the use of TLS with specific protocols (like draft-ietf-netconf-over-tls13) completely forbid 0-RTT. Section 5.1.4 talks about loading certificate chains. It might also talk about loading the information needed to perform revocation checks or the use of OCSP stapling. Section 5.1.4 says: "Certificate fingerprints are another option." More explanation or a reference is needed here, Minor Concerns: The draft uses RFC 2119 terms, but it lacks a reference to RFC 2119 and the usual RFC 2119 boilerplate. Nits: Section 3: Please add a reference for FIPS 140. Section 3.2.2.1: s/Certificate Authority (CA)/Certification Authority (CA)/ Section 3.3: s/Certificate Provisioning/Certificate provisioning/ Section 5.1.3: s/abandoned/abandoned./ Section 5.1.4: s/Certificate Authority (CA)/Certification Authority (CA)/ IDnits complaints about: == The 'Updates: ' line in the draft header should list only the numbers of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-opsawg-9092-update-10: (with DISCUSS and COMMENT)
Randy: The consumer of geofeed data SHOULD fetch and process the data themselves. Importing datasets produced and/or processed by a third- party places significant trust in the third-party. >>> >>> this is in sec cons already. you want it moved up or duplicated? i >>> kinda like it where it is, but am flexible. >> >> I was not suggesting a new placement, just the edit to the last line. > > sorry. sure. > >> I propose adding that to the bottom of the paragraph that starts: >> >> If and only if the geofeed file is not signed per Section 5, ... >> >> By doing that, it does not conflict with the requirement in Section 5 >> that the address range of the signing certificate cover all prefixes >> in the signed geofeed file. > > When reading data from an unsigned geofeed file, one MUST ignore data > outside the referring inetnum: object's address range. This is to > avoid importing data about ranges not under the control of the > operator. Note that signed files MUST only contain prefixes within > the referring inetnum:'s range as mandated in Section 5. Fine with me. Russ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-opsawg-9092-update-10: (with DISCUSS and COMMENT)
Randy: >> >> Suggested edits: >> >> The address range of the signing certificate MUST cover all prefixes >> in the signed geofeed file. If not, the authenticator is invalid. >> >> The signing certificate MUST NOT include the Autonomous System >> Identifier Delegation certificate extension [RFC3779]. If it is >> present, the authenticator is invalid. >> >> As with many other RPKI signed objects, the IP Address Delegation >> certificate extension MUST NOT use the "inherit" capability defined >> in Section 2.2.3.5 of [RFC3779]. If "inherit" is used, the >> authenticator is invalid. > > sure > >> The consumer of geofeed data SHOULD fetch and process the data >> themselves. Importing datasets produced and/or processed by a third- >> party places significant trust in the third-party. > > this is in sec cons already. you want it moved up or duplicated? i > kinda like it where it is, but am flexible. I was not suggesting a new placement, just the edit to the last line. >> I think is is probably better to drop the following from Section 6: >> >> When using data from a geofeed file, one MUST ignore data outside the >> referring inetnum: object's inetnum: attribute address range. > > this is meant for an unsigned file. e.g. multiple diverse inetnum:s > refer to the single geofeed file https://rg.net/geofeed. it allows an > operator not signing to maintain one file. > > all geofeeds are not signed for a number of reasons > > o rpki data may not exist for some, cf. decades of difficulty getting >rpki allowed by all RIRs. plus, you do not really want to tie the >two operational processes together. > > o geofeed data are not critical. they just hints to geoloc obsessed >content providers I propose adding that to the bottom of the paragraph that starts: If and only if the geofeed file is not signed per Section 5, ... By doing that, it does not conflict with the requirement in Section 5 that the address range of the signing certificate cover all prefixes in the signed geofeed file. Russ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Paul Wouters' Discuss on draft-ietf-opsawg-9092-update-10: (with DISCUSS and COMMENT)
Paul: I am writing to address #3 and #4. Thanks for your careful review. > #3 Signature and white space requirements are a bit troubling > >Trailing blank lines MUST NOT appear at the end of the file. > > That's rather strong. Should the file be rejected if a blanc line appears > at the end? If not, I wonder why to even mention this, especially with 2119 > force. Based on: > >If the authenticator is not in the canonical form described above, >then, the authenticator is invalid. > > That is a "yes the file should be rejected if it has a trailing blanc line". I > think that is unwise, I would like to hear the reasoning behind this. > >When present, such end-of-file markers MUST NOT be covered by the >digital signature. > > This is going to cause problems if people make detached signatures of the > file. > What is the reason for this requirement? > > The CMS signature does not cover the signature lines. > > This gets really complicated now, when we read the above item on blanc lines. > Does this mean the blanc line MUST NOT appear before these # comments? Or not > after these comments? Or both? Can there be a blanc line between geofeed > content > and signature? How about two blanc lines? As the text says, we want canonical form to be the input to the signing process. This is unchanged from RFC 9092, which has not caused the interoperability concerns that you suggest. Also, this is the same approach that was used for digitally signing Internet-Drafts. > #4 Misc. Security comments > > The address range of the signing certificate MUST cover all >prefixes in the signed geofeed file. > > I vaguely remember huge problems with such similar requirement. The document > is > not clear what to do when this is not the case? Reject everything? Or only > accept those entries that ARE covered? More guidance is needed here. > >The signing certificate MUST NOT include the Autonomous System >Identifier Delegation certificate extension [RFC3779]. > > What must one do if this does include it? > >As with many other RPKI signed objects, the IP Address Delegation >certificate extension MUST NOT use the "inherit" capability >defined in Section 2.2.3.5 of [RFC3779]. > > What must one do if this does include it? > >The Certificate Authority (CA) SHOULD sign only one geofeed file >with each generated private key and SHOULD generate a new key >pair for each new version of a perticular geofeed file. The CA >MUST generate a new End Entity (EE) certificate for each signing >of a particular geofeed file. > > When can these SHOULDs be ignored? Eg it _is_ possible to use the same key but > a different EE cert? Also, what is the reason for needing to generate a new EE > cert per geofeed version file? What issue is solved by not allowing a long > lived > EE cert to do this job? > >When using data from a geofeed file, one MUST ignore data outside >the referring inetnum: object's inetnum: attribute address range. > > How does this "MUST ignore" combine with the above mentioned "failed > validation" ? eg here it would seem an entry to 0.0.0.0/0 must be ignored, but > earlier text said to invalidate the entire file, not just the entry. So how > would we ever get here? > >If and only if the geofeed file is not signed per Section 5, >then multiple inetnum: objects MAY refer to the same geofeed >file, and the consumer MUST use only lines in the geofeed file >where the prefix is covered by the address range of the inetnum: >object's URL it has followed. > > We normally call this a downgrade attack. Strip the signature and modify the > file? Are there any counter measures that can be used to prevent this attack? > >Importing datasets produced and/or processed by a third-party > places ill-advised trust in the third-party. > > I don't think you can call all third-parties "ill-advised" by definition. > eg is "google DNS" and ill-advised third-party for DNS ? I agree with the response that Job already offered. In short, RPKI certificates are issued to match the privileges required for the object that will verified with the public key. In this way, least privilege is always accomplished. Since Section 5 is option, authentication is optional. Thus, the Operational Considerations do include some discussion of unsigned geofeed files. Suggested edits: The address range of the signing certificate MUST cover all prefixes in the signed geofeed file. If not, the authenticator is invalid. The signing certificate MUST NOT include the Autonomous System Identifier Delegation certificate extension [RFC3779]. If it is present, the authenticator is invalid. As with many other RPKI signed objects, the IP Address Delegation certificate extension MUST NOT use the "inherit" capability defined
Re: [OPSAWG] [secdir] Secdir last call review of draft-ietf-opsawg-9092-update-09
Tim: >> (2) Section 6, paragraph 5: is this intended to be a RFC 2119 "MAY"? >> If so, capitalize. If not, avoid the word. > > took me a moment. i think it is para 6, this one, yes? > > It is good key hygiene to use a given key for only one purpose. To > dedicate a signing private key for signing a geofeed file, an RPKI > Certification Authority (CA) may issue a subordinate certificate > exclusively for the purpose shown in Appendix A. > > that 'may' should probably be 2119ed. russ, opinion? I actually think this is fine either way. In this case, the text is saying that an RPKI CA might choose to create a subordinate CA solely for issuing these certificates. Russ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Last-Call] Intdir last call review of draft-ietf-opsawg-9092-update-06
RFC 9092 includes a normative reference to RFC 8805.The shepherd writeup for draft-ietf-opsawg-finding-geofeeds (which eventually became RFC 8805) calls out this downref. The downward references were referenced in the Last Call: https://mailarchive.ietf.org/arch/search/?q=draft-ietf-opsawg-finding-geofeeds At this point, RFC 5485 and RFC 8805 should have been added to the downref registry; however I do not see either of them here https://datatracker.ietf.org/doc/downref I hope the OPS AD can correct this now. Russ > On Nov 20, 2023, at 6:36 AM, Sheng Jiang via Datatracker > wrote: > > Reviewer: Sheng Jiang > Review result: Ready with Nits > > I have reviewed this document as part of the IntArea directorate's ongoing > effort to review all IETF documents being processed by the IESG. Comments that > are not addressed in last call may be included in AD reviews during the IESG > review. Document editors and WG chairs should treat these comments just like > any other last call comments. > > Document: draft-ietf-opsawg-9092-update-06 > Reviewer: Sheng Jiang > Review Date: 2023-11-20 > Result: Ready with Nits > > This Standards Track document specifies how to augment the > Routing Policy Specification Language inetnum: class to > refer specifically to geofeed data files and describes an > optional scheme that uses the Resource Public Key > Infrastructure to authenticate the geofeed datafiles. It intends > to obsolete RFC 9092. It is well written and almost ready with > several Nits regarding to references, see beloww. > > Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) > Obsolete normative reference: RFC 6486 (Obsoleted by RFC 9286) > Downref: Normative reference to an Informational RFC: RFC 8805 ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action: draft-ietf-opsawg-9092-update-03.txt
Job: > The example signature chain still is broken :-/ Thank you for your very careful review. > 1/ The Trust Anchor cert still doesn't mark its RFC 3779 > autonomousSysNum extension as critical. RFC 6487 section 4.8.11 > requires this. I must have done something very clumsy when I composed the XML, because looking at my individual files, the extension is marked critical. $openssl x509 -in exampleta.pem -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 12:08:32:70:da:05:55:18:c0:b8:df:c5:c3:b5:11:bb:40:c4:64:d0 Signature Algorithm: sha256WithRSAEncryption Issuer: CN = example-ta Validity Not Before: Sep 19 20:33:39 2023 GMT Not After : Sep 16 20:33:39 2033 GMT Subject: CN = example-ta Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:d0:a6:b4:7e:83:f8:b8:27:23:9b:55:44:53:a7: 52:69:18:cd:b7:bc:63:f2:13:97:c3:28:53:ea:57: ba:f0:33:50:26:9b:b7:27:7b:0e:ba:53:4d:88:cd: 5d:17:e6:88:af:e6:74:86:7d:15:f9:53:1b:1b:47: eb:f0:3c:13:1c:79:0c:83:81:2e:65:7b:11:62:bf: 87:c1:fd:58:df:0d:3d:aa:5f:f5:23:b0:b2:fd:40: e7:9a:48:e8:7b:4e:82:52:2e:39:ad:a5:ad:03:f6: 2c:fb:7e:e9:77:85:dc:51:8e:93:0c:66:21:3f:ad: e5:fd:ff:29:9d:a5:6f:c4:76:0d:05:eb:e4:fd:58: 66:44:d6:68:8f:78:88:e5:e4:e6:70:9e:62:c7:09: fb:64:37:f6:9a:62:4d:62:3c:d8:cd:9e:21:d8:20: e8:c2:d6:34:a9:00:19:a8:67:24:e3:b2:0a:f0:2c: 4d:85:d5:f2:11:91:59:30:01:2a:93:a2:af:c3:e6: ff:6f:a1:76:98:61:a5:d4:34:96:f8:1f:fe:70:7a: 74:6e:bd:3e:4e:fe:7e:8f:5e:1e:f4:ac:c4:32:17: 9c:b3:2e:cf:7a:ca:dc:6a:83:98:06:5f:d9:1a:6d: 59:ef:c4:55:3c:9c:77:cf:6b:4a:e1:97:07:d3:26: 79:63 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: C0:BD:52:5D:BE:D2:78:B2:16:EC:B3:A3:43:95:D2:06:0B:99:08:32 X509v3 Authority Key Identifier: C0:BD:52:5D:BE:D2:78:B2:16:EC:B3:A3:43:95:D2:06:0B:99:08:32 X509v3 Basic Constraints: critical CA:TRUE X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Certificate Policies: critical Policy: ipAddr-asNumber Subject Information Access: RPKI Manifest - URI:rsync://rpki.example.net/repository/example-ta.mft RPKI Notify - URI:https://rrdp.example.net/notification.xml CA Repository - URI:rsync://rpki.example.net/repository/ sbgp-ipAddrBlock: critical IPv4: 0.0.0.0/0 IPv6: ::/0 sbgp-autonomousSysNum: critical Autonomous System Numbers: 0-4294967295 Signature Algorithm: sha256WithRSAEncryption Signature Value: 6b:d7:8b:63:d4:00:9a:79:59:38:8c:8e:cd:ba:6d:6b:9c:2a: 70:e5:10:57:fc:91:ee:8f:f4:d7:39:04:65:a4:9a:bc:a0:6d: d7:d9:4c:2b:a0:17:66:ea:f1:d5:3e:63:ca:32:30:1b:b6:c4: b5:96:53:86:3b:47:da:6f:34:57:99:1c:da:db:05:8d:2a:bf: ca:9e:cd:24:17:25:30:75:5d:de:d5:ec:7b:d2:1f:de:75:d8: 17:86:f1:44:87:22:af:59:57:94:06:d8:37:e1:28:d5:4d:e2: e6:a2:4e:f9:fc:68:bb:3b:7b:31:ea:e4:d8:38:a1:9e:c7:a7: 4d:e5:ca:cc:de:ed:7e:6b:82:61:96:47:08:2f:2f:88:2a:09: 59:d1:fe:a3:5b:91:33:84:e2:40:0a:59:b1:42:7c:b0:5e:13: 00:1a:eb:44:99:80:fc:47:79:bf:40:93:05:b8:2a:4f:1e:f2: 83:4f:95:6a:b1:4b:3d:d9:e3:62:0b:69:a0:22:6a:c0:4d:82: d5:4a:57:d7:9a:d9:49:a2:d5:b8:65:ed:6f:05:dd:fd:c1:c4: 83:9b:c5:5b:a4:13:b0:c7:8c:40:51:14:6b:a8:64:89:c0:c6: b7:12:d3:51:d8:5c:90:18:26:08:6a:05:da:79:59:8a:2e:5f: d4:14:d6:02 > 2/ The intermediate CA cert lists > > URI:rsync://rpki.example.net/repository/3ACE2CEF4FB21B7D11E3E184EFC1E297B3778642.crl > as its CRLDP; but instead must reference > URI:rsync://rpki.example.net/repository/example-ta.crl > The intermediate CA is subordinate to the TA, and thus should > reference the CRL signed by the TA (not the CRL it signed itself). Indeed. This is a cut-and-paste error. just corrected it. I have a long plane ride tomorrow. I'll try to correctly generate the XML on the plane. Russ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action: draft-ietf-opsawg-9092-update-02.txt
I will work on items 1-4 for the next version. Russ > On Sep 19, 2023, at 1:11 AM, Job Snijders > wrote: > > Dear authors, > > There still are a few nits with the examples in this document. > > 1/ The sbgp-autonomousSysNum extension in the Trust Anchor MUST be > marked critical (RFC 6487 section 4.8.11), it currently is not. > > 2/ The sbgp-autonomousSysNum extension in the CA cert MUST be > marked critical (RFC 6487 section 4.8.11), it currently is not. > > 3/ On the EE certificate, the basicConstraints extension MUST be absent > if the CA bit is set to false. Only CA certificates are expected to > carry a basicConstraints extension. (RFC 6487 section 4.8.1) > > 4/ the lack of CRLs in the example makes it much harder to truly verify > the provided geofeed files, please consider including the 2 missing > CRLs so a complete example is presented. > > 5/ Section 3 still lists RSC as 'complex', and RPKI-RTA as 'applicable > in the long run'; but draft-ietf-sidrops-rpki-rta-00 has long since > expired, and also marked 'replaced by RFC9232'. Can the authors > explain what kind of applicability of RTA they envision in the long > run? It's also not clear to me how the RTA 'applicability' relates to > using a self-signed trust anchor? > > Kind regards, > > Job > > On Mon, Sep 18, 2023 at 06:40:36PM -0700, internet-dra...@ietf.org wrote: >> Internet-Draft draft-ietf-opsawg-9092-update-02.txt is now available. It is a >> work item of the Operations and Management Area Working Group (OPSAWG) WG of >> the IETF. >> >> Title: Finding and Using Geofeed Data >> Authors: Randy Bush >>Massimo Candela >>Warren Kumari >>Russ Housley >> Name:draft-ietf-opsawg-9092-update-02.txt >> Pages: 26 >> Dates: 2023-09-18 >> >> Abstract: >> >> This document specifies how to augment the Routing Policy >> Specification Language inetnum: class to refer specifically to >> geofeed data files and describes an optional scheme that uses the >> Resource Public Key Infrastructure to authenticate the geofeed >> datafiles. >> >> The IETF datatracker status page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-opsawg-9092-update/ >> >> There is also an HTMLized version available at: >> https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-9092-update-02 >> >> A diff from the previous version is available at: >> https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-9092-update-02 >> >> Internet-Drafts are also available by rsync at: >> rsync.ietf.org::internet-drafts >> >> >> ___ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg > > ___ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] CALL FOR ADOPTION: draft-ymbk-opsawg-9092-update
> On Sep 15, 2023, at 1:29 PM, Randy Bush wrote: > >> 1/ the new EE certificate uses an 'inherit' element in its RFC3779 >> extension, but section 5 disallows the use of 'inherit' in EEs. > > sigh. russ? Oops. I'll dig into it. > >> 2/ given that the example EE was refreshed in -01, the example >> Base64-encoded CMS signature (page 24) also must be refreshed. > > russ? I did refresh it. Randy did you pull it from my email? Regardless, it will need refreshed again to fix the above. Russ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] POLL FOR IPR: draft-ymbk-opsawg-9092-update
No, I'm not aware of any IPR that applies to this draft Russ On Aug 7, 2023, at 9:20 AM, Joe Clarke (jclarke) wrote: > > Ahead of a call for WG adoption of draft-ymbk-opsawg-9092-update, we’d like > to poll for known IPR. > > Authors and contributors on the To: line, please respond on-list as to > whether or not you are aware of any IPR that pertains to this work. > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If you are aware of IPR, indicate whether or not this has been disclosed per > IETF IPR rules (see RFCs 3669, 5378, and 8179). > > Joe > ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Genart early review of draft-ietf-opsawg-sbom-access-03
Reviewer: Russ Housley Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-opsawg-sbom-access-03 Reviewer: Russ Housley Review Date: 2021-12-13 IETF LC End Date: unknown IESG Telechat date: unknown Summary: Almost Ready Note: I am not a good persone to review the YANG specification. I assume one of the YANG Doctors will have a look at this document too. Major Concerns: Section 1 says: To satisfy these two key use cases, objects may be found in one of three ways: This lead to some confusion for me. Earlier in the document, it says: This specification does not allow for vulnerability information to be retrieved directly from the endpoint. That's because vulnerability information changes occur at different rates to software updates. After thinking about it, I realized that the objects do not include vulnerability information, but pointers to obtain vulnerability information. Please reword to others do not need to give it the same amount of thought. Minor Concerns: Section 1, first sentence: The reference to "A number of activities" is very vague. It is not wrong. Please be more specific, provide some references, or drop the vague reference altogether. Section 1 says: In the second case, when a device does not have an appropriate retrieval interface, but one is directly available from the manufacturer, a URI to that information must be discovered. s/must/MUST/ ? Nits: The terms "software" and "firmware" are used with essentially the same meaning in this document. If there is a difference, it needs to be explained. If they are the same in the context of this document, please say so. Abstract, last sentence: please add "(MUD)" and also a pointer to RFC 8520. Section 1, first sentence: The reference to "A number of activities" is very vague. It is not wrong. Please be more specific, provide some references, or drop the vague reference altogether. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-finding-geofeeds-12: (with DISCUSS and COMMENT)
Ben:
text. Trailing space characters MUST NOT appear on a line of text.
That is, the space or tab characters must not be followed by the
sequence. [...]
Is the restriction on Unicode characters of category "space separator"
("space characters") or the two listed characters? (Why just those two,
and not form feed as well?)
>>>
>>> Looking at the ABNF in RFC 8805, It does not look like there should be
>>> any trailing whitespace, this was more for consistency with RFC 5485.
>>
>> perhaps a clearer phrasing would be
>>
>>Trailing space characters MUST NOT appear on a line of text. That
>>is, space or tab characters must not immediately preceed a
>>sequence.
>
> Hmm, so I'm supposed to read "space characters" and think "a sequence of
> one or more 0x20 bytes"? I guess I can maybe see that, but do kind of want
> an answer on whether we care about other unicode codepoints that are
> "whitespace" appearing immediately prior to . For better or for
> worse, things get complicated and messy once we go past 7-bit ASCII.
RFC 8805 says that each feed entry is a text line of the form:
ip_prefix,alpha2code,region,city,postal_code
The first three fields are ASCII. The city can be UTF-8, except comma. The
postal_code is optional and deprecated, but it can be can be UTF-9, except
comma.
By that description, trailing whitespace is allowed, but not helpful.
I guess we can drop that sentence.
Russ
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-finding-geofeeds-12: (with DISCUSS and COMMENT)
I guess the last sentence should go away too. RFC 8805 does not prohibit them, but I cannot imagine them as helpful. Russ > On May 21, 2021, at 3:39 PM, Randy Bush wrote: > > so > > The canonicalization procedure converts the data from its internal > character representation to the UTF-8 [RFC3629] character encoding, > and the sequence MUST be used to denote the end of a line of > text. A blank line is represented solely by the sequence. > Other non-printable characters, such as backspace, are not expected. > > ? ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Roman Danyliw's No Objection on draft-ietf-opsawg-finding-geofeeds-12: (with COMMENT)
Roman: Responding to just one comment. > ** Appendix A. The end-user certificate has a sbgp-ipAddBlock field which is > “IPv4: inherit IPv6: inherit”. However, the parent CA is encoding an IPv4 > only > range so it seems misplaced that there is a IPv6 reference there. > > See https://mailarchive.ietf.org/arch/msg/opsawg/zYwS9OHWhzkXrfXVUu4ZG16-2GI/ > for follow-up discussion on this. I will be glad to make this change to the example. It took some time to make the changes and edit the file. I just sent it to Randy for incorporation into the next version of the I-D. Russ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-finding-geofeeds-12: (with DISCUSS and COMMENT)
Ben: Responding to Part 1 of your DISCUSS and a few of your comments. My co-authors will address the other parts, including the NITS. > -- > DISCUSS: > -- > > Roman and Russ did the heavy lifting already, but I think I have a bit more > fiddling to do regarding the validation procedures (just getting them > internally consistent, I think)... > > (1) > Here: > > As the signer specifies the covered RPKI resources relevant to the > signature, the RPKI certificate covering the inetnum: object's > address range is included in the [RFC5652] CMS SignedData > certificates field. > > we say that the signing certificate is included in the SignedData > certificates field. That makes sense, as SignedData is a SEQUENCE > including "certificates [0] IMPLICIT CertificateSet OPTIONAL", and > CertificateSet, as a SET OF CertificateChoices, allows for the literal > "Certificate" branch of CertificateChoices. > > But later on, we say that: > > 1. Obtain the signer's certificate from an RPKI Repository. The > certificate SubjectKeyIdentifier extension [RFC5280] MUST match > the SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier > [RFC5286]. If the key identifiers do not match, then validation > MUST fail. > > which entails fetching the certificate from a directory, based on the > SubjectKeyIdentifier. > > Why do we need to obtain the certificate twice in two different ways? Thanks for catching this error that I introduced yesterday. Here is a correction. OLD: 1. Obtain the signer's certificate from an RPKI Repository. The certificate SubjectKeyIdentifier extension [RFC5280] MUST match the SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier [RFC5286]. If the key identifiers do not match, then validation MUST fail. NEW: 1. Obtain the signer's certificate from the CMS SignedData CertificateSet [RFC5652]. The certificate SubjectKeyIdentifier extension [RFC5280] MUST match the SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier [RFC5652]. If the key identifiers do not match, then validation MUST fail. [snip] > -- > COMMENT: > -- [snip] > > Section 3 > > The URL's use of the web PKI can not provide authentication of IP > address space ownership. It is only used to authenticate a pointer > to the geofeed file, [...] > > I'm a little confused by the use of the phrase "authenticate a pointer > to the geofeed file". My understanding is that the "pointer to the > geofeed file" is the URL itself, i.e., it is a pointer from the RPSL > stanza to the geofeed file, and that dereferencing the URL retrieves the > geofeed file itself (i.e., not a pointer). In particular, the URL (and > any Web PKI usage therein) does not do anything to authenticate the RPLS > stanza in which the URL appears. IIUC, it would be okay to just drop > that bit and say "It is only used to authenticate the domain name in the > URL, and provide confidentiality and integrity for the geofeed file in > transit". Am I missing something? I think it would be more accurate to say that the WebPKI provides authentication and integrity of the geofeed file that is fetched. However, as I said in response to Roman's ballot comments, the ultimate integrity check is the signature that is validated with the RPKI certificate. [snip] > Section 4 > > address range. One needs a format that bundles the relevant RPKI > certificate with the signature and the digest of the geofeed text. > > If the signature is distributed alongside the file being signed, why is > it necessary to bundle the digest of the file being signed with the > signature? This just invites security-relevant implementation bugs > where the validator just accepts the precomputed digest and does not > validate that the contents of the geofeed file actually have that > digest. This comes from the fact that CMS does carry the message digest in a signed attribute, but this is probably too much detail at this point in the discussion. OLD: One needs a format that bundles the relevant RPKI certificate with the signature and the digest of the geofeed text. NEW: One needs a format that bundles the relevant RPKI certificate with the signature of the geofeed text. > (There is, however, value in the CMS SignedData including the digest > *algorithms* used in signatures. I don't know if that was the intent > here.) Yes, CMS carries the digest algorithm identifier. We can be more explicit. OLD: Borrowing detached signatures from [RFC5485], after file canonicalization, the Cryptographic Message Syntax (CMS) [RFC5652] would be used to create a detached DER encoded
Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-finding-geofeeds-10: (with DISCUSS and COMMENT)
Thanks Roman. Two follow-up comments in line. Russ > On May 19, 2021, at 5:59 PM, Roman Danyliw wrote: > > Hi Russ! > > Inline ... > >> -Original Message----- >> From: Russ Housley >> Sent: Wednesday, May 19, 2021 11:27 AM >> To: Roman Danyliw >> Cc: IESG ; draft-ietf-opsawg-finding-geofe...@ietf.org; >> opsawg-cha...@ietf.org; Ops Area WG ; George Michaelson >> >> Subject: Re: Roman Danyliw's Discuss on draft-ietf-opsawg-finding-geofeeds- >> 10: (with DISCUSS and COMMENT) >> >> Roman: >> >> Addressing some of your comments below. I'm leaving others to my co- >> authors. >> >>> -- >>> DISCUSS: >>> -- >>> >>> The validation process for the signature computed in Section 4 seems >>> underspecified. >>> >>> For example, let’s consider the example in Appendix A. Through a whois >> query >>> for 192.0.2.0 one finds a “remarks:Geofeed ” field which >>> leads to a geofeed file which had the detached CMS signature blob “# >>> RPKI >>> Signature: 192.0.2.0/24” depicted at the end of Appendix A. What >>> reference or text guides how to validate that signature in the RPKI >>> (akin to the level of detail in Section 3.3 of RFC7909 or RFC6125)? >>> >>> I’m inferring that the steps would roughly be: >>> >>> ** Download the end-entity certificate identified by the >>> subjectKeyIdentifier field via the pointer/URI in the >>> “subjectInfoAccess” field extracted from the CMS signature blob >>> >>> ** Download the intermediate certificate identified by the >>> authorityKeyIdentifier field via the pointer/URI in the “caIssuer” >>> field extracted from the CMS signature blob >>> >>> ** Based on the RIR identified in the whois query, download the RPKI >>> trust anchor of the RIR >>> >>> ** Validate the certificate chain from the RPKI trust anchor down to >>> the end-entity certificate. Check that all of the basicConstraints, >>> certificatePolicies, etc. are accurate. Check the CRL. >>> >>> ** Verify that the end-entity certificate contains the IP address of >>> interest >>> (192.0.2.0) in the sbgp-ipAddrBlock field >>> >>> ** Validate the signature using the algorithm identified in the CMS >>> signature blog using the end-entity certificate >>> >>> Is that the process? Is that stated somewhere in the document or >>> available via reference? >> >> I suggest the following changes in Section 4: >> >> OLD: >> >> Validation of the signing certificate needs to ensure that it is part >> of the current manifest and that the resources are covered by the >> RPKI certificate. >> >> As the signer specifies the covered RPKI resources relevant to the >> signature, the RPKI certificate covering the inetnum: object's >> address range is included in the [RFC5652] CMS SignedData >> certificates field. >> >> Identifying the private key associated with the certificate, and >> getting the department with the Hardware Security Module (HSM) to >> sign the CMS blob is left as an exercise for the implementor. On the >> other hand, verifying the signature requires no complexity; the >> certificate, which can be validated in the public RPKI, has the >> needed public key. >> >> NEW: >> >> As the signer specifies the covered RPKI resources relevant to the >> signature, the RPKI certificate covering the inetnum: object's >> address range is included in the [RFC5652] CMS SignedData >> certificates field. >> >> Identifying the private key associated with the certificate, and >> getting the department with the Hardware Security Module (HSM) to >> sign the CMS blob is left as an exercise for the implementor. On the >> other hand, verifying the signature requires no complexity; the >> certificate, which can be validated in the public RPKI, has the >> needed public key. >> >> The trust anchors for the RIRs are expected to already be available >> to the party performing signature validation. Validation of the CMS >> signature on the geofeed file involves: >> >> 1. Obtain the signer's certificate from an RPKI Repository. The >> certificate >> SubjectKeyIdentifier extension [RFC5280] MUST ma
Re: [OPSAWG] Roman Danyliw's Discuss on draft-ietf-opsawg-finding-geofeeds-10: (with DISCUSS and COMMENT)
Roman: Addressing some of your comments below. I'm leaving others to my co-authors. > -- > DISCUSS: > -- > > The validation process for the signature computed in Section 4 seems > underspecified. > > For example, let’s consider the example in Appendix A. Through a whois query > for 192.0.2.0 one finds a “remarks:Geofeed ” field which > leads to a geofeed file which had the detached CMS signature blob “# RPKI > Signature: 192.0.2.0/24” depicted at the end of Appendix A. What reference or > text guides how to validate that signature in the RPKI (akin to the level of > detail in Section 3.3 of RFC7909 or RFC6125)? > > I’m inferring that the steps would roughly be: > > ** Download the end-entity certificate identified by the subjectKeyIdentifier > field via the pointer/URI in the “subjectInfoAccess” field extracted from the > CMS signature blob > > ** Download the intermediate certificate identified by the > authorityKeyIdentifier field via the pointer/URI in the “caIssuer” field > extracted from the CMS signature blob > > ** Based on the RIR identified in the whois query, download the RPKI trust > anchor of the RIR > > ** Validate the certificate chain from the RPKI trust anchor down to the > end-entity certificate. Check that all of the basicConstraints, > certificatePolicies, etc. are accurate. Check the CRL. > > ** Verify that the end-entity certificate contains the IP address of interest > (192.0.2.0) in the sbgp-ipAddrBlock field > > ** Validate the signature using the algorithm identified in the CMS signature > blog using the end-entity certificate > > Is that the process? Is that stated somewhere in the document or available > via > reference? I suggest the following changes in Section 4: OLD: Validation of the signing certificate needs to ensure that it is part of the current manifest and that the resources are covered by the RPKI certificate. As the signer specifies the covered RPKI resources relevant to the signature, the RPKI certificate covering the inetnum: object's address range is included in the [RFC5652] CMS SignedData certificates field. Identifying the private key associated with the certificate, and getting the department with the Hardware Security Module (HSM) to sign the CMS blob is left as an exercise for the implementor. On the other hand, verifying the signature requires no complexity; the certificate, which can be validated in the public RPKI, has the needed public key. NEW: As the signer specifies the covered RPKI resources relevant to the signature, the RPKI certificate covering the inetnum: object's address range is included in the [RFC5652] CMS SignedData certificates field. Identifying the private key associated with the certificate, and getting the department with the Hardware Security Module (HSM) to sign the CMS blob is left as an exercise for the implementor. On the other hand, verifying the signature requires no complexity; the certificate, which can be validated in the public RPKI, has the needed public key. The trust anchors for the RIRs are expected to already be available to the party performing signature validation. Validation of the CMS signature on the geofeed file involves: 1. Obtain the signer's certificate from an RPKI Repository. The certificate SubjectKeyIdentifier extension [RFC5280] MUST match the SubjectKeyIdentifier in the CMS SignerInfo SignerIdentifier [RFC5652]. If the key identifiers do not match, then validation MUST fail. 2. Construct the certification path for the signer's certificate. All of the needed certificates are expected to be readily available in the RPKI Repository. The certification path MUST be valid according to the validation algorithm in [RFC5280] and the additional checks specified in [RFC3779] associated with the IP Address Delegation certificate extension and the Autonomous System Identifier Delegation certificate extension. If certification path validation is unsuccessful, then validation MUST fail. 3. Validate the CMS SignedData as specified in [RFC5652] using the public key from the validated signer's certificate. If the signature validation is unsuccessful, then validation MUST fail. 4. Verify that the IP Address Delegation certificate extension [RFC3779] covers the address range of the geofeed file. If the address range is not covered, then validation MUST fail. If all of these steps MUST be successful to consider the geofeed file signature as valid. > > > -- > COMMENT: > -- > > Thank you to Kyle Rose for the
Re: [OPSAWG] [Last-Call] [secdir] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06
> On May 3, 2021, at 11:44 AM, Kyle Rose wrote: > > On Mon, May 3, 2021, 11:28 AM Russ Housley <mailto:hous...@vigilsec.com>> wrote: >> This is not quite right. It is true that theWebPKI provide authentication >> and integrity when https:// is used, but this is not required. If http:// >> were used, and the file was modified in transit by an attacker, the RPKI >> signature check would fail. >> >> Yes. Which is why I'm suggesting that you mandate https. > > I do not have a problem mandating the use of https:// for authentication and > integrity protection of the file. I think that is shown in the examples. I > am saying that doing so does not "chain" the trust models. > > Explain how an attacker could get a client to accept a forged geofeed data > file authenticated as I have suggested, because I'm not seeing it. We are not understanding each other. The RPKI signature will prevent the relying party from accepting a modified file, regardless of the means used to fetch it. For this reason, there is no need think about the interaction of the RPKI and the WebPKI. No dependency is being created. Russ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Last-Call] [secdir] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06
> On May 3, 2021, at 10:47 AM, Kyle Rose wrote: > > On Mon, May 3, 2021 at 10:40 AM Russ Housley <mailto:hous...@vigilsec.com>> wrote: > >> Understood. I'm not suggesting the web PKI be used to authenticate IP >> address space ownership. I'm suggesting that the following chain would be >> sufficient: >> >> * RPKI authenticates the routing information, which includes the IP address >> space and the https URLs for each geofeed file. >> * Web PKI authenticates the data served at that URL. >> * Client verifies that the IP ranges in the geofeed data are contained >> within the (RPKI-authenticated) routing information. > > This is not quite right. It is true that theWebPKI provide authentication > and integrity when https:// is used, but this is not required. If http:// > were used, and the file was modified in transit by an attacker, the RPKI > signature check would fail. > > Yes. Which is why I'm suggesting that you mandate https. I do not have a problem mandating the use of https:// for authentication and integrity protection of the file. I think that is shown in the examples. I am saying that doing so does not "chain" the trust models. Russ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [secdir] [Last-Call] Secdir last call review of draft-ietf-opsawg-finding-geofeeds-06
Kyle: > > This document appears to propose overlapping mechanisms for > > establishment of trust in geofeed data. As far as I can tell, geofeed > > data may be authenticated both by: > > > > * RPKI private key signature of a digest of a canonicalized form of the > > geofeed data file. * Web PKI via https URL for geofeed data file. > > not exactly. > > the web pki has no authority over IP address space ownership. > > Understood. I'm not suggesting the web PKI be used to authenticate IP address > space ownership. I'm suggesting that the following chain would be sufficient: > > * RPKI authenticates the routing information, which includes the IP address > space and the https URLs for each geofeed file. > * Web PKI authenticates the data served at that URL. > * Client verifies that the IP ranges in the geofeed data are contained > within the (RPKI-authenticated) routing information. This is not quite right. It is true that theWebPKI provide authentication and integrity when https:// is used, but this is not required. If http:// were used, and the file was modified in transit by an attacker, the RPKI signature check would fail. > I.e., you are chaining trust from the RPKI explicitly to the (https) URL, and > implicitly to the data served from that URL. The web PKI is used only to > ensure that the data is not modified in transit. It is not used to authorize > IP address space ownership: regardless of the PKI used to authenticate the > geofeed data, the client still needs to cross-check the IP ranges in the > geofeed data against the ownership in the RPKI-authenticated routing > information. My point is that there is no chaining of trust. Russ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] AD review of draft-ietf-opsawg-finding-geofeeds-04
Rob: >> >> Unless is modified to formally define > [RW] > > My comment was less about what gets written in the documents, and more about > how this update would actually be done in practice. E.g., updating 8805 to > indicate a new section would presumably break any existing clients expecting > to fetch a regular CSV file via the "geofeed: or "remaks: geofeed" attributes? > > I.e., it seems that either 8805 would have to be updated in backwards > compatible way, and it looks like adding such an appendix wouldn't be > backwards compatible (c.f., RFC 8805 section 7), or all clients would have to > be updated before the publishing format is changed, or it would need new > geofeed attribute names to publish the different versions of the geofeed data > at the same time. > > How wedded are you to that text? Perhaps it would be simpler to just delete > the "Until [RFC8805] is updated to formally define such an appendix" text and > just say that the signature is always predicated by '#' comments? The whole reason that the signature is put in comments is so that they can be ignored by clients that only understand RFC 8805. > One point of clarification is that 8805 was published as Informational on the > RSE, but I'm not sure that really matters. I think the there just needs to be a downref called out in the IETF Last Call. Russ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] AD review of draft-ietf-opsawg-finding-geofeeds-04
> On Apr 12, 2021, at 7:33 PM, Randy Bush wrote: > 3. The definition of canonicalization refers to section 2.2 of RFC 5485 (which talks about ASCII) vs RFC8805 which talks about UTF-8. Is this disparity an issue? >>> >>> russ, how do you want to handle? >> >> This is really about line endings, but it would probably be best to >> assign a content type for UTF8 Test with CRLF. > > yuchh. send text, if you would please. Actually, I went back to the I-D, and I withdraw my suggestions. This I-D already defines a new content type: id-ct-geofeedCSVwithCRLF. This new content type already handles the situation as I was thinking. It could be more clear, and I suggest: OLD: Borrowing detached signatures from [RFC5485], after text file canonicalization (Sec 2.2), the Cryptographic Message Syntax (CMS) [RFC5652] would be used to create a detached DER encoded signature which is then BASE64 encoded and line wrapped to 72 or fewer characters. NEW: The canonicalization procedure converts the data from its internal character representation to the UTF-8 [RFC3629] character encoding, and the sequence MUST be used to denote the end of a line of text. Trailing space characters MUST NOT appear on a line of text. That is, the space or tab characters must not be followed by the sequence. Thus, a blank line is represented solely by the sequence. Other nonprintable characters, such as backspace, are not expected. For robustness, any nonprintable characters MUST NOT be changed by canonicalization. Trailing blank lines MUST NOT appear at the end of the file. That is, the file must not end with multiple consecutive sequences. Any end-of-file marker used by an operating system is not considered to be part of the file content. When present, such end-of-file markers MUST NOT be processed by the digital signature algorithm. Borrowing detached signatures from [RFC5485], after file canonicalization, the Cryptographic Message Syntax (CMS) [RFC5652] would be used to create a detached DER encoded signature which is then BASE64 encoded and line wrapped to 72 or fewer characters. END Russ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] AD review of draft-ietf-opsawg-finding-geofeeds-04
Responding to just two places where Randy handed off to me ... >> 3. The definition of canonicalization refers to section 2.2 of RFC >> 5485 (which talks about ASCII) vs RFC8805 which talks about UTF-8. Is >> this disparity an issue? > > russ, how do you want to handle? This is really about line endings, but it would probably be best to assign a content type for UTF8 Test with CRLF. > This document also suggests optional data for geofeed files to >> provide stronger authenticity to the data. >> >> Would "optional signature data" be clearer than just "optional data"? > > ok. russ? maybe 'authenticating'? How about: ... optional signature, which authenticates the data when present. Russ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] IPR CALL: draft-ietf-opsawg-finding-geofeeds
I do not know about any IPR associated with thie Internet-Draft. Russ > Authors, contributors, and WG members, as we are in WGLC for this > document, we want to solicit knowledge of any IPR that may pertain to > the draft-ietf-opsawg-finding-geofeeds work. > > Please state either, "no, I am not aware of any IPR that applies to this > draft" or, "yes, I am aware of IPR that applies this draft". > > If there is IPR, it must be disclosed in compliance with IETF IPR rules > (i.e., RFCs 3669, 5378, and 8179). Please indicate if this has been done. > > If you have any additional details, please share those as well. > > If you are an author or contributor, you must reply to indicate IPR status. > > Joe ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [Suit] draft-moran-suit-mud, EAT and MUD
I think that the best way forward is to ask SECDISPATCH. I do not think SUIT
is a bad answer, but we have a process to pick.
Russ
> On Jun 14, 2020, at 5:23 PM, Michael Richardson wrote:
>
> Hi, I read draft-moran-suit-mud today.
> It would naturally fall into a MUD WG if we had that.
> As it is, I have no idea where to discuss this, and thus another shotgun.
> I gather the mailman deletes my Reply-To suggestions.
>
> I feel that this document should be adopted and the details filed in, but I
> have no idea what WG it belongs in given the current state of things.
> {It totally fits into the IoT lifecycle security WG I had proposed}
>
> I knew it was around since it was talked about at the Hackathon a bunch, but
> I hadn't read the result until today.
>
> If you use Hypothesis my comments are at:
>
> https://hyp.is/go?url=https%3A%2F%2Ftools.ietf.org%2Fid%2Fdraft-moran-suit-mud-00.html=__world__
> I'm not sure what that does if you don't have the plugin installed.
> I'd prefer to write them as a pull request since they are mostly suggestions
> on fixing some wording rather than any kind of substantive request for
> changes.
>
> Substantive comments:
> "At the time of onboarding, devices report their manifest in use to the MUD
> manager."
>
> so I think that we will need to detail this!!!
> When using an IDevID based onboarding system (BRSKI/BRSKI-TEEP/BRSKI-AE or
> EAP-NOOB with some certificate based system) then the MUD certificate OID is
> available.
> But, that's not the manifest of the software currently running, and it would
> not be reasonable to embed that into the IDevID for the reasons I explain at:
>
> https://datatracker.ietf.org/doc/html/draft-richardson-opsawg-mud-acceptable-urls-00#section-2
>
> More interesting is that you are requesting:
> Each time a device is updated, rebooted, or otherwise substantially
> changed, it will execute an attestation.
> Among other claims in the Entity Attestation Token (EAT)
> [I-D.ietf-rats-eat], the device will report its software digest(s),
> configuration digest(s), primary manifest URI, and primary manifest
> digest to the MUD manager.
>
> Well, that attestation is actually ideal for use during onboarding as well.
>
> It seems to me that the path of trust should go like:
>
> 1) (Manufacturer IDevID PKI) -> IDevID.
> 2) IDevID -> "generic" MUD file (signed by key from Manufacturer PKI <%>)
> 3) MUD file -> identifies key that signs firmware manifests
> 4) SUIT MANIFEST -> "specific" (per version) MUD file
>
> I had previous suggested that the SBOM be attached to the per-version MUD
> file, but I am not so sure anymore.
>
> Note that the EAT described above would be *Evidence* (not Attestation
> Results), per the architecture. It would be signed by the IDevID in <2>.
>
> Finally, if you didn't see my message to secdispatch about IDevID.
>
> https://mailarchive.ietf.org/arch/msg/secdispatch/Hqe1lHG2wnW_9NxJLazEYbmGYN0/
>
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
signature.asc
Description: Message signed with OpenPGP
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
