[00:13:50] brong leaves the room
[14:51:31] John L joins the room
[14:51:39] John L leaves the room
[17:45:33] Richard Barnes joins the room
[19:09:22] francesca joins the room
[19:12:36] <francesca> Etherpad: https://etherpad.ietf.org:9009/p/notes-ietf-107-secdispatch
[19:12:50] <francesca> Webex: https://ietf.webex.com/ietf/j.php?MTID=ma2f143a46b2c7cceae25de38a1b3318d  
[19:21:17] Cindy Morgan joins the room
[19:23:36] amontville joins the room
[19:33:46] <francesca> Slides: https://datatracker.ietf.org/meeting/107/session/secdispatch
[19:35:11] Marco Tiloca joins the room
[19:35:27] Marco Tiloca joins the room
[19:35:46] Sofia Celi leaves the room
[19:36:51] Marco Tiloca leaves the room
[19:39:40] carrickdb@jabber.hot-chilli.net joins the room
[19:39:58] Marco Tiloca joins the room
[19:40:32] jmagallanes joins the room
[19:42:19] Yoshiro YONEYA joins the room
[19:44:49] sfuerst joins the room
[19:46:47] ted.h joins the room
[19:48:12] Dan York joins the room
[19:48:49] jimsch1 joins the room
[19:49:34] rick@openfortress.nl joins the room
[19:50:17] Jim Fenton joins the room
[19:51:14] Marco Tiloca leaves the room
[19:51:38] Marco Tiloca joins the room
[19:51:56] Jonathan Hammell joins the room
[19:52:48] lsawyer joins the room
[19:52:50] Olaf Kolkman joins the room
[19:53:19] secdispatch joins the room
[19:53:39] Rich Salz joins the room
[19:54:04] Karl joins the room
[19:54:19] kaduk@jabber.org/barnowl joins the room
[19:54:42] John Levine joins the room
[19:54:53] Russ Housley joins the room
[19:54:56] Marco Tiloca leaves the room
[19:55:29] Pete Resnick joins the room
[19:55:50] Marco Tiloca joins the room
[19:56:03] Cullen Jennings joins the room
[19:56:07] lpardue joins the room
[19:56:24] tim costello joins the room
[19:56:42] spencerdawkins joins the room
[19:56:56] Roman Danyliw joins the room
[19:57:10] Stefan Santesson joins the room
[19:57:15] Mike StJohns joins the room
[19:57:19] cvmiller joins the room
[19:57:24] Barry Leiba joins the room
[19:57:45] Alissa Cooper joins the room
[19:57:46] <Pete Resnick> Someone is in webex as "Call-in User_3", but they're muted. It is going to be very difficult for them to un-mute themselves.
[19:57:47] Ben Schwartz joins the room
[19:57:54] sftcd joins the room
[19:57:58] Ben Campbell joins the room
[19:58:04] martin.duke joins the room
[19:58:12] <lsawyer> *6  *should*  work for audio-only mute/unmute, iirc
[19:58:26] Martin Thomson joins the room
[19:58:31] lpardue_eviltwin joins the room
[19:58:34] Atarashi Yoshifumi joins the room
[19:58:35] <Pete Resnick> Ah, I never learned that one.
[19:58:36] wseltzer joins the room
[19:58:39] xp29srs joins the room
[19:59:20] m&m joins the room
[19:59:20] brong joins the room
[19:59:34] Warren Kumari joins the room
[19:59:38] <Rich Salz> Minutes in the etherpad
[19:59:49] Jonathan Lennox joins the room
[19:59:53] Alexey Melnikov joins the room
[20:00:05] adam joins the room
[20:00:08] dkg joins the room
[20:00:14] Melinda joins the room
[20:00:24] Valery Smyslov joins the room
[20:00:41] cabo joins the room
[20:00:41] mnot joins the room
[20:00:49] Seth Blank joins the room
[20:00:52] <adam> The mnemonic for "*6" is "*M", for "MUTE"
[20:00:57] Greg Wood joins the room
[20:01:18] Shumon Huque joins the room
[20:01:24] secd joins the room
[20:01:26] msk joins the room
[20:01:27] <brong> Sorry my audio is very slow connecting
[20:01:47] Kathleen joins the room
[20:01:48] ek joins the room
[20:01:49] <brong> as in I've been waiting 3 minutes now
[20:01:58] wilma joins the room
[20:01:59] Karen O'Donoghue joins the room
[20:02:02] <kaduk@jabber.org/barnowl> I (for once) managed to remember to try joining like 10 minutes early
to avoid the top-of-the-hour load spike.
[20:02:13] <brong> I was barely awake 10 minutes ago!
[20:02:13] secd leaves the room
[20:02:16] Marco Tiloca leaves the room
[20:02:23] <cabo> I joined on the hour and everything worked, for once
[20:02:26] <brong> 7am Saturday morning here
[20:02:35] secd joins the room
[20:02:40] Peter Wu joins the room
[20:02:41] carl mehner joins the room
[20:02:42] Mike Bishop joins the room
[20:02:45] ssahib joins the room
[20:02:45] ekr@jabber.org joins the room
[20:02:56] <brong> alive:)
[20:03:02] <kaduk@jabber.org/barnowl> I know the 7am slot quite well, that being what IESG calls are at for
me here in US-pacific
[20:03:03] SM joins the room
[20:03:06] dee3@hot-chilli.net joins the room
[20:03:17] Samuel Weiler joins the room
[20:03:26] synp joins the room
[20:03:36] <brong> I have 2-3 7ams every week, all my exec 1:1s and full exec team meetings are there to fix US team
[20:03:40] <brong> fit
[20:03:47] secd leaves the room
[20:04:00] secd joins the room
[20:04:01] ebakoslang@jabb.im joins the room
[20:04:02] <dkg> ah trac.  just in time for python2 EOL ☹
[20:04:07] <synp> 11PM here
[20:04:13] <brong> fun
[20:04:17] <msk> what kaduk said
[20:04:32] csperkins joins the room
[20:04:33] <msk> almost daily lately
[20:04:34] Jeffrey Yasskin joins the room
[20:05:02] np joins the room
[20:05:09] <brong> I'm spending as much time in a headset as a callcentre agent these days!
[20:05:38] <jimsch1> Better than the two 4am calls I had last week
[20:05:56] Marco Tiloca joins the room
[20:06:24] <brong> ouch yeah
[20:06:38] <kaduk@jabber.org/barnowl> 4am, is that stay-up-late or get-up-early territory?  Or "midnight
stumbling around"
[20:06:51] <brong> (Avenue Q) It sucks to be me, it sucks to be me... is there anybody here it doesn't suck to be...
[20:06:55] kha joins the room
[20:07:08] <Jonathan Lennox> 4 pm in US EDT!
[20:07:08] secd leaves the room
[20:07:14] kha joins the room
[20:07:16] <Jonathan Lennox> (You asked)
[20:07:20] <lsawyer> that was an entirely different song from AveQ then i was expecting
[20:07:21] mnot waves at @brong down the road
[20:07:28] bhoeneis joins the room
[20:07:43] brong waves back from quarantine-house
[20:07:44] secd joins the room
[20:08:17] kha leaves the room
[20:08:17] secd leaves the room
[20:08:23] kha joins the room
[20:08:37] caw joins the room
[20:09:09] <dkg> reminder for future slide decks -- please number your slides!
[20:09:11] <ekr@jabber.org> I was hoping for a complex solution
[20:09:22] <francesca> dkg: great point to add to our wiki :)
[20:09:29] mglt joins the room
[20:09:32] <dkg> ooh, right
[20:09:36] <Richard Barnes> who knows if we’ll have computers in the far future?
[20:09:40] <synp> Just encode it in ASN.1
[20:09:46] chi.jiun.su joins the room
[20:10:05] kha joins the room
[20:10:15] <sftcd> I'm not seeing who really wants this tbh, I can imagine people thinking they want it, is anyone really validating signatures from 1999/2000 these days?
[20:10:34] <kha> Hello. This is a test
[20:10:37] <dkg> sftcd: i am, in my MUA
[20:10:39] <kha> Is this the jabber room for secdipatch of the IETF?
[20:10:39] kha leaves the room
[20:10:41] <dkg> it fails horribly
[20:10:50] <Mike StJohns> on legal documents - yes.  Of course its a paper signature
[20:10:50] <Jeffrey Yasskin> sftcd: The Web Archive wants this.
[20:10:58] <Jonathan Lennox> kha: yes
[20:11:11] <sftcd> @dkg: do you actually care about those sigs on old mails?
[20:11:24] <sftcd> @yasskin: wants it for.... ?
[20:11:27] <cvmiller> If only the Web Archive would archive IPv6-only sites :(
[20:11:30] <kha> Hi. this is a test message
[20:11:32] <kha> Not sure this web client works
[20:11:32] kha leaves the room
[20:11:34] <kaduk@jabber.org/barnowl> I can't refute the assertion that legal departments need to do
something like that.
[20:11:39] <dkg> sftcd: typically, no.  my preferred approach goes something like "cache validation when i first evaluate it, and trust my cache"
[20:11:44] <dkg> but the details aren't worked out
[20:11:47] <Barry Leiba> kha: Ça marche.
[20:11:53] <dkg> so i'm interested to see the proposal
[20:11:57] secd joins the room
[20:12:00] <sftcd> right, decrypting old mails I do need but sigs I don't care
[20:12:36] Mark Baushke joins the room
[20:12:42] <synp> Oh, I know.  We can do it with blockchain
[20:12:45] <jimsch1> dkg: But why should I trust your cache?
[20:12:46] <brong> haha
[20:12:51] <dkg> jimsch1: you shouldn't
[20:12:58] <dkg> i care about *me* trusting my cache
[20:13:01] <Jim Fenton> sftcd: I'm rarely in a situation where signature validation is critical. Suspect the same may be for you. But I dont work in Legal...
[20:13:13] <Jeffrey Yasskin> sftcd: To prove that they've archived a site accurately, for example in the case of https://www.fastcompany.com/40563570/the-internet-archive-rejects-msnbc-host-joy-reids-claim-that-her-old-blog-was-hacked. They also, of course, need the site to sign its content too, but that's something web packaging might help with.
[20:13:16] <dkg> afaict, Legal doesn't care at all about cryptographic signatures
[20:13:17] kha leaves the room
[20:13:19] <ted.h> @sftcd It seems like someone doing things like title search would want this; availability of a digital signature on a transmission document would be useful.  But those often go back in time a good bit.
[20:13:22] <dkg> IANAL
[20:13:29] <Mike StJohns> @sftcd - do you own your own house, do you have a will, do you have a trust or contract taht will pay out in 10-15 years?  All of these involve a person specific attestation usually in the form of a paper signature.
[20:13:32] <Jim Fenton> dkg: I think the problem is more like proving to a third party that it was properly signed.
[20:13:47] <dkg> Jim Fenton: yeah, that sounds problematic/impossible
[20:14:27] <wseltzer> IAAL and I still deal with Ls who think that only pen on paper works for a signature
[20:14:42] <jimsch1> I guess everything needs to be PQ signed
[20:14:49] <Jeffrey Yasskin> I'm guessing SVT replaces a complex technical challenge with the complex social challenge of trusting the present day vouching entity.
[20:14:50] kiran.ietf joins the room
[20:14:51] <sftcd> I know there are paper analogs to this yes, but still don't see much need for verifying 20 year old signatures - I'm not saying one shouldn't but if there is nobody today who is dealing with 20 year old signatures then I'm unsure we'll know real reqs
[20:15:08] <Jim Fenton> wseltzer: Yeah, our society is backward in that respect among others.
[20:15:16] <brong> it's like the version of copyright where you have to file a claim up-front
[20:15:31] <dkg> is this the point where we say "yo dawg"?
[20:15:36] <brong> and renew it every year if you still want to keep ti
[20:15:36] <sftcd> @yasskin: why wouldn't e.g. annual re-signing work for that application?
[20:15:38] mcr joins the room
[20:15:39] <ekr@jabber.org> My question is how you know that the SVT was signed when it says it was?
[20:15:45] <wseltzer> just don't say "I want a lawyer dawg"
[20:15:51] <dkg> ekr@jabber.org: we sign it with another SVT
[20:15:59] <brong> it's SVTs all the way down
[20:15:59] <ekr@jabber.org> Yeah, it's turtles all the way down
[20:16:02] <dkg> wseltzer: ha ha
[20:16:03] <brong> snap
[20:16:10] <Mike StJohns> @sftcd - Deeds are probably the best example of 20+ year attestations that need to be verified long after the signature.
[20:16:18] <brong> indeed
[20:16:19] <Pete Resnick> @ekr: Wouldn't the SVT be verifiable for the lifetime of the SVT?
[20:16:38] kaduk@jabber.org/barnowl leaves the room
[20:16:43] merm joins the room
[20:16:44] <sftcd> @msj: yes but who's looking at rsa1024+md5 sigs for deeds generated in 1999?
[20:16:51] <wseltzer> OT, but lawyer twitter was worrying about how to do will attestation in the era of social distancing :(
[20:16:52] kaduk@jabber.openafs.org/barnowl joins the room
[20:16:59] <ekr@jabber.org> @Pete: well, what happens if that key is compromised
[20:17:02] kha joins the room
[20:17:09] <Mike StJohns> @ekr - see my comments on the DNSOP list relative to DNS root key stuff - mainly you bind things into something like... sigh ... blockchains.  
[20:17:09] Marco Tiloca leaves the room
[20:17:14] kha leaves the room
[20:17:15] <Mike Bishop> The SVT is like a notary -- "I have checked that the signature is valid."  But you have to be able to validate the notary's signature (either time machine or requiring it to remain valid), and the notary has to time-machine back to validate the signature, no?
[20:17:20] <brong> use two different services and hope they don't both get comproised at the same time
[20:17:24] <secd> My state vote-by-mail system checks the paper signature on my ballot envelope Against a stored digitized version from the dmv - subject to drift over time as the sig can be up to ten years old.
[20:17:31] <synp> You'd have to trust this validation service for 20 years.   If the validation service became corrupt after 15, it could issue bad tokens for the 1999 signed documents.
[20:17:39] <Pete Resnick> @ekr: Oh, absolutely: Once the SVT is compromised, all of history is lost.
[20:17:42] <Barry Leiba> Wendy, some neighbours and I just shared beer on my deck, each in his own corner, bring his own chair and glas.
[20:17:55] kha joins the room
[20:17:57] <dkg> but if you've got a signature algo you can trust for 20 years, why not just use that algo in the first signature?
[20:18:08] <Rich Salz> ++
[20:18:23] <Jim Fenton> Barry Leiba: Presumably you didn't actually *share* the beer
[20:18:24] <kha> New try: test message for IETF secdipatch jabber room
[20:18:27] <mcr> the link on line 31 of the etherpad gets me a cloudflare 403.
[20:18:29] <ekr@jabber.org> Right, so TSAs are designed so they don't have key compromise problems
[20:18:32] <dkg> kha: we can all see you
[20:18:49] <brong> "designed so they don't have key compromise problems"
[20:18:54] <Barry Leiba> Jim, yes.  You put glass down and sit.  I fill and sit.  You pick up and sit, and drink.  All good.
[20:18:55] <kha> @dkg: thanks, finally i have a working setup. Friday is not too late
[20:18:56] <Mike StJohns> @sftcd - Yup - but I don't think that's what he's about.  think about a digitally signed bill of sale for a house and a deed registration all issued today.  How do you do that so when you sell your house in 20 years you can have a quiet title?
[20:19:05] <brong> assume a spherical TSA of uniform density
[20:19:11] <synp> @dkg the problem is not that the algorithm is no longer good. It's that we don't know that the signature existed in 1999.
[20:19:16] <mcr> All of mailarchive is now 403 for me :-(
[20:19:17] <ek> does mean SVT is not the best name?
[20:19:35] <sftcd> @msj: honestly? I don't know:-) but I'm not clear this is (part of) it
[20:19:44] <Mike StJohns> @sftcd - that said, I'm not sure this slves that problem
[20:20:03] <ekr@jabber.org> brong: yes, they don't depend on secrets at all
[20:20:03] secd leaves the room
[20:20:07] <ekr@jabber.org> They are based on hash chains
[20:20:13] secd joins the room
[20:20:18] <brong> yes, hash chains are good
[20:20:25] <brong> entirely public, all that
[20:20:27] <kaduk@jabber.openafs.org/barnowl> hash chains, like block chains before block chains were cool?
[20:20:27] <Pete Resnick> @mcr: mailarchive working for me just now.
[20:20:40] <brong> until somebody signs a secret that the court says they have to take down...
[20:20:41] <dkg> does "block chains" (in the slide) count for the drinking game?
[20:20:45] <Rich Salz> surety, the first "blockchain" stamping service, right?  30 years old?
[20:20:47] <Cullen Jennings> Lawyers - yes
[20:20:58] <dkg> "block chaining" that is
[20:21:00] <Jeffrey Yasskin> sftcd: Sites go offline and/or get their keys compromised. It might also be better to ask the actual people with this use case, who wrote https://www.iab.org/wp-content/IAB-uploads/2019/06/sawood-alam-2.pdf, to make sure I'm not forgetting some part of their requirements.
[20:21:01] <kha> lawyers and security people are the same: their answer is always no, don't do it because
[20:21:06] <brong> you put DVDCSS into the blockchain...
[20:21:06] secd leaves the room
[20:21:07] <Seth Blank> so -- trust me I made this
[20:21:18] <Jim Fenton> So this is the opposite of wanting some signatures to be non-provable after a certain date (DKIM signaturess on leaked emails, for example)
[20:21:18] Marco Tiloca joins the room
[20:21:42] <wseltzer> If this is about creating an artifact that stands for "I had a signed document," I'm not sure that crypto is as important as the liability bond the trusted third party is willing to give
[20:21:49] <Seth Blank> you can repudiate this easily-- just get your hands on the key used to generate the SVT and sign some garbage
[20:21:53] <Jonathan Lennox> If the hash method used for the hash chain is broken, the whole thing becomes useless, yes?
[20:22:16] <brong> yes... I would probably chain 3 different hashes
[20:22:28] <sftcd> @yasskin: thanks, will read (I wasn't at that w/s)
[20:22:32] <brong> much less likely that they all become broken in the same way
[20:22:35] <Jim Fenton> What would the key lengths need to be for very long-term signatures?
[20:22:35] <Pete Resnick> Who is the intended relying party who is going to making an SVT? A court?
[20:22:36] <adam> Yeah, I'm surprised he didn't discuss key compromise even once in this deck.
[20:22:39] <Jonathan Lennox> Is the assumption that hash functions won't fall to the point where we have a preimage attack?
[20:22:40] <Rich Salz> surety used two different hashes
[20:22:50] <Mike Bishop> Treating this not as a proof that the signature is good, but as a "note to self" that you've already checked it makes this slightly more palatable.
[20:22:59] <sftcd> @rich: two different hashes like in the early TLS KDF? :-)
[20:23:01] <Mark Baushke> so, thi proposal is sort of like electronic version of a paper validated by a notary and a copy of that document notarized by another notary in the future.
[20:23:10] <adam> Mike Bishop: Couldn't that be a single bit?
[20:23:12] <Rich Salz> i like this last bullet :)
[20:23:13] <dkg> Mike Bishop: isn't that doable with just a sort of arbitrary timestamped attestation?
[20:23:36] <synp> @dkg yes!
[20:23:45] <sftcd> reference to ltans is a bit like saying "hey we failed before we can do that again, but maybe we won't" ;-
[20:23:52] <Mike Bishop> @dkg, I think that's basically what this is.  Hence the claim of simplicity.
[20:24:03] <Jeffrey Yasskin> Mike Bishop++
[20:24:14] <Rich Salz> www.surety.com <http://www.surety.com>  still exists, to my surprise
[20:24:24] secd joins the room
[20:24:31] <ekr@jabber.org> Yes, you have to assume that the hashes are secure
[20:25:38] <Jonathan Lennox> How would you feel about something like "this hash has no known preimage attack, and at the time this was made it had no known collision attack"?
[20:26:02] <sftcd> so I think the real problem is we cannot know the requirements that'll exist in many years' time so while this is a nice thought experiment, it's hard to see it as more than that - that said, I don't object if someone and their funder wants to work on another stab at this
[20:26:17] <brong> the problem is that if you only log the hash, then the content can be substituted later
[20:26:27] <Rich Salz> +sftcd
[20:26:32] <ekr@jabber.org> brong: you mean if the hash has been compromised?
[20:26:43] tfpauly joins the room
[20:26:47] secd leaves the room
[20:26:50] <brong> ekr@jabber.org: suppose you note "in 2001 I saw this MD5 of a document":
[20:26:55] <kha> wouldn't it be hard to find the implementation of the old algorithms?
[20:27:09] <ekr@jabber.org> That actually is probably fine if it is authenticated with SHA-256
[20:27:14] secd joins the room
[20:27:18] <brong> that's not a proof that a particular document that claims to be from 2001 and has said MD5 is the document that was sighted
[20:27:20] <ekr@jabber.org> like if the hash chain used sha-256
[20:27:32] <synp> @kha: no, we have plenty of MD5 and MD4 implementations.
[20:27:32] <ekr@jabber.org> brong: I don't believe MD5 has any efficient preimage attacks
[20:27:33] <brong> ekr@jabber.org: sure, but it wasn't using sha-256 in 2001
[20:27:33] <sftcd> @kha: I saw a note yesterday that curl needs another DES implementation because openssl is dropping it (for NTLM apparently) ;-)
[20:27:34] <carrickdb@jabber.hot-chilli.net> @kha I thought the point is that you never have to dig up the old algorithms
[20:27:50] <Rich Salz> knowing the signature is valid just makes it simpler to know where to start arguing in court.
[20:27:59] <Rich Salz> I thought we gave up the nonRepudiation bit ?
[20:28:02] <brong> @ekr you've had 20 years to find a collision
[20:28:15] g.e.montenegro joins the room
[20:28:18] <ekr@jabber.org> brong: I think you're going to need to be clearer on the scenario you have in mind
[20:28:28] <ekr@jabber.org> in order for me to evaluate your claim
[20:28:40] <cabo> Why wait 20 years?  Get an SVT every year, from different entities
[20:28:45] <brong> claim: I file an MD5 with the SRT in 2001, playing a long con
[20:28:57] <Mark Baushke> at a certain point in time the private key may have leaked and not been identified as leaked until a later time which would then be revoked.
[20:28:59] <ekr@jabber.org> but then you needed a collision *then*
[20:29:00] <ekr@jabber.org> not now
[20:29:06] <dkg> cabo: or just re-sign every year
[20:29:06] secd leaves the room
[20:29:13] <cabo> The signer is dead
[20:29:17] spencerdawkins joins the room
[20:29:18] <brong> then I create a document that claims to be from 2001, in which somebody promised to pay me a zillion dollars in 2021
[20:29:21] <Mike StJohns> @cabo - stock certificate hidden in a sock drawer for 20 years
[20:29:27] secd joins the room
[20:29:43] <cabo> @Mike StJohns: Don't do that, then :-)
[20:29:43] <dkg> a dead sock drawer
[20:29:44] Marco Tiloca leaves the room
[20:30:02] <ekr@jabber.org> brong: that's a preimage attack
[20:30:17] secd leaves the room
[20:30:24] <synp> Huh!  I knew we would get to blockchain
[20:30:29] <brong> ekr@jabber.org: sure - but given 20 years you should be able to brute force that
[20:31:00] secd joins the room
[20:31:08] <cabo> ? That doesn't work
[20:31:25] <brong> or maybe replace MD5 with something that does have a preimage attack...
[20:31:29] <Mike StJohns> @synp - time is natures way of making sure everything doesn't happen at once; blockchains are humans ways of indicating the order in which things happened.... :-)
[20:31:38] <Pete Resnick> @ekr: Isn't he just saying that you have to replace the SVT before the SVT is compromised?
[20:31:52] <kaduk@jabber.openafs.org/barnowl> Thanks Francesca :)
[20:32:01] <ekr@jabber.org> brong: how do you replace md5? The hash algorithm is part of what's archived
[20:32:02] <sftcd> the L in LAMPS is (or was;-) supposed to be for "Limited" - this proposal is not very limited
[20:32:05] <francesca> ben :)
[20:32:24] <ekr@jabber.org> The Internet seems to think that MD5's preimage resistance is 2^{123}, which is still way outside of brute force
[20:32:26] <Jonathan Lennox> ekr: he means replace in his example.
[20:32:27] <brong> do one of each hash algorthm that was trusted in 2001 and hope one gets a preimage attack is what I meant
[20:32:31] <carrickdb@jabber.hot-chilli.net> @sftcd It seems limited to me. In what way is this not limited?
[20:32:47] <Mike StJohns> @cabo - can't prevent it... anyone ever hear the story of SF-LIST being delivered to an MIT computer many years after it was orginally queued.
[20:32:47] <ekr@jabber.org> Uh OK
[20:32:51] <adam> Pete Resnick: That seems to require a different kind of time machine than we've been talking about so far...?
[20:32:51] secd leaves the room
[20:33:00] <sftcd> 20 year signature validity is close to unlimited I guess:-)
[20:33:01] <Martin Thomson> So this isn't "I validated this signature".  It is "I was convinced that an entity I trust (who might be a previous iteration of myself) validated (this signature|a signature that confirms that an entity I trust (who might be myself <insert recursion>))"
[20:33:03] <dkg> MIC: is there a reason that this needs to be embedded in a document, and can't just travel alongside the document?
[20:33:16] <dkg> that would change the dispatch questions a lot
[20:33:27] <cabo> dkg: +1
[20:33:30] Marco Tiloca joins the room
[20:33:32] <dkg> (if we don't have to think about PDF and XML and $arbitrary_format)
[20:33:36] <Pete Resnick> @adam: Yeah, or an infinitesimally small amount of replacement time for the SVT.
[20:33:40] <Russ Housley> For this to work, the SVT needs to use the strongest hash and signature that are available; perhaps much more computationally expensive that was used by the original signer
[20:33:46] petereyee joins the room
[20:34:04] m&m leaves the room: Disconnected: closed
[20:34:11] m&m joins the room
[20:34:40] <sftcd> I'm also not getting how the svt token gets around the continuity problem
[20:35:04] <Martin Thomson> sftcd: lots of little bits of trust glues it together
[20:35:04] <brong> svt signs the full content with a newer hash
[20:35:07] <adam> So, I understand that the goal here is to figure out (a) whether there's interest to work on this, and (b) if so, where should we do that work? But it seems to me, given the claims being made, that we probably need some additional analysis about whether this technique is even possible. Until we have sec folks signing on to that notion, the other questions seem premature.
[20:35:13] <Jeffrey Yasskin> Is this a format for expressing notarization?
[20:35:15] <Pete Resnick> This doesn't sounds like much of a protocol. It sounds more like a re-signing policy.
[20:35:20] <Russ Housley> As chair of LAMP, I that that is the wrong home.  The "L" is Limited.  This is not a limited enhancement.  That said, I am not opposed to a WG forming BOF at IETF 108
[20:35:32] <dkg> are MIC: questions here not counted as being in the queue?
[20:35:41] <dkg> b/c my MIC: question above was before the queue was cut
[20:35:41] <carrickdb@jabber.hot-chilli.net> @Pete Agreed
[20:35:45] <francesca> the jabber scribe should move them in the queue
[20:35:52] <cabo> Not sure that Kathleen was aware
[20:35:53] <Pete Resnick> I think Richard just said that.
[20:35:54] <Mike StJohns> @adam agree
[20:35:57] secd joins the room
[20:36:14] <Roman Danyliw> Not a good fit for LAMPS.  This is too broad and too much work.
[20:36:16] <Mike StJohns> who's the jabber scribe?
[20:36:45] <sftcd> @bron: yes, i think the re-signer needs to re-sign the original to-be-signed data to get a benefit if you wanna avoid the cascade of sigs
[20:36:49] Yumi Sakemi joins the room
[20:37:43] g.e.montenegro leaves the room
[20:37:47] secd leaves the room
[20:37:50] <sftcd> I suggest the QUIC WG:-)
[20:37:57] <dkg> Russ Housley: what if this was just a timestamping service?
[20:38:00] <cabo> I think that this should be scoped to the JWT claim only.
[20:38:10] <Rich Salz> Chris Wood is the jabber scribe IIRC
[20:38:23] <ted.h> How do you say "bite your tongue" in Irish?  Asking for a friend...
[20:38:25] secd joins the room
[20:38:31] <mnot> We will deal with it in QUIC, sure.
[20:38:31] Marco Tiloca leaves the room
[20:38:33] Marco Tiloca joins the room
[20:38:45] <carrickdb@jabber.hot-chilli.net> @mnot lol
[20:38:50] <Jeffrey Yasskin> This is the best slide!
[20:38:51] <brong> QUICly
[20:39:11] <lpardue> @sftcd no
[20:39:40] secd leaves the room
[20:39:40] <francesca> Please if you haven't done so, sign the bluesheet: https://etherpad.ietf.org:9009/p/notes-ietf-107-secdispatch
[20:39:45] <francesca> (friendly reminder)
[20:39:46] <Jim Fenton> as usual, gret photos on Brian's slides
[20:39:50] <Jim Fenton> *great
[20:40:14] <Russ Housley> @DKG: if it was only a extension carried in the TSTInfo [RFC3161], then it would fir in LAMPS, but the proposal was for something bigger
[20:40:17] <adam> Yeah, Brian takes some pretty amazing pictures.
[20:41:00] <kaduk@jabber.openafs.org/barnowl> I lost audio from Roman
[20:41:02] <brong> slides have numbers, yay
[20:41:06] <brong> slide 2
[20:41:35] <Mike StJohns> Add that comment to "how do present virtually"
[20:41:45] <Seth Blank> hmm, this also feels relevant for mail-- specifically if there's a chain of oportunistic TLS servers in a row
[20:41:55] spencerdawkins leaves the room: Disconnected: No route to host
[20:41:55] <Rich Salz> hey @mnot, you guys like this?  We'd like a standard, I think.  (I spoke with Brian at 106 or 105)
[20:42:29] <kaduk@jabber.openafs.org/barnowl> Or rather, all my network conked out and my note about it got queued
[20:42:34] <brong> nice draft name
[20:42:36] <Jeffrey Yasskin> Re "numbering slides", is there a BCP for presentation slides? I remembered to put numbers and the session id and presentation title in my slides this time, but I don't have a checklist to remember to do it next time.
[20:42:37] <brong> slide 3
[20:42:45] secd joins the room
[20:43:37] <kha> what kind of deployments use client certificates?
[20:43:49] <msk> haha that actually is the draft name
[20:43:58] <Mike StJohns> don't you need the whole chain?
[20:44:03] <francesca> jeffrey: I found a slideset that was done by the edu team that had tips for good IETF presentations, I'll add it to the wiki
[20:44:11] <Rich Salz> Akamai has many customers that have end-users with client certs.
[20:44:13] <Jim Fenton> kha: Anything where the client authenticates with a smartcard
[20:44:22] <Roman Danyliw> @Kaduk: dispatch SVT to more community discussion required; suggest a mailing list if desired.
[20:44:22] <carrickdb@jabber.hot-chilli.net> @kha government stuff, for example
[20:44:29] <Rich Salz> Yeah, small deployments like us dept of defense :)
[20:44:41] <kha> i wasn't aware of such deployments. good info
[20:44:44] <Jim Fenton> Also, the country of Estonia.
[20:44:59] <Rich Salz> with buggy smartcards, right? :(
[20:45:00] <Mike StJohns> @kha, Jim - basically many US gov't systems requie the use of a PIV II card for TLS access
[20:45:14] <carrickdb@jabber.hot-chilli.net> @Rich haha :)
[20:45:14] <lpardue_eviltwin> @kha mTLS is often used for "devices" that a vendor wants to ensure can legitimately access their infra. I dread to mention IoT but that is a wide example
[20:45:19] <Jim Fenton> PIV II? ref?
[20:45:43] <kha> i know client certificates are used for eap-tls but didn't know they are also used for web traffic
[20:45:45] <Mike StJohns> @jim - one minute - its a SP800 series document at NIST (actually 4 of them)
[20:45:56] <Mike StJohns> Personal Identity Verification
[20:46:08] <wilma> does he really mean that the proxy would just forward the certificate?  not the verify msg?
[20:46:23] <Jim Fenton> Mike StJohns: I'm very familiar with PIV
[20:46:26] <dkg> wilma: yes, i think that's what it's doing
[20:46:28] <Mike StJohns> https://csrc.nist.gov/projects/piv/piv-standards-and-supporting-documentation
[20:46:36] <carrickdb@jabber.hot-chilli.net> @wilma If it weren't verified, wouldn't the proxy just kill the connection?
[20:46:37] <mcr> LOL.
[20:46:45] <mcr> (on voting)
[20:46:45] secd leaves the room
[20:46:46] <francesca> you got quoted mcr
[20:46:52] <Rich Salz> i believe so, yes.  origin has a trust relationship with the intermediary so it will trust whatever end-user identity is being asserted
[20:46:52] <Jonathan Lennox> If I put a Client-Cert header in my port-80 http connections, will reverse proxies notice?
[20:46:53] <brong> slide 7, I got caught up enjoying the content
[20:47:17] <ekr@jabber.org> That technical feedback was me
[20:47:19] <Jim Fenton> Mike: It was the II part of "PIV II" that confused me
[20:47:24] <mcr> Cool. Now I can file my Take-Down Notice on the IETF youtube channel, and $$profit$$.
[20:47:28] <Seth Blank> this feels more widely applicable than just HTTPS, right? thinking both email and (god forbid) DOH
[20:47:36] <mcr> DoH is HTTPs.
[20:47:36] <brong> slide "no numbers now, just pretty pictures":
[20:47:41] <wilma> PIV = FIPS 201
[20:47:46] <mcr> Email makes NOSENSE.
[20:48:06] <mnot> Everyone, please click the device enrolment notification and begin the process. It is safe.
[20:48:13] <mcr> If you are doing Client Side certificates for DoH, I'm impressed.
[20:48:15] Marco Tiloca leaves the room
[20:48:23] secd joins the room
[20:48:37] <Seth Blank> @mcr in email the use case is STARTTLS across multiple hops
[20:48:39] Andrew Campling joins the room
[20:48:45] <dkg> please let's not do client side certs for DoH
[20:48:52] kaduk@jabber.openafs.org/barnowl leaves the room
[20:48:55] <dkg> persistent client identities for DoH are a serious privacy concern
[20:49:02] <tfpauly> If you’re using DoH for privacy, why would you send a client cert?
[20:49:06] <mcr> @dkg, exactly.
[20:49:08] <brong> Seth Blank: at that point surely the right place is the Received header
[20:49:25] <brong> with key $fingerprint
[20:49:32] <mcr> I agree with brong.
[20:49:34] <Mike StJohns> Ah - PIV II was basically the re-do of the cac protocols. I'm not sure where II came from, but may have had something to do with the different version of the underlying applets
[20:49:45] <brong> speaking of which, why are we forwarding the entire key rather than a fingerprint?
[20:49:47] <adam> dkg: I think that depends on deployment scenarios. Like, if I had my own personal DOH server in a colo that I didn't want other people to use, I would want to be able to auth to it. HTTP Basic would work, but...
[20:49:47] <Alexey Melnikov> I was about to bring up RFC 7239 (Forwarded HTTP Extension), I am glad it was mentioned by the presenter
[20:49:53] <wilma> CAC is PIV compliant today
[20:49:54] secd leaves the room
[20:49:58] <mcr> putting the entire cert chain from each hop would be the only meaningful way, and that's kilobytes per hop. Please no.
[20:50:22] secd joins the room
[20:50:23] <Rich Salz> no.  handle simple end-user/intermediary (cdn, loadbanalcer etc)/origin case.
[20:50:31] <Jim Fenton> Mike: Ah, so FIPS 201-2 maybe? That's about to be revised.
[20:50:46] <mcr> (my previous comment related to SMTP)
[20:50:53] <wilma> FIPS 201 is being revised currently.
[20:51:05] <wilma> (this is Deb Coole)
[20:51:12] <msk> mcr: *cough* ARC *cough*
[20:51:25] <Jim Fenton> wilma: Oh, hi Deb.
[20:51:26] <dkg> brong: entire cert makes a lot more sense than fingerprint, because it avoids a lookup process on the receiving side
[20:51:34] <Rich Salz> Wilma?  Hilarous.  Hi Deb!
[20:51:34] secd leaves the room
[20:51:35] ek leaves the room
[20:51:42] xp29srs leaves the room
[20:51:43] <Mike StJohns> Maybe - google PIV II and you'll see various "PIV II" requirements documents.  
[20:51:48] <carrickdb@jabber.hot-chilli.net> @Wilma Hi Deb :D
[20:51:55] <mcr> @msk, I think that I could be convinced that some assertion about how the certificate was validated is in order, but not literally this.  
[20:52:17] <wilma> client auth is a bit of a pain through a proxy today.
[20:52:23] <Rich Salz> In our experience, origin's don't need the chain because they issued the cert or know how did.
[20:52:29] Marco Tiloca joins the room
[20:53:09] <Jim Fenton> wilma: Sometimes that's a feature (better MITM protection)
[20:53:19] <Rich Salz> No, you put the identity if you verified it, @mcr
[20:53:29] <wilma> sometimes it is just poking a hole in the proxy.
[20:54:07] Jonathan Lennox leaves the room: Disconnected: Replaced by new connection
[20:54:23] Jonathan Lennox joins the room
[20:54:31] <carrickdb@jabber.hot-chilli.net> Why does the backend server need the entire cert rather than just whatever it needs, like the SAN or something?
[20:54:35] <mcr> I need the chain, and I need to tell the front end load balancer that any chain is okay, and let the application code decide if that chain has the right semantics.
[20:54:41] <ekr@jabber.org> @mcr: right.
[20:54:46] <Richard Barnes> @carrickdb - avoid making those decisions up front
[20:54:53] <Rich Salz> @mcr you might need the chain.  But our use-cases do not.
[20:54:55] <carrickdb@jabber.hot-chilli.net> @Richard Fair enough
[20:55:05] <Jeffrey Yasskin> mnot: HTTPBIS is growing a pile of work that's mostly relevant to the reverse-proxy->backend connection. At what point might it make sense to split the WG?
[20:55:11] <mcr> @Rich, fair enough.  there are different uses here.
[20:55:15] <lpardue_eviltwin> I am aware of audit requirements that would like the services to be able to log client certificate information. How much info is dependent on the geo, policial, etc e.g https://en.wikipedia.org/wiki/EIDAS
[20:55:18] <jimsch1> @Rich: Would there ever be a cross-cert chain problem between the proxy and the server?
[20:55:30] <Rich Salz> I am curious what client-auth with proxies you have.
[20:55:32] <dkg> the draft doesn't consider the case where there are multiple TLS client certs either, afaict :(
[20:55:38] <ekr@jabber.org> @dkg: in my comments!
[20:55:50] <mnot> @Jeffrey - we're actually thinking of making a different split. Also, lots of HTTPbis stuff is concluding…
[20:55:59] Mirja joins the room
[20:56:01] <Richard Barnes> @carrickdb - apparently mohit agrees with you :)
[20:56:18] xp29srs joins the room
[20:56:18] <ekr@jabber.org> Note that it's not generally possible to reconstruct the entire chain from just the EE cert
[20:56:22] <mcr> @dkg, how does that work... multiple TLS client certs... is this some TLS 1.3 that I am ignorant of?
[20:56:29] <dkg> mcr: it's all versions of TLS
[20:56:30] <ekr@jabber.org> @mcr: post-handshake client auth
[20:56:31] <carrickdb@jabber.hot-chilli.net> @Richard hehe yay
[20:56:39] <lpardue_eviltwin> Jefferson HTTPbis
[20:56:44] <dkg> ekr@jabber.org: post-*initial*-handshake
[20:56:46] <Rich Salz> In our deployments, the origins know exactly who issued the cert, or they have pre-configured their end-user cert on their backend.  So, @jim, no.
[20:56:46] Marco Tiloca leaves the room
[20:56:49] <dkg> since it's still handshake
[20:57:08] <mcr> @ekr, oh, I see now. So actually, the headers might have to be forwarded multiple times as the TLS progresses....
[20:57:09] <Rich Salz> We don't see client-auth where client is "go get a cert anywhere" and talk to my server.
[20:57:18] <dkg> mcr: correct
[20:57:20] <ekr@jabber.org> @dkg: in TLS 1.2, it's multiple handshakes, but in TLS 1.3 we usually call it post-hadnshake :)
[20:57:34] Marco Tiloca joins the room
[20:57:59] <dkg> i'll get right on it and s/handshake/hadnshake/ everywhere :P
[20:58:04] <ekr@jabber.org> oic.
[20:58:11] <Mike StJohns> isn't there somewhat of a session binding problem here?
[20:58:22] <ekr@jabber.org> MSJ: well, it would be nice to have one
[20:58:23] <dkg> Mike StJohns there definitely is
[20:58:35] <ekr@jabber.org> Should we send an SVT?
[20:58:43] <Mike StJohns> *face plants*
[20:58:47] <lsawyer> lol
[20:58:47] <dkg> the intermediary can supply arbitrary HTTP request parameters that were not supplied by the actual client
[20:58:52] <brong> It sounds like there should be a header prefix which CDNs MUST strip or rewriter
[20:59:06] <dkg> the origin has to trust the intermediary completely
[20:59:10] secd joins the room
[20:59:12] <Richard Barnes> Sounds like folks are generally OK with DISPATCHing to HTTPBIS?
[20:59:17] <ekr@jabber.org> @dkg: HTTP Request Signatures!
[20:59:18] <dkg> b/c it's a raw assertion
[20:59:21] <carrickdb@jabber.hot-chilli.net> @Richard makes sense to me
[20:59:33] <adam> This looks like an HTTPBIS thing to me also
[20:59:41] <dkg> ekr@jabber.org: that sounds like a different proposal to me :)
[20:59:45] kaduk@jabber.org/barnowl joins the room
[20:59:48] <mnot> Maybe SECDISPATCH shouldn't be deciding what HTTPBIS's scope is :)
[20:59:58] <Mike StJohns> HTTPbis - but needs attention from the TLS guys
[21:00:02] <sftcd> yeah, HTTPBIS seems like it'd be a good venue
[21:00:06] <ekr@jabber.org> @dkg: and that would definitely need an SVT :)
[21:00:07] <sftcd> or.... QUIC :-)
[21:00:11] <lpardue_eviltwin> no
[21:00:17] <mcr> I think that SECDISPATCH should empower HTTPBIS to recommend splitting it out into a new WG, or keeping it in HTTPBIS.
[21:00:22] <Richard Barnes> @mnot - by “DiSPATCHED to”, i meant “you guys decide” :)
[21:00:34] <adam> mnot: So the authority of DISPATCH-style working groups never extends to the ability to make other WGs take on work
[21:00:36] <mnot> @Richard - I was talking about the conversation
[21:00:41] <Alexey Melnikov> Yes, HTTPBIS is the right place to start
[21:00:46] <adam> It just says "hey, that looks like the right place to us, how about you go ask?"
[21:01:21] <brong> Is there a canonical list of working groups where work is sent to die?
[21:01:26] <brong> QUIC, OAUTH, ... ?
[21:01:26] secd leaves the room
[21:01:29] <Jonathan Lennox> With the understanding that usually there's a pretty substantial overlap between the dispatch group and the WG things are sent to.
[21:01:34] <mnot> QUIC provides death-as-a-service, yes
[21:01:42] <Roman Danyliw> I think what we are saying is that HTTPBis is the right place to decide how to do the work.  If that means splitting off, by all means
[21:01:49] <mcr> @brong, LOL.
[21:02:02] <Roman Danyliw> Dispatch can't make a WG do the work, more than it can force AD-sponsor
[21:02:04] <synp> That's an awesome name for a movie
[21:02:21] <synp> Indicators of Compromise, I mean
[21:02:23] <mnot> Right. What you want to avoid is DISPATCH groups (because we have multiple!) being used to re-litigate decisions / venue shop.
[21:02:25] <Rich Salz> perhaps she's been compromised.
[21:02:35] <Rich Salz> KRISTY, BLINK TWICE IF YOURE OK
[21:02:47] <carrickdb@jabber.hot-chilli.net> @synp Great title
[21:02:49] <wseltzer> rsalz++
[21:02:58] <Kathleen> She did put a message to webex chat
[21:02:59] Marco Tiloca leaves the room
[21:03:13] spencerdawkins joins the room
[21:03:20] secd joins the room
[21:03:28] <sftcd> this is my fav slide of this IETF
[21:03:35] <lpardue_eviltwin> +1
[21:03:40] <dkg> ♥!
[21:03:48] <Jonathan Lennox> And with slide numbers!
[21:03:59] <mcr> (maybe a good this to add to the chair todo is to say hello to each presenter at the beginning of the meeting.)
[21:04:15] xp29srs leaves the room
[21:04:17] secd leaves the room
[21:04:21] <ekr@jabber.org> This is a pretty hi-faluting way to introduce SASL
[21:04:34] <dkg> do you prefer low-falutin'?
[21:04:51] <ekr@jabber.org> well, I just assumed he was gonna be like "people have HTTP and they have SASL"
[21:05:05] <Richard Barnes> i try to keep my falutin’ level pretty middle-of-the-road
[21:05:15] <Jonathan Lennox> mid-falutin'
[21:05:35] Marco Tiloca joins the room
[21:05:53] <lpardue_eviltwin> "just testin'"
[21:06:06] <Richard Barnes> plain-ole-falutin'
[21:06:15] <msk> so that wasn't Warren?
[21:06:26] <mcr> (I love the heart from the AAA to the user)
[21:07:12] <Richard Barnes> i’m doing all my slides in marker from now on
[21:07:13] <dkg> mcr: i read that heart as going the other way
[21:07:16] <ekr@jabber.org> It's amazing
[21:07:41] <carrickdb@jabber.hot-chilli.net> It's definitely refreshing
[21:07:50] <Andrew Campling> It's very retro, OHP format for those that remember pre-computer slideware
[21:07:58] <carrickdb@jabber.hot-chilli.net> yes
[21:08:02] <dkg> Andrew Campling: i was thinking the same thing
[21:08:12] <sftcd> I have a set of overheads from 1991 I still use in class sometimes
[21:08:15] <dkg> plus you can draw on it while it's on the OHP
[21:08:17] <ted.h> You know "glacial pace" used to mean slowly.  But now I wonder.  If I say I want to go glacially for my move to SASL, who picks the glacier that's the reference point?
[21:08:22] <Richard Barnes> secretariat needs to provide transparency projectors for 108
[21:08:25] <Alexey Melnikov> Slides style certainly got people's attention :-)
[21:08:33] xp29srs joins the room
[21:08:41] tim costello leaves the room
[21:08:59] tim costello joins the room
[21:09:00] <Jonathan Lennox> Richard: particularly tricky if 108 will also be virtual
[21:09:15] <Richard Barnes> Webex can do whiteboarding!
[21:09:21] <sftcd> @Alexey: what's the betting the next person tries this gets beaten up for it? ;-)
[21:09:31] <mnot> @richard: can it procure toilet paper?
[21:09:33] <adam> Richard Barnes: The first time I presented what became RFC 3265, it was with printed-out transparencies on an overhead projector.
[21:09:34] <dkg> ted.h: i think it just means "will eventually go away and we will all die" today
[21:10:12] <kaduk@jabber.org/barnowl> ted.h: do you want your glacial pace to be going forwards or
backwards, though?
[21:10:22] <cabo> Jonathan Lennox: There are document cameras for that…
[21:10:50] <Alexey Melnikov> What I like about SASL over HTTP is that I can use the same SASL framework in a mixed non HTTP and HTTP environment.
[21:11:25] <Alexey Melnikov> I also don't need to define a new authentication mechanism twice. HTTP is always being a special case
[21:11:27] <Rich Salz> ponts for "someone with a skirt"
[21:11:33] <dkg> this has the same problems as negotiate/spnego, though -- the UX on the browser side is very ill-defined
[21:11:39] <brong> that's a kilt
[21:11:42] <Alexey Melnikov> So I do support this work
[21:11:56] <brong> just missing bagpipes
[21:11:58] <mnot> @Alexey - no. Other protocols are the special case.
[21:12:01] <carrickdb@jabber.hot-chilli.net> @Rich ditto
[21:12:01] Steve Todd joins the room
[21:12:13] <brong> DISPATCHED to... QUIC
[21:12:21] <Alexey Melnikov> mnot: Like EVERR OTHER protocol.
[21:12:28] <sftcd> sorry if I missed him covering it, but wasn't the objection to SASL from HTTP folks the potential for >1 round-trip being needed?
[21:12:42] <francesca> Please if you haven't done so, sign the bluesheet: https://etherpad.ietf.org:9009/p/notes-ietf-107-secdispatch
[21:12:45] <brong> as opposed to the OAUTH redirect dance?
[21:12:45] <mnot> @Alexey - well, the SIP folks have seen the light.
[21:12:46] <kaduk@jabber.org/barnowl> the draft covers how to do >1 round-trip
[21:13:03] <Richard Barnes> @mnot you mean the RIPT folks?
[21:13:19] <mnot> @Richard - of course!Q
[21:13:36] <sftcd> @kaduk: yes, other drafts in the past had a story there too, but it never seemed to make http folks happy iirc (but maybe I'm misremembering)
[21:13:43] <mnot> (how do you retweet on this thing?)
[21:14:01] Jonathan Lennox leaves the room: Disconnected: Replaced by new connection
[21:14:02] Jonathan Lennox joins the room
[21:14:05] <Jim Fenton> mnot: cut/paste
[21:14:06] <dkg> last time i checked, negotiate/spnego with modern browsers meant that for any given origin, the user has a choice: effectively sending a permanent, globally-linkable cookie, or negotiate/spnego doesn't work.
[21:14:15] <ted.h> @mnot are you subtweeting someone by asking to retweet?
[21:14:17] <Richard Barnes> RT @mnot 5:13 PM mnot: (how do you retweet on this thing?)
[21:14:17] <dkg> well, not "cookie", but cookie-equivalent thing
[21:14:19] <mnot> @Jim: tempting :)
[21:15:03] <brong> RT @Richard Barnes 8:15 AM I am a teapot
[21:15:06] <Jim Fenton> [14:14:19] <mnot> @Jim: tempting :)
[21:15:09] <brong> we need SVT for these things
[21:15:13] Marco Tiloca leaves the room
[21:15:18] <brong> REPUDIATE
[21:15:31] <kaduk@jabber.org/barnowl> cookie-equivalent in some sense other than "contains a long-term
[21:15:38] secd joins the room
[21:15:41] <mcr> I had to step away....  would this let us do HTTPS if all the asymmetric crypto mechanisms die?
[21:16:01] <ekr@jabber.org> I don't think it keys the TLS connection
[21:16:07] <ekr@jabber.org> But someone else proposed something like that
[21:16:08] <kaduk@jabber.org/barnowl> This wouldn't *key* TLS for https, but authenticate within the TLS
[21:16:18] <ekr@jabber.org> Or maybe this guy
[21:16:19] <dkg> it'll authenticate the client -- but not the server?
[21:16:19] <Alexey Melnikov> mnot: Let's be honest, the lack of proper authentication framework in HTTP is why HTTP authentication is so sh*t
[21:16:21] <kaduk@jabber.org/barnowl> I think it was the same someone, actually, ekr
[21:16:31] <mcr> kaduk, right, so we'd still need a Quantum safe key agreement.
[21:16:39] <ekr@jabber.org> Alexey: no, I dont think that that's true at all.
[21:16:44] <mnot> @Alexey - no, it's UX
[21:16:54] <ekr@jabber.org> The reason that HTTP Authentication is shit is that no Web site wants to outsource auth to HTTP
[21:17:15] <dkg> except for IETF websites
[21:17:17] <ekr@jabber.org> Merkle puzzle boxes!
[21:17:18] <brong> there's a chicken and egg about that
[21:17:35] <ekr@jabber.org> brong: no, I don't think that that's correct. Sites take active efforts to keep the browser out of it
[21:17:38] <brong> nobody wants to outsource auth to HTTP because the UX is shit
[21:17:42] <mnot> Similar for IPv6 and DANE.
[21:17:43] <ekr@jabber.org> For instance, blocking password form fill
[21:17:56] <Alexey Melnikov> mnot: UX is not a protocol problem. Bad UX doesn't help, of course
[21:17:59] <brong> for the longest time, you couldn't log out over http auth sensibly
[21:18:08] <dkg> Alexey Melnikov: UX is definitely a protocol problem
[21:18:17] <mnot> @Alexey: protocols cannot solve all problems.
[21:18:28] <dkg> we have a history of designing protocols that do not take UX designer needs in mind
[21:18:31] spencerdawkins leaves the room: Disconnected: No route to host
[21:18:37] <carrickdb@jabber.hot-chilli.net> dkg: couldn't you have terrible UX even with a great protocol?
[21:18:42] <dkg> yes, of course
[21:18:55] <Alexey Melnikov> mnot: separable problems should be worked on separatedly
[21:18:55] Marco Tiloca joins the room
[21:19:08] <dkg> but if you expose incomprehensible primitives to the UX layer, then the designers can't make it sensible to the user.
[21:19:16] <dkg> and we have done that a lot
[21:19:18] <Jonathan Lennox> I feel confident that I can create terrible UX for any protocol you want
[21:19:25] <carrickdb@jabber.hot-chilli.net> dkg: I see
[21:19:35] <Alexey Melnikov> dkg: UX is out of scope for many protocols
[21:19:38] <ekr@jabber.org> dkg: true, but I mean, basic auth is more or less isomorphic to current web auth
[21:19:50] <ekr@jabber.org> But like the only people who use it are us and W3C :)
[21:19:56] <ekr@jabber.org> Do we even still use it?
[21:20:02] <dkg> we like to pretend that it's out of scope, and we have screwed the UX side of the projects for years as a result
[21:20:09] <kaduk@jabber.org/barnowl> and basic auth is crap
[21:20:17] secd leaves the room
[21:20:21] <ekr@jabber.org> kaduk: in what way is it crap? It's insecure?
[21:20:34] <dkg> it's a bearer token, for one thing
[21:20:43] <kaduk@jabber.org/barnowl> It's insecure in that it's a bearer token, yeah
[21:20:44] <ekr@jabber.org> dkg: totes, but like so is passwords in forms
[21:20:53] <dkg> indeed, i don't like those either
[21:20:55] secd joins the room
[21:20:58] <Richard Barnes> anyone want to actually talk on the mic?
[21:21:07] <ekr@jabber.org> I feel like like it or not, WebAuthn is kinda what we have here for Web site auth
[21:21:23] <bhoeneis> UX considerations or how to improve UX matter in protocols is definitely something the IETF should work on
[21:21:35] <Jeffrey Yasskin> Agree with DKG: even though detailed UX is out of scope, it's important to have some good UXes in mind when designing things.
[21:21:38] <ekr@jabber.org> and WebAuthn is basically a bolt-on to passwords
[21:21:40] <Mike StJohns> I've seen basic auth carry other tokens - especially in conjunction with client certs...
[21:22:10] <adam> Mike StJohns -- Did the header field actually say "Basic"?
[21:22:30] <Martin Thomson> adam: I have seen the same thing
[21:22:36] <Richard Barnes> @ekr@jabber.org - webauthn has some non-password modes
[21:22:42] <Mike StJohns> yup
[21:22:43] <Martin Thomson> the token really doesn't mean anything
[21:22:48] <brong> "App passwords" are basically tokens via Basic
[21:23:01] ebakoslang@jabb.im leaves the room
[21:23:09] <Mike StJohns> it was a work around AFAICT - I didn't spend any time on learning more
[21:23:26] <Martin Thomson> Apparently GitHub ignores the token, because their documentation is inconsistent with respect to "bearer" or what have you
[21:23:28] ebakoslang@jabb.im joins the room
[21:23:48] <mnot> Same-origin policy is your friend…
[21:23:57] <mnot> (until it bites you)
[21:24:14] <sftcd> @mnot: I think he's saying he's leery of the SOP
[21:24:15] <adam> Huh. Yeah, I'm very much used to seeing "Authorization: bearer <JWT>"
[21:24:18] Mo Zanaty joins the room
[21:24:42] <dkg> pushing auth to the lower layer is great, until you realize that the lower layer is invisible to the user, and you need to ask the user something like "do you want to uniquely identify yourself to service X"
[21:25:14] <Pete Resnick> EKR's co-worker obviously wants to inject something.
[21:25:22] <dkg> if every user was fine with being identified globally with a unique identifier this wouldn't be a concern.
[21:25:26] <mnot> Making all the things look the same is not sufficient motivation. There are good reasons why HTTP auth isn't used widely (as per above), and a solution that doesn't address those shortcomings is not going to succeed.
[21:25:59] <brong> Webex needs an easy way to show who is currently sending audio... like how browsers display tabs that are producing audio
[21:26:18] <Mike StJohns> Mine is showing EKR speaking..
[21:26:19] <Richard Barnes> there’s an indicator in the roster
[21:26:23] <kaduk@jabber.org/barnowl> at least some of the webex UIs show who is sending audio
[21:26:26] <Mike StJohns> In the tab at the top
[21:26:30] <Jonathan Lennox> @brong: if you're in the mode that has the small windows above the big window, it highlights people sending media (audio or video)
[21:26:33] <kaduk@jabber.org/barnowl> (but there are too many different UIs for me to count...)
[21:26:38] <Jonathan Lennox> In the Mac desktop UI
[21:27:16] <brong> Jonathan: does it work sensibly with 200 users?  Because you need to sort them to the top
[21:27:27] <Mike StJohns> click upper right - "Video strip view"
[21:27:27] merm leaves the room
[21:27:39] ebakoslang@jabb.im leaves the room
[21:27:51] <Jonathan Lennox> @brong: as long as most people are muted, yeah.  I dunno what happens if more than 6 people are sending media
[21:29:05] <sftcd> so I read the draft and saw the mails - I also wonder if this'd make a useful RFC when done, but OTOH it is an interesting topic and it's possible the IETF and the community of security practitioners from which Kirsty comes could benefit from trying to make a finished RFC out of this - I'm not sure if the effort would be efficient/worthwhile but it should be educational all around
[21:29:19] ash joins the room
[21:29:21] <Mike StJohns> on mine I'm getting host/presenter/last 4 speakers
[21:29:21] Marco Tiloca leaves the room
[21:29:31] <mcr> @sfcd. was there any reply to my comments?
[21:29:31] secd leaves the room
[21:29:35] secd joins the room
[21:29:46] <sftcd> @mcr: which comments?
[21:29:47] merm joins the room
[21:30:18] <mcr> https://mailarchive.ietf.org/arch/msg/secdispatch/H2mbJ3ogjN2IZLgG2BEp0lphbhw/
[21:30:43] <mcr> aha, there is a reply which I never saw.
[21:31:06] <sftcd> @mcr: I guess if you check your email... :-)
[21:31:16] <dkg> next slide?
[21:31:27] <mcr> quarantine means I can't read email at the pub.
[21:31:32] <dkg> Richard Barnes: can you advance the slide?
[21:31:32] <kha> that's nice. put the draft in the slides
[21:31:44] <sftcd> you have an open pub? thing of the past here
[21:32:00] <mcr> yes, I have to learn to read my email at home.
[21:32:22] <adam> I very much like "Pyramid of Pain" as a section heading.
[21:32:22] <mcr> Pyramid of Paine.
[21:32:24] <Rich Salz> "I love a good table of contents"  How veddy veddy eglish
[21:32:24] <mcr> nice.
[21:32:36] xdf joins the room
[21:32:47] secd leaves the room
[21:33:04] <Mike StJohns> what's Kristy's organizational association?
[21:33:06] <msk> many good netflix movie titles in here
[21:33:21] <Seth Blank> I believe she's with the UK NCSC
[21:33:21] <Rich Salz> UK Cyber Defense Agency
[21:33:33] <kaduk@jabber.org/barnowl> UK NCSC, yes
[21:33:33] <Mike StJohns> "Hashes of Malice" as a movie title?
[21:33:45] <msk> i like it
[21:33:46] <sftcd> @msj: near some horseracing track somewhere:-)
[21:34:00] <Mike StJohns> tnx
[21:34:20] <Richard Barnes> @MSJ “Hashes of Malice” is my death metal band name
[21:34:23] rick@openfortress.nl leaves the room
[21:34:41] <kaduk@jabber.org/barnowl> Not "Hashchains of Malice"?
[21:34:50] <Mike StJohns> *face plants*
[21:34:54] <Richard Barnes> even better
[21:34:58] <adam> With an inaugural album "Pyramid of Pain"
[21:35:16] <Mike StJohns> Actually "Pyramid of Paine" scans better
[21:35:24] secd joins the room
[21:35:27] <Mike StJohns> ref "Major Paine"
[21:35:29] <Andrew Campling> I thougt that was the next series after 50 Shades
[21:35:37] <kaduk@jabber.org/barnowl> Agreed (msj)
[21:36:53] Marco Tiloca joins the room
[21:37:08] <kaduk@jabber.org/barnowl> I don't think it's relevant for dispatch, but I do wonder whether
there's an overlap between IoC and PII that would have to be
considered in practice
[21:37:20] <lpardue_eviltwin> more pain, more gain!
[21:37:20] secd leaves the room
[21:37:29] <adam> I mean, yes? IP addresses are frequently considered PII.
[21:37:32] secd joins the room
[21:37:54] <Mirja> it's not PII if you are a bot...
[21:38:15] <brong> BII
[21:38:20] <mcr> There is a significant need to pick a standard way for ISPs and other network operators to be able to exchange IoCs in a privacy preserving way.
[21:38:24] <adam> It _is_ PII if a machine in my house gets compromised...
[21:38:26] <sftcd> @mirja: it's common to have lists of IoCs some of which will be false positives
[21:38:37] <Jonathan Lennox> It'd be fascinating to see a APT file a GDPR complaint against cyberdefence people
[21:38:52] <kaduk@jabber.org/barnowl> mcr: allow me to introduce you to my good friend, Alexey, who until
wednesday was responsible for the MILE working group
[21:39:02] <Mike StJohns> Is there a protocol for that (automated complaint)?
[21:39:04] <John Levine> doesn't INCH do a lot of this?
[21:39:09] <ekr@jabber.org> isn't there some mitre thing too?
[21:39:10] <Barry Leiba> It'd be best if people who are not EU lawyers not speculate about what is and isn't PII.
[21:39:28] <Kathleen> INCH/MILE exchanges this type of data, yes.
[21:39:35] <Andrew Campling> IP addersses are definitely consider PII by EU regulators
[21:39:35] secd leaves the room
[21:39:36] <Barry Leiba> The issue is more fraught than any of us imagine.
[21:39:37] Marco Tiloca leaves the room
[21:39:43] Marco Tiloca joins the room
[21:39:44] <adam> Or if Google decides that my obscure search-fu means that I'm a robot (which happens quite quickly if you use *any* advanced search features, like "site:example.com" or "filetype:pdf")
[21:39:45] <Mirja> (I was just joking…sorry… no more jokes fo me)
[21:39:54] <sftcd> @barry: disagree:-) PII should be (but isn't) in the eye of the beholder and not the beholder's lawyer
[21:39:55] <mcr> Yes, I think that MILE / INCH is probably an answer.  
[21:40:07] <mcr> that's even in my email.
[21:40:07] <ekr@jabber.org> sftcd: it sounds like you are agreeing!
[21:40:22] <sftcd> me agreeing? With what?
[21:40:23] <brong> PII == whatever an EU lawyer can convince an EU regulator it is
[21:40:31] <mcr> I was hoping some INCH/MILE expert would have replied to my comment.
[21:40:34] <ekr@jabber.org> That PII is defined by lawyers, you just wish it weren't
[21:40:36] <adam> sftcd: I'm as shocked as anyone else
[21:40:42] <sftcd> @ekr: yes that is true
[21:40:44] <Kathleen> MCR, what comment
[21:40:46] <Barry Leiba> Stephen: indeed, part of the irony is that *your* data may be protected even if you don't consider them private.  Go figure.
[21:40:56] <mcr> https://mailarchive.ietf.org/arch/msg/secdispatch/gqdcU9MbuNgZYf8bmGlfMkz6C6Q/ @Kathleen
[21:42:16] <synp> Does this thing need a WG?  Why not just individual or even ISE?  Do we expect to have IETF input change the content?
[21:42:46] <Pete Resnick> She actually wants it to be an RFC because she thinks it's the best place to publish it. That's both frightening and heartwarming.
[21:42:52] <synp> I'm not contesting that it's useful and needs to be published.  I'm just not sure *we* are gointg to contribute much
[21:42:59] <mcr> It could go via ISE.  That's about the only place I would imagine.  Maybe @Kathleen and @Alexey have more INCH/MILE clue could say if there was some stronger connection.
[21:43:01] <kaduk@jabber.org/barnowl> It would benefit from having a pool of people who are indoctrinated in
the IETF culture/RFC-style helping to shape the writing
[21:43:03] <Kathleen> @mcr - fits with ROLIE and IODEF
[21:43:08] <adam> Pete: And it argues for ISE rather than IETF, if that's the sole logic
[21:43:08] Marco Tiloca leaves the room
[21:43:19] Marco Tiloca joins the room
[21:43:25] <Pete Resnick> @mcr/adam: Yep, exactly what I was thinking.
[21:43:25] <msk> adam++
[21:43:29] <sftcd> @kaduk: I tend to agree with the benefit there but is that effort worthwhile? it could be a lot of work - pain even;-)
[21:43:31] <Kathleen> She just named other specs instead in the draft
[21:43:31] <msk> was going to propose the same
[21:43:51] <kaduk@jabber.org/barnowl> sftcd: well, I for one am not signing up to do the work myself.  At
least not for the next 2 years :)
[21:44:04] <francesca> It's time to join the queue people :)
[21:44:07] <Kathleen> ISE, unless it evolves to be used with protocols and provides applicablity
[21:44:08] <Alexey Melnikov> mcr: I need to think whether or not MILE is a good place for this. Certainly sending an email to MILE asking for reviews makes sense
[21:44:10] dkg joins the room
[21:44:13] <Alissa Cooper> I feel like this might be relevant: https://www.ietf.org/about/groups/iesg/statements/support-documents/
[21:44:19] <sftcd> if this were dispatched to mile, I think there'd be no benefit from it for the IETF tbh
[21:44:31] <Rich Salz> sftcd++
[21:45:01] <mcr> @Alissa, yes, give that, I don't think we should publish as is.
[21:45:04] <Rich Salz> MIC: Is the interest in IETF because it will help the IETF or because the IETF has good rep fr publishing
[21:45:36] Marco Tiloca leaves the room
[21:45:45] <Andrew Campling> Won't it inform thinking for IETF folk?
[21:45:49] <francesca> Rich: ack
[21:46:02] <sftcd> @rich: isn't this just a fragment of the SMART proposal? (some bits of that were worthwhile, this possibly being one)
[21:46:02] <Seth Blank> to the question at the MIC, I think a potential useful place for a document here would be in Privacy Considerations -- "this item could be PII, but is also a useful IOC, therefore..."
[21:46:07] <kaduk@jabber.org/barnowl> I think she thinks it will help the IETF.  I'm not sure I disagree,
thouhg cost/benifit is unclear
[21:46:37] <Barry Leiba> I'm very mixed on it.  I think there's value, but I'm not sure where it goes.
[21:46:58] <Ben Schwartz> I think this is the IAB's domain.
[21:47:00] <mcr> are there some more IETF experienced people with strong connections to NCSC ?
[21:47:32] <Seth Blank> @barry might this be better as a M3AAWG BCP?
[21:47:38] <sftcd> btw, does anyone know how MISP (https://www.misp-project.org/) corresponds to the mile etc. work in the IETF? Probably off topic for now but I'd like to understand that sometime if it wouldn't bore me to death:-)
[21:47:53] dkg leaves the room
[21:48:01] <msk> @seth: Is it limited to messaging?
[21:48:04] <Rich Salz> I don't think so.  She's realatively new here.  I remember hanging out with her, {others} Deb briefly in Singapore.
[21:48:27] <Alexey Melnikov> mcr: NCSC people are relatively new to IETF
[21:48:31] <wilma> not me, Deb
[21:48:46] <ekr@jabber.org> The interest in IETF is because we have an awesome publication format
[21:48:46] <Rich Salz> I think this is good to bring new community into IETF.
[21:48:51] <Rich Salz> reputation
[21:48:58] <Barry Leiba> Seth; perhaps, and there's an NCSC guy who's been to M3AAWG.
[21:48:59] <sftcd> and we know how to UPDATE the shit out of things:-)
[21:49:09] <mcr> Alexey, yes, that's clear.  I want to bring them in, but I would like them stretch a bit further.
[21:49:15] <Richard Barnes> @Rich - are you just too lazy to mic up? :)
[21:49:19] <adam> sftcd: Shush, you.
[21:49:28] <mcr> I don't know that much about misp-project.  
[21:49:35] <Martin Thomson> last time Rich used his mic, we all suffered
[21:49:35] <Rich Salz> I was told my mic suckedXXXXX wasn't good.
[21:49:36] <Seth Blank> Several NCSC people have been to M3AAWG. Ian Levy (Tecnical Director of NCSC) was also at IETF105 in Prage I believe.
[21:49:37] secd joins the room
[21:49:37] <Barry Leiba> I wouldn't call the NCSC people that "new" to the IETF; they've been around for a bit, and Kirsty has, in particular.
[21:49:54] <Cullen Jennings> "It is notoriously hard to bring new work to the IETF. " hope that makes the minutes
[21:50:00] dkg joins the room
[21:50:02] <Alexey Melnikov> Barry Leiba: they have been to several IETFs, but they didn't publish any RFCs yet
[21:50:04] <Seth Blank> err, 104
[21:50:30] <Seth Blank> Ian Levy and Richard C have also both been very active in DMARC with respect to the PSD draft
[21:50:49] <Seth Blank> they've brought lots of data and willingness to participate in experiments
[21:51:02] <Barry Leiba> I think what Kirsty is outlining *is* appropriate for IETF publication.  I just don't know the right home.
[21:51:27] <Alexey Melnikov> Seth Blank: right. My point is that they don't yet have experience with getting documents approved as RFC
[21:51:31] <sftcd> @barry: I kind of agree but still wonder if the effort would be worth it
[21:51:34] <Barry Leiba> Alexey, what do you think about it in MILE?
[21:51:37] <ekr@jabber.org> This really seems like a prime ISE candidate
[21:51:43] <sftcd> ISE mebbe yeah
[21:51:47] <Barry Leiba> Stephen: we do lots of stuff that's worth less.
[21:51:51] <Rich Salz> @sftcd most security is yelling in an empty room, no?
[21:52:00] <Barry Leiba> (Not meaning to downplay your concern.)
[21:52:03] <mcr> http://www.sandelman.ca/SSW/talks/ripe-iot-unquarantine2019/  I tried to engage ISPs at RIPE79 on how they would like home gateways to communicate with them about IoCs, and how they are, or would like to, exchange IoCs.  MISP-project, IODEF, MILE were all in context.  I would like to see something more specific about how IoCs are encoded, and in particularly, anonymized. What we have here is the introduction to an actual profile/content.
[21:52:06] <Alexey Melnikov> Barry Leiba: I need to think about MILE. I will need to read the document first before commenting
[21:52:07] <sftcd> @barry: I'm not questioning the worth, but rather the effort to get consensus
[21:52:10] secd leaves the room
[21:52:14] <mcr> (i have read the document)
[21:52:18] <Barry Leiba> Stephan: ack.
[21:52:33] <sftcd> if this goes to MILE, my bet is that everyone would just ignore it entirely, until a possible flame up @ IETF LC
[21:52:48] <mcr> well said Ben.
[21:53:02] <msk> leaning toward ISE as well, but the MILE angle is interesting
[21:53:11] <kaduk@jabber.org/barnowl> The doc does have the -00 nature, be warned
[21:53:46] <francesca> ben, roman: very split opinions on mic and in the chat
[21:53:48] m&m leaves the room: Disconnected: Replaced by new connection
[21:53:49] m&m joins the room
[21:53:52] <mcr> there might be a patent prior art reason to publish this.
[21:53:56] <sftcd> Kirsty seems to be describing an ISE doc there
[21:54:24] <msk> sftcd: yeah
[21:54:32] <Richard Barnes> @sftcd - to the mic!
[21:54:34] <synp> @mcr a draft is as good for that purpose as an RFC.  Drafts are (also) forever
[21:54:41] <Mirja> so what's about opssec?
[21:54:46] <sftcd> @rlb: MIC: my above please:-)
[21:54:54] <sftcd> I'm not in an audio-out friendly environment
[21:54:57] <Richard Barnes> @sftcd ack
[21:55:19] <sftcd> and I also hate talking to webex as well of course:-)
[21:55:47] <brong> sftcd: please formulate exactly what you want said
[21:55:55] <ekr@jabber.org> sftcd: you could use Zoom!
[21:56:08] <amontville> FWIW, this work seems useful. We're looking to update threat models and work over the past few years has seemed to start defining a security architecutre of sorts, so it seems that this work is good.
[21:56:15] <sftcd> I hate zoom and webex equally
[21:56:15] <Richard Barnes> @sftcd sorry if i paraphrased a bit there
[21:56:26] <kaduk@jabber.org/barnowl> I didn't catch who Kathleen asked if they wanted to say something
[21:56:42] <sftcd> nah that's fine I think the cost/benefit issue here is clear, even if it's unclear which is greater
[21:57:11] <ekr@jabber.org> kaduk: you and Roman!
[21:57:14] <ekr@jabber.org> back to work
[21:57:17] <Kathleen> :-)
[21:57:26] <mcr> I prefer to start with MILE.
[21:57:41] <mcr> I don't think that there will be the right people in OPSEC.
[21:57:55] carrickdb@jabber.hot-chilli.net leaves the room
[21:57:55] <amontville> MILE seems directly relevant
[21:58:12] secd joins the room
[21:58:15] <sftcd> the only benefit to the IETF here happens if/when we get the debate as to how to do IoCs in a more privacy-friendly (and TLS-friendly) manner and that won't happen inside MILE is my bet
[21:58:23] dkg joins the room
[21:58:40] <amontville> Fair point.
[21:58:40] secd leaves the room
[21:59:19] <mcr> @sftcd, I agree with you.  But at this point the document does not transport IoCs, and so MILE needs to think about how it might do that. At which point, I think that we need to get review, probably from HIPRG and ?
[21:59:46] secd joins the room
[21:59:47] <sftcd> @mcr: HIPRG? dunno 'bout that tbh
[22:00:00] Shumon Huque leaves the room
[22:00:03] martin.duke leaves the room
[22:00:10] <mcr> whomever you think can make the IoC have higher privacy-fu.
[22:00:16] Melinda leaves the room
[22:00:22] <mcr> or whatever the right way to say that is....
[22:00:34] secd leaves the room
[22:00:56] dkg leaves the room
[22:01:00] jimsch1 leaves the room
[22:01:08] <sftcd> ah, work'd be required before I could answer that :-)
[22:01:14] <mcr> is there a scotchbof?
[22:01:14] amontville leaves the room
[22:01:19] Russ Housley leaves the room
[22:01:21] Atarashi Yoshifumi leaves the room
[22:01:23] Olaf Kolkman leaves the room
[22:01:24] Jonathan Hammell leaves the room
[22:01:28] Andrew Campling leaves the room
[22:01:28] sftcd leaves the room
[22:01:29] Barry Leiba leaves the room
[22:01:29] synp leaves the room
[22:01:31] xdf leaves the room
[22:01:33] mcr leaves the room
[22:01:35] cvmiller leaves the room
[22:01:38] Stefan Santesson leaves the room
[22:01:38] Samuel Weiler leaves the room
[22:01:39] Seth Blank leaves the room
[22:01:39] msk leaves the room
[22:01:44] Mike StJohns leaves the room
[22:01:48] Ben Schwartz leaves the room
[22:01:49] wilma leaves the room
[22:01:51] carl mehner leaves the room: offline
[22:01:55] tfpauly leaves the room
[22:01:56] Valery Smyslov leaves the room
[22:02:00] Cullen Jennings leaves the room
[22:02:01] lsawyer leaves the room
[22:02:05] Cindy Morgan leaves the room
[22:02:12] adam leaves the room
[22:02:12] Yoshiro YONEYA leaves the room
[22:02:14] Mirja leaves the room
[22:02:15] wseltzer leaves the room
[22:02:19] Jim Fenton leaves the room
[22:02:21] Dan York leaves the room
[22:02:29] m&m leaves the room
[22:02:43] Jeffrey Yasskin leaves the room
[22:02:47] Rich Salz leaves the room
[22:02:54] francesca leaves the room
[22:02:56] dkg joins the room
[22:03:01] <kaduk@jabber.org/barnowl> Didn't you get the memo?  It's at your place.
[22:03:03] dee3@hot-chilli.net leaves the room
[22:03:08] xp29srs leaves the room
[22:03:08] Marco Tiloca leaves the room
[22:03:08] brong leaves the room
[22:03:43] Alexey Melnikov leaves the room
[22:04:16] np leaves the room
[22:04:34] jmagallanes leaves the room
[22:04:42] Ben Campbell leaves the room
[22:04:50] Karl leaves the room
[22:04:52] Jonathan Lennox leaves the room
[22:04:53] Martin Thomson leaves the room
[22:05:04] csperkins leaves the room
[22:05:32] dkg joins the room
[22:05:33] Ben Campbell joins the room
[22:05:39] Roman Danyliw leaves the room
[22:05:39] petereyee leaves the room
[22:05:45] Ben Campbell leaves the room
[22:06:40] sfuerst leaves the room
[22:07:48] dkg leaves the room
[22:07:48] tim costello leaves the room
[22:08:12] mnot leaves the room
[22:08:28] dkg joins the room
[22:08:37] tim costello joins the room
[22:09:22] Karl joins the room
[22:09:30] Steve Todd leaves the room
[22:10:12] Greg Wood leaves the room
[22:10:18] Karl leaves the room
[22:10:28] ssahib leaves the room
[22:11:04] dkg joins the room
[22:11:10] Alissa Cooper leaves the room
[22:11:31] Samuel Weiler joins the room
[22:13:01] Mo Zanaty leaves the room
[22:13:12] Mike Bishop leaves the room
[22:13:34] mglt leaves the room
[22:14:01] dkg joins the room
[22:14:34] spencerdawkins leaves the room
[22:14:43] ekr@jabber.org leaves the room
[22:15:48] dkg leaves the room
[22:17:18] SM leaves the room
[22:18:07] kha leaves the room
[22:18:46] Ben Campbell joins the room
[22:19:27] dkg leaves the room
[22:22:48] dkg leaves the room
[22:23:25] Mark Baushke leaves the room
[22:25:18] dkg leaves the room
[22:26:44] Richard Barnes joins the room
[22:26:48] Richard Barnes leaves the room
[22:27:48] Richard Barnes leaves the room
[22:28:13] merm leaves the room
[22:28:18] dkg leaves the room
[22:28:24] Pete Resnick leaves the room
[22:29:37] Richard Barnes joins the room
[22:30:48] dkg leaves the room
[22:30:54] Richard Barnes leaves the room
[22:33:56] dkg joins the room
[22:44:28] kiran.ietf leaves the room
[22:47:55] Ben Campbell leaves the room
[22:53:15] Ben Campbell joins the room
[22:54:06] caw leaves the room
[22:58:35] Mark Baushke joins the room
[23:00:46] Ben Campbell leaves the room
[23:25:00] dkg joins the room
[23:38:06] tim costello leaves the room
[23:38:52] tim costello joins the room
[23:39:18] dkg leaves the room
[23:45:11] tim costello leaves the room
[23:49:47] Samuel Weiler leaves the room
[23:50:06] kiran.ietf joins the room
[23:51:52] Peter Wu leaves the room: Disconnected: BOSH client silent for over 60 seconds
[23:53:18] cabo leaves the room
[23:56:04] cabo joins the room
[23:56:18] cabo leaves the room