[{"author": "Brad Gorman", "text": "send one over to the Austrian lounge as VIE
", "time": "2022-03-25T11:30:08Z"}, {"author": "Keyur Patel", "text": "Hi Folks :)
", "time": "2022-03-25T11:30:58Z"}, {"author": "Randy Bush", "text": "warren's mic volume is low
", "time": "2022-03-25T11:31:10Z"}, {"author": "Nathalie Trenaman", "text": "Meetecho crew, can you up the mic on the chairs table?
", "time": "2022-03-25T11:32:49Z"}, {"author": "John Scudder", "text": "In-room chairs may need to eat the mic
", "time": "2022-03-25T11:32:51Z"}, {"author": "John Scudder", "text": "yes it does
", "time": "2022-03-25T11:33:09Z"}, {"author": "Meetecho", "text": "That mic was causing feedback in the previous session, so we had to lower the gain
", "time": "2022-03-25T11:33:29Z"}, {"author": "Warren Kumari", "text": "Thanks
", "time": "2022-03-25T11:33:35Z"}, {"author": "Meetecho", "text": "Speaking closer to the mic should help
", "time": "2022-03-25T11:33:39Z"}, {"author": "Jeffrey Haas", "text": "https://en.wikipedia.org/wiki/Missing_stair
", "time": "2022-03-25T11:35:48Z"}, {"author": "Nathalie Trenaman", "text": "how is the volume now?
", "time": "2022-03-25T11:39:49Z"}, {"author": "Jeffrey Haas", "text": "There's a difference between \"this is a idea that has many issues\" and \"this is stupid\"
", "time": "2022-03-25T11:39:50Z"}, {"author": "Jeffrey Haas", "text": "@nathalie a little low, but better.
", "time": "2022-03-25T11:40:03Z"}, {"author": "Nathalie Trenaman", "text": "the face masks don't help...
", "time": "2022-03-25T11:40:20Z"}, {"author": "Keyur Patel", "text": "very well said Lars!
", "time": "2022-03-25T11:40:33Z"}, {"author": "Maarten Aertsen", "text": "thanks Allison
", "time": "2022-03-25T11:40:39Z"}, {"author": "Rob Austein", "text": "There's a Greg Brown song, \"On records, the sound just fades away\". That would be Warren.
", "time": "2022-03-25T11:44:47Z"}, {"author": "Meetecho", "text": "Slides imported
", "time": "2022-03-25T11:45:00Z"}, {"author": "Chris Morrow", "text": "thanks!
", "time": "2022-03-25T11:45:14Z"}, {"author": "Warren Kumari", "text": "The sides were loaded in the tool, but then my brower decided to restart, apologies all for looking like we've never seen a computer before...
", "time": "2022-03-25T11:46:26Z"}, {"author": "Nathalie Trenaman", "text": "If anyone wants to help me with the notes, they are here:
", "time": "2022-03-25T11:46:52Z"}, {"author": "Nathalie Trenaman", "text": "https://notes.ietf.org/notes-ietf-113-sidrops?edit
", "time": "2022-03-25T11:46:54Z"}, {"author": "Warren Kumari", "text": "I would appreciate someone helping me understand the relationship between things like this and draft-ietf-sidrops-rpki-has-no-identity so I can explain it when this goes to the IESG...
", "time": "2022-03-25T11:52:30Z"}, {"author": "Warren Kumari", "text": "(I haven't looked to see if it says in the doc)
", "time": "2022-03-25T11:52:43Z"}, {"author": "George Michaelson", "text": "this is my personal understanding: _no assertion signed by any RPKI certificate can (or should attempt) to warrant it anchors a proof of identity. it is not intended to, nor is is able to (by definition) certify identity. Signs over objects which assert identity carry no meaning in the signing as to the correctness of that identity._
", "time": "2022-03-25T11:54:30Z"}, {"author": "Rob Austein", "text": "@warren: short answer, I'm not sure they can be reconciled, but the key point is what kind of identity one is talking about. If it's just \"does the unknown party control this resource?\" it's this doc, if it's mission creep, not so much
", "time": "2022-03-25T11:55:05Z"}, {"author": "Warren Kumari", "text": "@GGM / Rob: Thank you. I suspect that htis is subtle and there will be come quesiotions at IESG time, so may ask for more text / help to explain this...
", "time": "2022-03-25T11:56:46Z"}, {"author": "Rob Austein", "text": "CRL bloat attack?
", "time": "2022-03-25T11:56:47Z"}, {"author": "Ties de Kock", "text": "Revocation tools are interesting, given that you need to know the RSC's EE exists.
", "time": "2022-03-25T11:56:54Z"}, {"author": "Ties de Kock", "text": "@Rob: CRL bloat attack unfortunately applies already for other signed objects :(
", "time": "2022-03-25T11:57:15Z"}, {"author": "George Michaelson", "text": "short lifetimes help prune CRLs. expired objects dont need to be on the CRL so it can truncate
", "time": "2022-03-25T11:57:40Z"}, {"author": "Rob Austein", "text": "Yes but this mechanism gives attacker more control over allocation cycle, I suspect
", "time": "2022-03-25T11:57:43Z"}, {"author": "Ties de Kock", "text": "Having short lived ROAs would also increase object churn a lot - it's a tradeoff
", "time": "2022-03-25T11:58:13Z"}, {"author": "Warren Kumari", "text": "Meetecho feature request: The \"choose sides to share\" should have the title, not jsut the filename.
", "time": "2022-03-25T11:58:51Z"}, {"author": "George Michaelson", "text": "no disagree. when we had strict serial order, we got implicit pruning by 'beyond this # its dead' but now we're in large UUID hash style certificate serials so can't use that
", "time": "2022-03-25T11:59:00Z"}, {"author": "Chris Morrow", "text": "Ties, can you say more about how more churn in the ROA set is important or not? (is it just 'moar downloads' or something else?)
", "time": "2022-03-25T11:59:21Z"}, {"author": "Meetecho", "text": "Warren: we'll see if this can be done
", "time": "2022-03-25T11:59:26Z"}, {"author": "George Michaelson", "text": "some attacks are hard to mitigate. they are often the simple ones. I mean DDoS still exists, right?
", "time": "2022-03-25T11:59:32Z"}, {"author": "Jeffrey Haas", "text": "In my meetings, we often name the files as part of upload as slot#_presoname
", "time": "2022-03-25T11:59:36Z"}, {"author": "Meetecho", "text": "Can you post this on tools-discuss so that the feedback remains?
", "time": "2022-03-25T11:59:44Z"}, {"author": "Ties de Kock", "text": "Chris: If you want to make ROAs expire quickly, so that they don't bloat the CRL list, in trade, you will end up publishing new ROAs much more often.
", "time": "2022-03-25T12:00:11Z"}, {"author": "Keyur Patel", "text": "it would be great to have a number associalted with the file name
", "time": "2022-03-25T12:00:17Z"}, {"author": "Keyur Patel", "text": "so you know the order
", "time": "2022-03-25T12:00:20Z"}, {"author": "Ties de Kock", "text": "\"probably need to model both scenarios to see what actually causes less traffic\"
", "time": "2022-03-25T12:00:31Z"}, {"author": "Jeffrey Haas", "text": "order exists in the meeting materials tool. It just needs to be preserved end to end. :-)
", "time": "2022-03-25T12:00:38Z"}, {"author": "Keyur Patel", "text": "@jeff - gets whacked if u update it last min or something
", "time": "2022-03-25T12:01:15Z"}, {"author": "Chris Morrow", "text": "Ties, ah that helps.
I'm not super (as a person/operator) concerned about either publishing 'more often' nor inducing more downloads. (I may be an outlier)
", "time": "2022-03-25T12:01:17Z"}, {"author": "Ties de Kock", "text": "Nor are you likely concerned with CRL size :)
", "time": "2022-03-25T12:02:01Z"}, {"author": "Jeffrey Haas", "text": "\"publish more often\" has the issue that if something disrupts distribution of the certs (attack traffic, e.g.) then you have stuff that expires. Usual comparable issue to DNS.
", "time": "2022-03-25T12:02:16Z"}, {"author": "Chris Morrow", "text": "probably a balance between longer CRL cost and 'moar downloads/publishes' :)
", "time": "2022-03-25T12:02:23Z"}, {"author": "Chris Morrow", "text": "jeff: yup.
", "time": "2022-03-25T12:02:41Z"}, {"author": "Rob Austein", "text": "IIRC APNIC won the first prize for CRL so long it could not be parsed by off the shelf tools. Was accidental, years ago, long since fixed, something wasn't pruning :)
", "time": "2022-03-25T12:03:17Z"}, {"author": "Ties de Kock", "text": "I
", "time": "2022-03-25T12:03:40Z"}, {"author": "Doug Montgomery", "text": "Are there pointers to documented RTBH abuse cases? Not doubting - just haven't seen such reports.
", "time": "2022-03-25T12:03:51Z"}, {"author": "Jeffrey Haas", "text": "Doug, I think you might be able to find some IXP operators willing to discuss it out of public sight.
", "time": "2022-03-25T12:04:16Z"}, {"author": "Chris Morrow", "text": "I know that for months Bell Canada sent every single prefix they had to AS701 with the RTBH community...
", "time": "2022-03-25T12:05:21Z"}, {"author": "Job Snijders", "text": "I know of several transit providers who do not offer RTBH because they can't safely offer such a service without being vulnerable through IRR-based filters
", "time": "2022-03-25T12:05:52Z"}, {"author": "Warren Kumari", "text": "... well, clearly they had an intent :-)
", "time": "2022-03-25T12:05:54Z"}, {"author": "Job Snijders", "text": "in my time at NTT we saw several nasty abuse cases
", "time": "2022-03-25T12:06:01Z"}, {"author": "Jeffrey Haas", "text": "Question about DOA: Is this intending to handle anything other than RTBH for adjacent ASes?
", "time": "2022-03-25T12:06:01Z"}, {"author": "Chris Morrow", "text": "luckily there were competing longer routes via another carrier that were used.
but i suspect ben/job mean: \"google sent rtbh for amzn prefixes to be mean' (or similar)
", "time": "2022-03-25T12:06:02Z"}, {"author": "Warren Kumari", "text": "701 shoud have honoroed it...
", "time": "2022-03-25T12:06:16Z"}, {"author": "Warren Kumari", "text": "problem solved.
", "time": "2022-03-25T12:06:20Z"}, {"author": "Jared Mauch", "text": "@Jeff do you want that relayed to the MIC or are you going to ask?
", "time": "2022-03-25T12:07:12Z"}, {"author": "Jeffrey Haas", "text": "if I can get mic time, I'll ask there.
", "time": "2022-03-25T12:07:23Z"}, {"author": "Jared Mauch", "text": "+1
", "time": "2022-03-25T12:07:31Z"}, {"author": "Warren Kumari", "text": "please keep the question short, Jeff.
", "time": "2022-03-25T12:09:25Z"}, {"author": "Nathalie Trenaman", "text": "Yes, friendly reminder: Chat here, is not (very well) incorporated in the minutes. If you want something minuted, please use mic queue
", "time": "2022-03-25T12:09:36Z"}, {"author": "Jeffrey Haas", "text": "30s at longest
", "time": "2022-03-25T12:09:38Z"}, {"author": "Warren Kumari", "text": "Thank you!
", "time": "2022-03-25T12:09:47Z"}, {"author": "Jeffrey Haas", "text": "fwiw, I suggest scraping chat for minutes.
", "time": "2022-03-25T12:09:49Z"}, {"author": "Jeffrey Haas", "text": "it's been useful in idr
", "time": "2022-03-25T12:09:57Z"}, {"author": "Nathalie Trenaman", "text": "Yes, they'll be added, but not integrated in the time line of the discussion
", "time": "2022-03-25T12:10:43Z"}, {"author": "Tim Bruijnzeels", "text": "regarding RSC, note that if the issuing CA performs a key rollover the .sig file will become invalid
", "time": "2022-03-25T12:11:53Z"}, {"author": "John Scudder", "text": "if Ignas could raise the mic closer to his talking-bits, that'd be great
", "time": "2022-03-25T12:11:58Z"}, {"author": "Tim Bruijnzeels", "text": "not saying that is bad, but note
", "time": "2022-03-25T12:12:01Z"}, {"author": "Rob Austein", "text": "Mike volume for currrent speaker low
", "time": "2022-03-25T12:12:02Z"}, {"author": "Jeffrey Haas", "text": "I have a proposal for the directly attached AS case that may require no rpki changes, but if the goal is transtiive RTBH marking it may not be a good fit
", "time": "2022-03-25T12:12:04Z"}, {"author": "Warren Kumari", "text": "Fixed?
", "time": "2022-03-25T12:12:19Z"}, {"author": "Jeffrey Haas", "text": "still low
", "time": "2022-03-25T12:12:24Z"}, {"author": "John Scudder", "text": "less bad
", "time": "2022-03-25T12:12:25Z"}, {"author": "Rob Austein", "text": "Still pretty quiet
", "time": "2022-03-25T12:12:27Z"}, {"author": "Rob Austein", "text": "Chew on the mike please
", "time": "2022-03-25T12:12:42Z"}, {"author": "Warren Kumari", "text": "And thank you to the speakers and questions for keeping things short.
", "time": "2022-03-25T12:12:46Z"}, {"author": "Warren Kumari", "text": "Fixed yet?
", "time": "2022-03-25T12:12:52Z"}, {"author": "Rob Austein", "text": "A little louder than it was
", "time": "2022-03-25T12:13:03Z"}, {"author": "Jeffrey Haas", "text": "he needs to move his mouth closer to the mic.
", "time": "2022-03-25T12:13:10Z"}, {"author": "Nathalie Trenaman", "text": "he is actually pretty close....
", "time": "2022-03-25T12:13:26Z"}, {"author": "Jeffrey Haas", "text": "better
", "time": "2022-03-25T12:13:39Z"}, {"author": "Rob Austein", "text": "Can hear after cranking local volume but is going to blow family into the next county when somebody else talks :)
", "time": "2022-03-25T12:13:43Z"}, {"author": "Warren Kumari", "text": "Ogg. In the room he is loud, and close (now)
", "time": "2022-03-25T12:14:09Z"}, {"author": "Rob Austein", "text": "Is better now definitely
", "time": "2022-03-25T12:14:20Z"}, {"author": "Warren Kumari", "text": "Thank you.
", "time": "2022-03-25T12:14:32Z"}, {"author": "Rob Austein", "text": "Klingon!
", "time": "2022-03-25T12:18:40Z"}, {"author": "Shunwan Zhuang", "text": "BGPsec is a perfect solution, and it would be great if performance were improved.
", "time": "2022-03-25T12:18:51Z"}, {"author": "George Michaelson", "text": "Klingon nets are in DTN WG
", "time": "2022-03-25T12:18:55Z"}, {"author": "Chris Morrow", "text": "ignas leaking his ultimate plan...
", "time": "2022-03-25T12:19:17Z"}, {"author": "Chris Morrow", "text": "this presentation (was also at iepg) is terrific... I had thought we ran a ton of scalability testing for this earlier in bgpsec's life... sadly we seem to have whiffed on that pitch :(
", "time": "2022-03-25T12:20:12Z"}, {"author": "Rob Austein", "text": "IIRC basic observation about BGPSEC scalability was that workload scales with number of peers, not total size of table. But was years ago and memory fades.
", "time": "2022-03-25T12:22:17Z"}, {"author": "Randy Bush", "text": "comic sans jealousy!
", "time": "2022-03-25T12:22:38Z"}, {"author": "Jeffrey Haas", "text": "it scales largely vs. number of routes and overall path length.
", "time": "2022-03-25T12:22:47Z"}, {"author": "Doug Montgomery", "text": "Some previous work on this topic - https://archive.nanog.org/sites/default/files/1_Sriram_High_Performance_Bgp_v1.pdf
", "time": "2022-03-25T12:22:52Z"}, {"author": "Jeffrey Haas", "text": "^
", "time": "2022-03-25T12:22:56Z"}, {"author": "John Scudder", "text": "Actually the slide is:
", "time": "2022-03-25T12:23:04Z"}, {"author": "John Scudder", "text": "What can be done then?
\u2022 BGPsec has some extensibility mechanisms inbuilt
\u2022 Protocol is versioned
\u2022 Algorithm identifiers could have different meaning in different
versions
\u2022 Hashed block layout needs to be rearranged
\u2022 Wire format needs to be rearranged
", "time": "2022-03-25T12:23:05Z"}, {"author": "Jeffrey Haas", "text": "main issue ends up being the people at the far end of the internet pay the highest tax... and often are the ones with less money for new hardware.
", "time": "2022-03-25T12:23:17Z"}, {"author": "Rob Austein", "text": "Verilog
", "time": "2022-03-25T12:23:29Z"}, {"author": "Nathalie Trenaman", "text": "slides: https://datatracker.ietf.org/meeting/113/materials/slides-113-sidrops-sidrops-bgpsec-scalability-00
", "time": "2022-03-25T12:24:21Z"}, {"author": "Job Snijders", "text": "Any work on supporting publication of Router Keys in hosted environments / web portals is worthwhile. Ignas is only talking about BGPsec \"on the wire\" (messages between two BGP speakers). The specs for CA / RP are stable and not impacted by performance improvement work on the BGP side of the house.
", "time": "2022-03-25T12:24:28Z"}, {"author": "Rob Austein", "text": "Nice preso, Klingon and all
", "time": "2022-03-25T12:25:55Z"}, {"author": "Job Snijders", "text": "indeed
", "time": "2022-03-25T12:26:07Z"}, {"author": "John Scudder", "text": "I don't want to use mic time for this but based on Ignas' sales pitch, it seems like a lead pipe cinch that we should work on this.
", "time": "2022-03-25T12:26:13Z"}, {"author": "Warren Kumari", "text": "Nod. Also thanks again to everyone for helping reclaim time.
", "time": "2022-03-25T12:26:19Z"}, {"author": "John Scudder", "text": "Sorry, that is an (archaic, even) idiom for \"of course we should\"
", "time": "2022-03-25T12:26:25Z"}, {"author": "Rob Austein", "text": "Yes
", "time": "2022-03-25T12:26:31Z"}, {"author": "Warren Kumari", "text": "Ties: is your question short?
", "time": "2022-03-25T12:26:45Z"}, {"author": "Ties de Kock", "text": "We can skip it :)
", "time": "2022-03-25T12:27:01Z"}, {"author": "Jeffrey Haas", "text": "better technique to make the crypto practical for more equipment would go a huge way toward deployability
", "time": "2022-03-25T12:27:11Z"}, {"author": "Jeffrey Haas", "text": "That said, usual caveat: https://xkcd.com/2347/
", "time": "2022-03-25T12:27:37Z"}, {"author": "Ties de Kock", "text": "@Jeffrey: and fit in memory. If we're talking about memory constrained platforms, time/memory platforms may not be possible
", "time": "2022-03-25T12:27:38Z"}, {"author": "Russ Housley", "text": "The caching that was suggested does not mean that the ECDSA signature algorithm was abused.
", "time": "2022-03-25T12:27:55Z"}, {"author": "Doug Montgomery", "text": "https://www.sciencedirect.com/science/article/pii/S0140366417303365?via%3Dihub
", "time": "2022-03-25T12:28:07Z"}, {"author": "George Michaelson", "text": "I am reminded of your talk on the costs of VLSI and special hardware design lockin John. made to IEPG some years ago
", "time": "2022-03-25T12:28:07Z"}, {"author": "Warren Kumari", "text": "Thank you. I really want to make sure that everyone has time to get through thier presetantions - we hadn;t budgeted enought time for my CoC bit and the tech bits.
", "time": "2022-03-25T12:28:08Z"}, {"author": "Rob Austein", "text": "I/O bandwidth for hash is common problem with hardware implementations of these crypto primatives, because jacking the clock speed doesn't help having to feed all the data through the soda straw
", "time": "2022-03-25T12:28:20Z"}, {"author": "Jeffrey Haas", "text": "I'm not a cryptographer, Russ, and I treat most of the presentation as the pipeline is capable of having reasonable parallelism installed. We've already looked at some such things as part of investigation.
", "time": "2022-03-25T12:28:44Z"}, {"author": "Warren Kumari", "text": "Ben: You joined the queue -- is that a clarification for now, or waiting till end?
", "time": "2022-03-25T12:34:00Z"}, {"author": "Job Snijders", "text": "@warren Ben says he'll wait to the end
", "time": "2022-03-25T12:38:38Z"}, {"author": "Warren Kumari", "text": "Thanks!
", "time": "2022-03-25T12:39:17Z"}, {"author": "Jeffrey Haas", "text": "+1 to Ben's comment.
", "time": "2022-03-25T12:40:33Z"}, {"author": "Jeffrey Haas", "text": "I'll stay out of queue.
", "time": "2022-03-25T12:42:54Z"}, {"author": "Jeffrey Haas", "text": "aspa is to validate as-path. if it shows in the path, it needs a record.
", "time": "2022-03-25T12:43:06Z"}, {"author": "Jared Mauch", "text": "(related: I believe that the SAVNET and ASPA stuff could be related to each other, if you didn't attend SAVNET)
", "time": "2022-03-25T12:44:07Z"}, {"author": "Jeffrey Haas", "text": "sav can happiily leverage this data.
", "time": "2022-03-25T12:44:29Z"}, {"author": "Jeffrey Haas", "text": "at a higher level, sav would benefit from rpsl style import/export policy
", "time": "2022-03-25T12:44:58Z"}, {"author": "George Michaelson", "text": "please not RPSL syntax.
", "time": "2022-03-25T12:46:15Z"}, {"author": "George Michaelson", "text": "(ok, not my problem. but gaaaaaaah)
", "time": "2022-03-25T12:46:23Z"}, {"author": "Jeffrey Haas", "text": "note I carefully didn't say syntax... just policy. :-)
", "time": "2022-03-25T12:46:33Z"}, {"author": "Chris Morrow", "text": "rpsl is so clear, and concise and feature-rich! why not use it?
", "time": "2022-03-25T12:47:28Z"}, {"author": "Chris Morrow", "text": "am joking :)
", "time": "2022-03-25T12:47:45Z"}, {"author": "John Scudder", "text": "ah, is joke
", "time": "2022-03-25T12:47:57Z"}, {"author": "Jeffrey Haas", "text": "the short form of it is that aspa provides a nice directed graph. roa's provide originator for prefixes. The two together provide a prefix to path viability graph. a small accommodation toward \"this prefix doesn't propagate here\" is enough to tighten the doors for sav a bit.
", "time": "2022-03-25T12:47:57Z"}, {"author": "Ties de Kock", "text": "(Warren: my question is for the end)
", "time": "2022-03-25T12:48:20Z"}, {"author": "Jeffrey Haas", "text": "This deck is less Klingon and more Sumerian.
", "time": "2022-03-25T12:48:52Z"}, {"author": "Jared Mauch", "text": "https://datatracker.ietf.org/meeting/113/materials/slides-113-sidrops-sidrops-ct-00
", "time": "2022-03-25T12:49:07Z"}, {"author": "Chris Morrow", "text": "the x-lation is what I always hoped would happen when someone sent me PPT slides which I had ot xlate for them... (these came as pdf though #sad)
", "time": "2022-03-25T12:49:28Z"}, {"author": "George Michaelson", "text": "those \"hoops\" are (or were) bound in a very opaque process. I am sure the participants understand them but I personally find the TA list in the browser incalculably worrying. I don't feel I have anything like enough exposure to the Diginotar process or its timeline, speaking as a user.
", "time": "2022-03-25T12:49:51Z"}, {"author": "Jeffrey Haas", "text": "posting pdf has been safer.
", "time": "2022-03-25T12:50:05Z"}, {"author": "George Michaelson", "text": "I know I found some lists. they said various vendors were acting. it felt like a smoke-filled-room process
", "time": "2022-03-25T12:50:18Z"}, {"author": "George Michaelson", "text": "its not unlike the public suffix list. I find it worrysome. governance without oversight?
", "time": "2022-03-25T12:50:38Z"}, {"author": "Chris Morrow", "text": "george, the TAL list in your browser is a bit orthogonal to the CT effort, right?
", "time": "2022-03-25T12:51:18Z"}, {"author": "Chris Morrow", "text": "(maybe this is job's current slide actually)
", "time": "2022-03-25T12:51:33Z"}, {"author": "Ties de Kock", "text": "Weren't the claimants independent of CAs if at all possible?
", "time": "2022-03-25T12:51:49Z"}, {"author": "Ties de Kock", "text": "Sure in practice by now they no longer are for web pki...
", "time": "2022-03-25T12:52:11Z"}, {"author": "Peter Hessler", "text": "sort of. these days having and publishing CT is basically a requirement for being accepted in the TAL list in the browser
", "time": "2022-03-25T12:52:16Z"}, {"author": "George Michaelson", "text": "@chris I dont know I've been brought to understand that yet. I still see it related
", "time": "2022-03-25T12:52:21Z"}, {"author": "George Michaelson", "text": "but if it turns out to be orthogonal I wouldnt be surprised. I may have dived down a rathole, rather prone to.
", "time": "2022-03-25T12:53:11Z"}, {"author": "Chris Morrow", "text": "ok. I suppose CT, to me, is a register of whom/what certificates were issued, and i SHOULD be able to (as a resource/domain holder) be able to say: \"HEY! THAT\"S ME!! but i did NOT register that!! REMOVE PLS!\"
", "time": "2022-03-25T12:53:37Z"}, {"author": "Peter Hessler", "text": "@chris yes, for sure
", "time": "2022-03-25T12:53:51Z"}, {"author": "Warren Kumari", "text": "@Chris: Yes.
", "time": "2022-03-25T12:53:53Z"}, {"author": "Chris Morrow", "text": "(this my little one did for a cert issued to them, actually)
", "time": "2022-03-25T12:53:53Z"}, {"author": "Peter Hessler", "text": "with the addition of \"hey, some random issued a cert for 8.8.8.8, lets look at details\"
", "time": "2022-03-25T12:54:16Z"}, {"author": "Ties de Kock", "text": "Because you need to incorporate the CT log response, CT log availability is an upper bound on CA availability :)
", "time": "2022-03-25T12:54:59Z"}, {"author": "Chris Morrow", "text": "Peter: yes :)
It looks like (to me) the CT work COULD permit another monitoring point for my infra to use in deciding if a) a route is trustworthy, and b) someone is trying to mess with me.
", "time": "2022-03-25T12:55:12Z"}, {"author": "Chris Morrow", "text": "ties :) yes... also dns because ... :)
", "time": "2022-03-25T12:55:25Z"}, {"author": "George Michaelson", "text": "I like transaction logs. Ledger. Public Ledger. I dont want to mention the chain of fools. But I do like public ledger ideas.
", "time": "2022-03-25T12:55:33Z"}, {"author": "George Michaelson", "text": "hmm. is this heading to \"instructions to RIRs\"
", "time": "2022-03-25T12:56:15Z"}, {"author": "George Michaelson", "text": "(which I can't argue against, it could be entirely proper to do that)
", "time": "2022-03-25T12:56:35Z"}, {"author": "Ties de Kock", "text": "@Chris and following the Certificate Transparency Policy group makes RPKI feel easy operationally :)
", "time": "2022-03-25T12:56:42Z"}, {"author": "Tim Bruijnzeels", "text": "What would be in scope? CA certificates only? or also manifests/crls
", "time": "2022-03-25T12:56:44Z"}, {"author": "Peter Hessler", "text": "instructions to the signing entities
", "time": "2022-03-25T12:56:50Z"}, {"author": "George Michaelson", "text": "he namechecked RIR on the slide Peter
", "time": "2022-03-25T12:57:08Z"}, {"author": "Ties de Kock", "text": "@Tim: Job just implied EE's, and I think there is a lot of value when you incorporate EEs
", "time": "2022-03-25T12:57:10Z"}, {"author": "Rob Austein", "text": "Part of the reason RPKI up-down protocol is CMS-based was audit capability. AFAIK nobody has made those data public.
", "time": "2022-03-25T12:59:44Z"}, {"author": "Peter Hessler", "text": "ahhh, the scope answered that
", "time": "2022-03-25T12:59:46Z"}, {"author": "George Michaelson", "text": "immutable logs. good way to describe it
", "time": "2022-03-25T13:00:45Z"}, {"author": "George Michaelson", "text": "@rob I think intent logging might be a bit different to instructed/requested CMS flow, but you have a point
", "time": "2022-03-25T13:01:28Z"}, {"author": "Warren Kumari", "text": "We only have 5 minutes for questions
", "time": "2022-03-25T13:01:31Z"}, {"author": "Tim Bruijnzeels", "text": "@Rob indeed.. I implemented logging but the amount of data grows... and grows..
", "time": "2022-03-25T13:01:43Z"}, {"author": "Rob Austein", "text": "Oh, I didn't mean audit of up-down CMS as replacement for CT. Just another source
", "time": "2022-03-25T13:02:22Z"}, {"author": "Tim Bruijnzeels", "text": "and a lot of it is irrelevant for up-down
", "time": "2022-03-25T13:02:26Z"}, {"author": "Jeffrey Haas", "text": "The people who've been recording every bgp route ever since the 90's have some amount of sympathy for you, Tim. :-)
", "time": "2022-03-25T13:02:26Z"}, {"author": "Tim Bruijnzeels", "text": "no I know - just saying.. but for up-down there is a lot of client asks entitlements and parent answers: same, same
", "time": "2022-03-25T13:03:03Z"}, {"author": "George Michaelson", "text": "@tim event sourcing is like mpeg4 it needs I and P blocks. I think rolling the base in the event log is a good path out
", "time": "2022-03-25T13:03:07Z"}, {"author": "Jared Mauch", "text": "or who process them in realtime from many-many-views :-)
", "time": "2022-03-25T13:03:09Z"}, {"author": "Jeffrey Haas", "text": "^
", "time": "2022-03-25T13:03:16Z"}, {"author": "Jean-Michel Combes", "text": "Just a comment: CT is useful only if this is used with the related protocol (e.g., SCT with TLS). Nothing prevents a \"malicious\" RIR to create a \"fake\" ROA and to use it as it wants without publishing it.
", "time": "2022-03-25T13:03:18Z"}, {"author": "George Michaelson", "text": "RRDP doesnt demand you go to the ur-Snapshot (for instance) its delta from a RECENT base
", "time": "2022-03-25T13:03:30Z"}, {"author": "George Michaelson", "text": "@jean how do you use a ROA if you dont publish it?
", "time": "2022-03-25T13:03:56Z"}, {"author": "Jean-Michel Combes", "text": "@George: good point
", "time": "2022-03-25T13:04:28Z"}, {"author": "Jean-Michel Combes", "text": ":)
", "time": "2022-03-25T13:04:31Z"}, {"author": "Maarten Aertsen", "text": "I think Ties\u2019 point about uptime bounds stand, doesn\u2019t it?
", "time": "2022-03-25T13:04:35Z"}, {"author": "Tim Bruijnzeels", "text": "@george fwiw my implementation uses event-sourcing for all changes - except... mft/crl re-issuance because that took too much space
", "time": "2022-03-25T13:05:00Z"}, {"author": "George Michaelson", "text": "I like event sourcing Tim. I also like frequent resets to a base, \"all this is in the past\" is part of the model
", "time": "2022-03-25T13:05:28Z"}, {"author": "Tim Bruijnzeels", "text": "I took a view of a hybrid model: the mft/crl updates do not change semantics - all other things are tracked forever
", "time": "2022-03-25T13:06:22Z"}, {"author": "George Michaelson", "text": "you can always replay the past blow-by-blow if you want to, you dont have to, if you publish intermediate index to current state to base events from
", "time": "2022-03-25T13:06:29Z"}, {"author": "Jeffrey Haas", "text": "pretty much every sane system for dealing with view over time will create synthetic checkpoints that represent the state at a given checkpoint time.
", "time": "2022-03-25T13:07:18Z"}, {"author": "Jeffrey Haas", "text": "these are always local views
", "time": "2022-03-25T13:07:50Z"}, {"author": "Ties de Kock", "text": "There is an interesting threat modelling question to answer here.
", "time": "2022-03-25T13:10:47Z"}, {"author": "George Michaelson", "text": "sure. ground truth runs from the epoch
", "time": "2022-03-25T13:10:50Z"}, {"author": "George Michaelson", "text": "views are inherently useful
", "time": "2022-03-25T13:11:02Z"}, {"author": "Peter Hessler", "text": "to speed up, I'm withdrawing from the queue
", "time": "2022-03-25T13:11:08Z"}, {"author": "Jean-Michel Combes", "text": "@George: publishing the ROA doesn't mean it is CT compliant (i.e., too different data structures).
", "time": "2022-03-25T13:11:17Z"}, {"author": "Jean-Michel Combes", "text": "*two
", "time": "2022-03-25T13:11:25Z"}, {"author": "Ties de Kock", "text": "@Jean-Michel Combes: The EE certificate of the ROA could incorporate SCT's toch?
", "time": "2022-03-25T13:11:36Z"}, {"author": "Nathalie Trenaman", "text": "Thanks Peter! But please bring your question to the list
", "time": "2022-03-25T13:11:38Z"}, {"author": "Jean-Michel Combes", "text": "@Ties: Sorry, I don't know
", "time": "2022-03-25T13:12:21Z"}, {"author": "Jean-Michel Combes", "text": "IMHO, applying CT to RPKI is not so easy ...
", "time": "2022-03-25T13:13:06Z"}, {"author": "Maarten Aertsen", "text": "chairs: we\u2019re now eating into the timeslot of the final speaker.
", "time": "2022-03-25T13:13:12Z"}, {"author": "Adianto Wibisono", "text": "I wonder if we have to apply CT as it is, or maybe RPKI's own/modified version, maybe to anticipate what will be presented next, things off the beaten path.
", "time": "2022-03-25T13:13:18Z"}, {"author": "George Michaelson", "text": "my personal view is that rolling a new way to do a thing others have defined, is usually a bad idea. if we come to this, I would want to caucus with people who have done CT to find a format for the intent log which works based on prior art.
", "time": "2022-03-25T13:17:37Z"}, {"author": "George Michaelson", "text": "(I think if we had known TAMP/CMP was in progress when we did the TAK/TAL stuff, we;d have thought harder to use TAMP, CMP, those protocols. Again, a personal view. the road not taken)
", "time": "2022-03-25T13:18:18Z"}, {"author": "Job Snijders", "text": "https://ripe83.ripe.net/wp-content/uploads/presentations/12-Certificate-Transparency-and-Discoverability.pdf (See last 2 slides)
", "time": "2022-03-25T13:18:23Z"}, {"author": "Job Snijders", "text": "indeed we have to consciously design CT to work for the RPKI
", "time": "2022-03-25T13:18:55Z"}, {"author": "Ties de Kock", "text": "@Job a believer still checks that there are enough SCTs in each certificate it accepts - it just does not check the complete CT log iirc.
", "time": "2022-03-25T13:19:00Z"}, {"author": "Peter Hessler", "text": "my question was more of a comment, I think bringing in the delegated RPKI operators into the intial scope would be helpful for this experiment, not only because several of them are already involved in webpki
", "time": "2022-03-25T13:19:21Z"}, {"author": "Job Snijders", "text": "@ties it is too early for me to meaningfully predict what we'll end up requiring from believers
", "time": "2022-03-25T13:19:39Z"}, {"author": "Ties de Kock", "text": "I'm just explaining the role of believer in the web PKI :)
", "time": "2022-03-25T13:20:01Z"}, {"author": "Job Snijders", "text": "ah
", "time": "2022-03-25T13:20:06Z"}, {"author": "Job Snijders", "text": "What was required from believers morphed over time
", "time": "2022-03-25T13:20:27Z"}, {"author": "Ties de Kock", "text": "Yeap. They tightened it down, EV first, all certs now. Logs from multiple organisations. Etc
", "time": "2022-03-25T13:20:59Z"}, {"author": "George Michaelson", "text": "theres also a huge minefield in \"instructions to the RIR\" which is way way WAY above my paygrade. Its the NRO EC, and wordings have to be done carefully.
", "time": "2022-03-25T13:21:00Z"}, {"author": "George Michaelson", "text": "(when it occurs in an IETF document, its very carefully worded)
", "time": "2022-03-25T13:21:16Z"}, {"author": "George Michaelson", "text": "Hmm. this paper looks like an improvement on the stories Byron and I brought to the table many many IETF ago.
", "time": "2022-03-25T13:22:15Z"}, {"author": "Jeffrey Haas", "text": "Security systems need to be resilient vs. bad actors. :-)
", "time": "2022-03-25T13:25:00Z"}, {"author": "Rob Austein", "text": "Please distinguish between \"publish in parent\" and \"parent controls RPKI keys\" (yes, I heard Job make that correction). Publication protocol was designed specifically to make publish in parent easier; parent controlling RPKI keys defeats point of using PKI in the first place.
", "time": "2022-03-25T13:25:12Z"}, {"author": "Nathalie Trenaman", "text": "Agreed
", "time": "2022-03-25T13:25:37Z"}, {"author": "Nathalie Trenaman", "text": "but yeah, people are lazy, and \"it just works\"
", "time": "2022-03-25T13:26:01Z"}, {"author": "Rob Austein", "text": "Sure, and for a lot of small operators running own CA is a PITA, so better that the outsource to parent than not do it at all. I just don't want us to end up recommending that model as good security practice
", "time": "2022-03-25T13:26:43Z"}, {"author": "Nathalie Trenaman", "text": "But delegated (and without Publish-in-Parent) is quite messy at times. I'm not sure why? Is it lack of sense-of-resonsibility? Something else?
", "time": "2022-03-25T13:28:54Z"}, {"author": "Job Snijders", "text": "messy in what regard?
", "time": "2022-03-25T13:29:24Z"}, {"author": "Job Snijders", "text": "oh, you mean publication servers being offline etc?
", "time": "2022-03-25T13:29:36Z"}, {"author": "Nathalie Trenaman", "text": "yes
", "time": "2022-03-25T13:29:41Z"}, {"author": "Job Snijders", "text": "i'll keep my silence as to what I believe are the underlaying reasons for that :)
", "time": "2022-03-25T13:30:34Z"}, {"author": "Jeffrey Haas", "text": "alt.rpki.*
", "time": "2022-03-25T13:31:30Z"}, {"author": "George Michaelson", "text": "RPSTIR is DB based. Not all validators use FS paradigm
", "time": "2022-03-25T13:32:21Z"}, {"author": "George Michaelson", "text": "but if you use rsync would have to write code to avoid FS write
", "time": "2022-03-25T13:32:29Z"}, {"author": "Chris Morrow", "text": "'fuse filesystem for the win' says jared.
", "time": "2022-03-25T13:32:40Z"}, {"author": "George Michaelson", "text": "(RPSTIR di ma should confirm. but thats how I understand it)
", "time": "2022-03-25T13:32:50Z"}, {"author": "Ties de Kock", "text": "the ripe ncc validator is/was DB based as well. I will refrain from commenting about that software's performance
", "time": "2022-03-25T13:32:53Z"}, {"author": "John Scudder", "text": "I did not expect to be reminiscing about NNTP this week
", "time": "2022-03-25T13:33:03Z"}, {"author": "Ties de Kock", "text": "(let's just say that db based is not necessarily better)
", "time": "2022-03-25T13:33:05Z"}, {"author": "George Michaelson", "text": "But it called /usr/bin/rsync so wrote to FS
", "time": "2022-03-25T13:33:05Z"}, {"author": "George Michaelson", "text": "Jared calls for code which doesnt do that
", "time": "2022-03-25T13:33:15Z"}, {"author": "Rob Austein", "text": "RRDP pretty much forced move to database because main lookup key became hash
", "time": "2022-03-25T13:33:33Z"}, {"author": "Chris Morrow", "text": "i'd point out that there are many filesystems that don't have performance problems with 'too many objects in the directory', but really.. this is an implementation detail at the publication point, I think :)
", "time": "2022-03-25T13:35:19Z"}, {"author": "Jean-Michel Combes", "text": "One thing is sure: ROV/BGPsec/ASPA have been/are standardized to avoid BGP monitoring ... if now we have to monitor CT logs (i.e., no CT material integrated inside the validation process of these mechanisms), that is sad ...
", "time": "2022-03-25T13:35:23Z"}, {"author": "George Michaelson", "text": "I think CT log analysis is outside Validation, its audit
", "time": "2022-03-25T13:35:44Z"}, {"author": "Keyur Patel", "text": "Thanks all. :)
", "time": "2022-03-25T13:35:48Z"}, {"author": "George Michaelson", "text": "maybe others disagree but I dont see the beams crossing
", "time": "2022-03-25T13:35:53Z"}, {"author": "Chris Morrow", "text": "wait 'to avoid monitoring' ? I didn't think taht was the goal.
", "time": "2022-03-25T13:35:53Z"}, {"author": "Melchior Aelmans", "text": "Thanks! safe travels home
", "time": "2022-03-25T13:36:01Z"}, {"author": "Chris Morrow", "text": "thanks! :)
", "time": "2022-03-25T13:36:21Z"}, {"author": "Peter Hessler", "text": "thanks all!
", "time": "2022-03-25T13:36:25Z"}, {"author": "Taiji Kimura", "text": "Thanks all!
", "time": "2022-03-25T13:36:40Z"}]