SIDROps Meeting Notes 107 - chair slides - randy/panel slides - opinions are important(ush) discussion of CRL changes russ - know that a CRL must be created (because CPS) to keep the ability to remove resources from use prior to expiry. warren - perhaps not equal to the root-dns management, change rates are different in bgp/dns. steve kent - Software should be ther to make the manifest prior to publication, something like RP software but with better error/etc for the CA/PubPoint about inconsistencies prior to updating published content. randy - ideally the verisign/etc folk have solid provisions for this. russ - there are 2 tests, ICANN and Verisign, actually. tests, ideally change with lessons learned. randy - there appear to be authors missing for the proposed document updates which must be made (rfc6486 - bis section-6) steve - (see last part of randy comment) Section 6 was rough on the original authors... much vaccilating due to concerns with ops/etc. Time to refresh this, with a new view on ops work and WG discussions. See ML discussion with proposed text from ML. randy - still need to find authors and use resources (steve/russ/) to review and provide updates to said text. steve - some choices were made about DoS issues and less (probably) focus there should be made. Ideally review George Michaelson's text on list about effects of missing content in a repository. job - updating an RFC could take ~2yrs, what can we do in the meantime to get guidance to the validator folk before then? randy - use consensus from WG, to push software changes. steve - perhaps the new section6 changes can move the operator/software forward? while the doc revision is pushed up ietf poles. first goal, get more agreement on section6/etc first. tim - pushing for rrdp over rsync, which SHOULD help move atomic changes this will help. george - if focused on section6, 6.5 is the most important/problem. There's only 1 normative word(SHOULD)... need more focus and harder language here. Put forth a tabular dos/donts steve - yes 6.5 is clearly in need of more hard words. warnings are not super helpful (says list traffic) for Tim, perhaps rrdp isn't 100%? is rsync REALLY the problem? guidance in the doc is to make the PubPoint an atomic change. possibly the RP software COULD help here, but not sure. russ - with more rigor on the pipeline of publication data we'd have made the rsync process work 'better'... regardless rrdp may still be nice :) randy - rob - can review docs, can not write so much, lack fo time. rrdp may make sense because there's only the manifest to guide download. the rsync problems are tied to the FileSystem, this causes continual problems. randy - now to CRLs - come from PKix history, well defined and understood removal of CRLs george - recognize distinction between positive and negative statements. all crypto is 'positive' not 'negative'. This means you can't say negative things. CRLs are only a negative thing: "Do not accept objs in this list" randy - 1) are crls undefined 2) should be removed russ - perhaps add to 8211 paragraph that discussion consequences about supressing a CRL. we learned more recently. tim - crl noise can deal with inconsistencies due to race conditions based on crl + manifest + ... circular dependencies on crl/manifest. (does the manifest get invalidated by the crl? is the crl in the manifest?) there's usecase still for CRL. With most of section6 dealt with then CRLs are more reasonable. steve - re 8211 changes... will issue errata for russ's changes. russ - possibly a 1para update. job - local poiicy point(s) - in last weeks with deployments, the local policy changes are being made with SLURM. Local validation changes may obviate local policy requirements on routing policy? steve - agree with job jay - see jabber - 'interesting that a manifest can be revoked in a crl' steve/rob - yes that's where it works tim - does this make sense? :) russ - yea.. no, yea... we should try not to do this, but it is possible, because they are cert objects. rob - please dont' re-write x509, but provide guidance that doing this is a 'bad plan'. rudiger - we can make additional constraints, right? enforcing that via consistency checks (steve) could make sense. tim - checking consistency is important, on publication server. check deltas/manifests/etc. - Randy slides - ROV Timing discussion historical pains (routing updates, dns updates, etc) lessons learned, we should learn them. Let's make the timing better and or more predictable. topology/etc discussion for path of CA/ROA/etc content -> rp -> rooter protocols used and timing of each protocol step discussed. (see slides for details) - Tim slides - Deprecate RSYNC! All Hail RRDP! not a WG doc yet, asking for that on list next. remove rsync because ... Why? see slides (server pains, implemtation problems, etc) RRDP should scale far better with CDN help/etc, much better libraries, deltas Today we have rsync, so graceful change is required Phase 0 - (today) rsync mandatory, rrdp optional Phase 1 - both protos MUST be supported (verification required) Phase 2 - RP protocols change to MUST RRDP, MUST NOT use rsync (measure) Phase 3 - Repositories MUST support RRDP, MAY RSYNC. possible to use this for data mining, not HA service. (see matrix, very useful) Adoption call coming shortly George - do we want formalizing in fetch uri's in asn.1? this seems unnecessary, fyi... DNS says perhaps ordering matters though. Rob - there is no list, there is no spoon. different oids. Nathalie - if you leave optional rsync.. we will be stuck forever. add phase4 where 'kill it with fire'. Tim - not against removal, but seems useful for other things (data science!) Rudiger - be cautious about the overlap time, as incosnistencies in the dual paths will cause confusion. The 'data science' part seems nice though. Possible not rysnc, but an API to review content in the same manner? Tim - rsync seems convenient still. With the rrdp urls... - ASCones - Max Stoochi Is not a sidrops draft, just re-picked up work, however. there's similar work here so chatting here now. New author! (melichor) Looking at security model now to revise that. Usage models for making prefix-lists Security documentation - ascone addition to new ascone... must required handshake. Adding an ASN to the cone is optionally approved ACKs are registered in the as-cone, as a bool. Review of 4 models of prefix filter creation (see slides) Want to integrate with ASPA if possible. consider that these 2 things are closely aligned/similar. Do we want both? - azimov - ques: 'inheritance between cones?' (customer -> cust -> cust) what should happen if the 2nd customer has no verification? the inclusion of as-set/as-cones there's very confusing/mesh as you get nearer to the edge... - max - if the stub is a stub.. won't the people just behave though? - azimov - RP is customer-cone, and not provider... this seems tenuous. - steve - back to slide 4 'validated' - asserted by publisher, RPs must trust this assertion. This is concerning... without verification by the RP this seems problematic. - max - the validation is in the DB, not by the AS-cone owner. - steve - this is still problematic (observation) - job - last-slide - integrating the two - as-cones is good thought exp... aspa - is an attempt to automate 'peer lock'. these two things are pretty different for filter creation. these may not combine well, keep them separate. - george - as-cones / roas discussion(s). The roa is signed not by an ASN but by a resource holder. "Who signs the objects?" - rudiger - security model looks dubious to rudiger. George's remark on signing relationship is at least documented oddly/wrongly. as-cones are policy statements, and should be signed by the ASN... the validated parts are interesting to the security model. This could make a good meeting point for ascone/aspa... - randy - as-set addict... deconstruct the approval path as it relates to removal of ASN from as-cones? - max - this is worked out in the new draft version. - randy - when removed you must be able to show that the previous version is invaild. - max - re-read the latest draft, this is covered we believe. - ASPA Update - Alexander Azimov Slides review Data/Comparisons on Yandex network, showing how ASPA functions Need for per-family ASPA today. Note the usage of internal tooling to verify external leakings - rudiger - question on asn.1 change: "Why sequence and not set?" - azimov - sure! - russ - no way hoza! (sets required to be sorted in DER) - job - wglc - perhaps pump the brakes because of manifest/crl changes in flight. - azimov - perhaps another verification would be nice too :) will send note when appropriate. - randy - crl/manifest is orthogonal - perhaps ... focus on aspa? - yunan - ptp peers are covered? how? will take to the list for question discussion. - doug - with partial, how do you detect lateral leaks? - azimov - possible to detect, looking to the future with as-empty/etc.