[{"author": "Kathleen Moriarty", "text": "

Good morning!

", "time": "2023-03-27T08:30:12Z"}, {"author": "Sean Turner", "text": "

cheers!

", "time": "2023-03-27T08:31:33Z"}, {"author": "Jim Fenton", "text": "

Why does Meetecho seem to think that Rifaat is remote?

", "time": "2023-03-27T08:31:50Z"}, {"author": "Jonathan Lennox", "text": "

Probably logged in to the full client

", "time": "2023-03-27T08:32:15Z"}, {"author": "Rich Salz", "text": "

Hi Max, Robert!

", "time": "2023-03-27T08:33:09Z"}, {"author": "Yoav Nir", "text": "

I'm logged in to the full client and it doesn't think that I'm remote.

", "time": "2023-03-27T08:34:15Z"}, {"author": "Ted Hardie", "text": "

Chairs, have the slides for this been presentation re-uploaded, to be linked in the minutes?

", "time": "2023-03-27T08:36:02Z"}, {"author": "Jonathan Hoyland", "text": "

What is the security property that you get from this status signal? Isn't it equivalent to \"unencrypted\"?

", "time": "2023-03-27T08:37:53Z"}, {"author": "Kathleen Moriarty", "text": "

Order was shuffled to accommodate a possible flight delay.

", "time": "2023-03-27T08:37:57Z"}, {"author": "Michael Richardson", "text": "

@Jonathan, yeah, I think that it's the same as unencrypted, but the content arrived encrypted, (signed), and if you unicast replied, you could encrypt.

", "time": "2023-03-27T08:39:02Z"}, {"author": "Kathleen Moriarty", "text": "

@Ted It appears only drafts are listed in the tar file and the PDF download.

", "time": "2023-03-27T08:39:54Z"}, {"author": "Deb Cooley", "text": "

reply all is problematic in S/MIME if the person replying doesn't have all the keys.

", "time": "2023-03-27T08:39:59Z"}, {"author": "Deb Cooley", "text": "

sometimes... usually, in my experience.

", "time": "2023-03-27T08:40:24Z"}, {"author": "Benjamin Beurdouche", "text": "

should we provide a reference to the public keys of the recipients in that header?

", "time": "2023-03-27T08:41:09Z"}, {"author": "Yoav Nir", "text": "

The important part about an \"encrypted\" indication is not that it was sent secure over this pipe where I got the message, but the idea that there's no cleartext version going around.

\n

99 encrypted versions and 1 unencrypted version = unencrypted

", "time": "2023-03-27T08:41:14Z"}, {"author": "Deb Cooley", "text": "

but the sender can send an unencrypted copy at a later time.

", "time": "2023-03-27T08:41:53Z"}, {"author": "Michael Richardson", "text": "

For the person receiving the encrypted message, there is much less traffic analysis on them.

", "time": "2023-03-27T08:42:00Z"}, {"author": "Robert Moskowitz", "text": "

Unencrypted internally and encrypted externally? I have seen such proposals.

", "time": "2023-03-27T08:42:33Z"}, {"author": "Kathleen Moriarty", "text": "

@Deb yes and sensitivity may have changed.

", "time": "2023-03-27T08:42:35Z"}, {"author": "Yoav Nir", "text": "

\"Don't do it\". So what do you do instead? Send it in the clear to everybody? Because the alternative is to make \"reply-all\" not work.

", "time": "2023-03-27T08:43:00Z"}, {"author": "Ted Hardie", "text": "

@Kathleen I also don't find this in the slides section of the tool.

", "time": "2023-03-27T08:43:20Z"}, {"author": "Deb Cooley", "text": "

'send it in the clear' is usually the answer

", "time": "2023-03-27T08:43:25Z"}, {"author": "Yoav Nir", "text": "

@Bob Moskowitz: I don't think that internal vs external is still well-defined enough.

", "time": "2023-03-27T08:43:38Z"}, {"author": "Deb Cooley", "text": "

or ask all the recipients for signed messages.

", "time": "2023-03-27T08:43:39Z"}, {"author": "Deb Cooley", "text": "

but then mail lists....

", "time": "2023-03-27T08:43:49Z"}, {"author": "Robert Moskowitz", "text": "

@Yoav: that is for sure. All cloudy as is typical of email.

", "time": "2023-03-27T08:44:47Z"}, {"author": "Kathleen Moriarty", "text": "

I think it would be good to have better answers as we are not going to change users. If there was an opportunistic encryption backup, that would be better than plaintext.

", "time": "2023-03-27T08:44:56Z"}, {"author": "Michael Richardson", "text": "

yeah, do a BOF.

", "time": "2023-03-27T08:44:58Z"}, {"author": "Kathleen Moriarty", "text": "

no hat, a BoF seems like a good choice

", "time": "2023-03-27T08:45:26Z"}, {"author": "Robert Moskowitz", "text": "

How to change basically bad behavior amongst agents. Be they software or people.

", "time": "2023-03-27T08:46:16Z"}, {"author": "Massimiliano Pala", "text": "

@yoav, it might be the best solution - the encrypted+unencrypted is quite scary in that it gives a false sense of some kind of security... a hard problem to even define with many different components (human behavior, UI, protocol, signal, ... ?)

", "time": "2023-03-27T08:46:35Z"}, {"author": "Martin Thomson", "text": "

The \"L\" stands for \"lies\"

", "time": "2023-03-27T08:47:07Z"}, {"author": "Murray Kucherawy", "text": "

We talked about chartering an email maintenance working group, but haven't done it.

", "time": "2023-03-27T08:47:08Z"}, {"author": "Jonathan Lennox", "text": "

If you're not defining an S/MIMEbis, it's limited...

", "time": "2023-03-27T08:47:10Z"}, {"author": "Pete Resnick", "text": "

FWIW: I wouldn't throw a fit if it ended up in LAMPS

", "time": "2023-03-27T08:47:37Z"}, {"author": "Stephen Farrell", "text": "

is the plan for dkg's thing that one message is sent by the MUA or two? (i.e. one in clear and one encrypted)

", "time": "2023-03-27T08:48:01Z"}, {"author": "Murray Kucherawy", "text": "

EMAILCORE is not an option, its charter is too tight.

", "time": "2023-03-27T08:48:05Z"}, {"author": "Richard Barnes", "text": "

AMPS! :guitar::loud_sound:

", "time": "2023-03-27T08:48:10Z"}, {"author": "Massimiliano Pala", "text": "

AMPS indeed! (\"L\" is silent... brilliant!)

", "time": "2023-03-27T08:48:40Z"}, {"author": "Deb Cooley", "text": "

that changes the answer

", "time": "2023-03-27T08:48:43Z"}, {"author": "Deb Cooley", "text": "

if we don't want people to do this, then....

", "time": "2023-03-27T08:49:01Z"}, {"author": "Andrew Campling", "text": "

A BoF seems a good way forward to bottom this out some more

", "time": "2023-03-27T08:50:16Z"}, {"author": "Murray Kucherawy", "text": "

I wish I'd seen this earlier, we could've talked about it in DISPATCH this morning maybe.

", "time": "2023-03-27T08:50:52Z"}, {"author": "Jim Fenton", "text": "

Wondering how we would put an email header field inside the encryption envelope, unless we put it in an email MIME part.

", "time": "2023-03-27T08:50:52Z"}, {"author": "John Preu\u00df Mattsson", "text": "

We can reuse the evil bit (RFC 3514)

", "time": "2023-03-27T08:51:15Z"}, {"author": "Rich Salz", "text": "

You could have \"Sec-Warning: foo@example.com got a plaintext copy\" in the encrypted part.

", "time": "2023-03-27T08:51:46Z"}, {"author": "Murray Kucherawy", "text": "

Mic line is closed; I was going to suggest proposing the idea to the ietf-822 list.

", "time": "2023-03-27T08:51:49Z"}, {"author": "Pete Resnick", "text": "

@Murray Kucherawy +1

", "time": "2023-03-27T08:52:27Z"}, {"author": "Jonathan Lennox", "text": "

What happens if you Bcc in the clear?

", "time": "2023-03-27T08:52:34Z"}, {"author": "Stephen Farrell", "text": "

BoF or setup a mailing list seems a good outcome

", "time": "2023-03-27T08:52:51Z"}, {"author": "Richard Barnes", "text": "

but will the mailing list be encrypted or not?

", "time": "2023-03-27T08:53:55Z"}, {"author": "Rich Salz", "text": "

It sure would be nice if DKG came up with easy problems sometimes.

", "time": "2023-03-27T08:54:16Z"}, {"author": "Yoav Nir", "text": "

Only to those of us who have keys

", "time": "2023-03-27T08:54:17Z"}, {"author": "Daniel Huigens", "text": "

We can't end-to-end encrypt to a mailing list, so a copy to a mailing list will be unencrypted

", "time": "2023-03-27T08:55:02Z"}, {"author": "Daniel Huigens", "text": "

We still encrypt the other copies because we don't special-case mailing lists, we assume it might be a recipient that trusts their mail server

", "time": "2023-03-27T08:55:31Z"}, {"author": "Deb Cooley", "text": "

Why not set up a mailing list that can be encrypted to?

", "time": "2023-03-27T08:55:54Z"}, {"author": "Deb Cooley", "text": "

Or do you not control the list?

", "time": "2023-03-27T08:56:02Z"}, {"author": "Rich Salz", "text": "

How do you know a recipient is a mailing list?

", "time": "2023-03-27T08:56:15Z"}, {"author": "Daniel Huigens", "text": "

dkg's example was sending to an IETF mailing list, so that is a question for the rest of the IETF :)

", "time": "2023-03-27T08:56:31Z"}, {"author": "Benjamin Schwartz", "text": "

Does PGP authenticate the Cc: header?

", "time": "2023-03-27T08:56:39Z"}, {"author": "Daniel Gillmor", "text": "

ahoy ahoy
\nJim Fenton said:

\n
\n

Wondering how we would put an email header field inside the encryption envelope, unless we put it in an email MIME part.

\n
\n

Jim, see draft-ietf-lamps-header-protection -- hopefully going into WGLC this week.

", "time": "2023-03-27T08:57:01Z"}, {"author": "Rich Salz", "text": "

@Daniel, you said \"we still encrypt...\" and I thought you were referring to how protonmail works.

", "time": "2023-03-27T08:57:12Z"}, {"author": "Daniel Huigens", "text": "

Yes, indeed

", "time": "2023-03-27T08:57:19Z"}, {"author": "Yoav Nir", "text": "

@Rich: You don't, but when the server re-distributes it, it should send DKG's proposed indication

", "time": "2023-03-27T08:57:27Z"}, {"author": "Daniel Huigens", "text": "

We encrypt copies to recipients that we have a key for, and not for recipients that we don't have a key for

", "time": "2023-03-27T08:57:36Z"}, {"author": "Daniel Huigens", "text": "

dkg's proposal is that we indicate in the encrypted copies that an unencrypted copy was also sent

", "time": "2023-03-27T08:58:25Z"}, {"author": "Michael Richardson", "text": "

over in madinas (now), we talk about having a new identifier replacing MAC address for stuff like L2VPN.... so maybe that's an interesting other dispatch choice.

", "time": "2023-03-27T08:59:06Z"}, {"author": "Daniel Gillmor", "text": "

Benjamin Schwartz said:

\n
\n

Does PGP authenticate the Cc: header?

\n
\n

@Benjamin Schwartz if it uses draft-ietf-lamps-header-protection it will. that specification works just as well for PGP/MIME as it does for S/MIME.

", "time": "2023-03-27T08:59:41Z"}, {"author": "Yoav Nir", "text": "

\"With good encryption and key management, secures plaintext so it cannot be recovered without the key\"

\n

With mediocre encryption and key management, it's still better than nothing.

", "time": "2023-03-27T08:59:51Z"}, {"author": "Benjamin Schwartz", "text": "

dkg: It seems like the threat model for reply-all is totally undefined ... and really you want to bundle the key fingerprints of all recipients into each message.

", "time": "2023-03-27T09:02:13Z"}, {"author": "Benjamin Schwartz", "text": "

That way I can be sure that I'm really sending my reply to the same recipients as the original message.

", "time": "2023-03-27T09:03:00Z"}, {"author": "Richard Barnes", "text": "

is any of this not obvious?

", "time": "2023-03-27T09:03:07Z"}, {"author": "Jonathan Lennox", "text": "

I think the point is it's obvious to security folks but not necessarily to others, so it'd be good to haver it written down.

", "time": "2023-03-27T09:03:42Z"}, {"author": "Robert Moskowitz", "text": "

But obvious still needs to be written down. So we just don't do the same thing over and over again..

", "time": "2023-03-27T09:03:47Z"}, {"author": "Richard Barnes", "text": "

it's not like routing people pay attention to security considerations anyway. how many routing docs did i review while i was on the IESG that had like \"Security Considerations: lol #YOLO\"

", "time": "2023-03-27T09:05:04Z"}, {"author": "Warren Kumari", "text": "

Seems more like int or ops?

", "time": "2023-03-27T09:05:21Z"}, {"author": "Richard Barnes", "text": "

but maybe being awake at 5am has my cynicism showing :)

", "time": "2023-03-27T09:05:30Z"}, {"author": "Warren Kumari", "text": "

Or transport -- much of this is things like encapsulation.

", "time": "2023-03-27T09:06:49Z"}, {"author": "Sean Turner", "text": "

@Richard I think I still have lots of scars ....

", "time": "2023-03-27T09:07:03Z"}, {"author": "Kathleen Moriarty", "text": "

Similar to a YANG Security Considerations template in it's use...

", "time": "2023-03-27T09:07:04Z"}, {"author": "Stephen Farrell", "text": "

so this is intended to bless routing drafts adding identifiers?

", "time": "2023-03-27T09:07:08Z"}, {"author": "Eric Rescorla", "text": "

Maybe it could go in ART

", "time": "2023-03-27T09:07:27Z"}, {"author": "Warren Kumari", "text": "

e.g VLAN headers, GRE, etc.

", "time": "2023-03-27T09:08:00Z"}, {"author": "Warren Kumari", "text": "

GEN FTW!

", "time": "2023-03-27T09:08:09Z"}, {"author": "Richard Barnes", "text": "

send it to DISPATCH-DISPATCH to figure out which DISPATCH to go to

", "time": "2023-03-27T09:08:53Z"}, {"author": "Robert Moskowitz", "text": "

Now what I stayed up for...

", "time": "2023-03-27T09:09:18Z"}, {"author": "Richard Barnes", "text": "

Dispatch to ITU-T

", "time": "2023-03-27T09:09:36Z"}, {"author": "Robert Moskowitz", "text": "

Direct impact to aviation planned PKI in this week's meetings at ICAO.

", "time": "2023-03-27T09:10:09Z"}, {"author": "Jim Fenton", "text": "

Names of colors: Sounds like a bikeshedding issue

", "time": "2023-03-27T09:10:54Z"}, {"author": "Stephen Farrell", "text": "

wouldn't a better update be to say \"never use any of that policy stuff\"?

", "time": "2023-03-27T09:11:06Z"}, {"author": "Deb Cooley", "text": "

^^^^^

", "time": "2023-03-27T09:11:18Z"}, {"author": "Alex Chernyakhovsky", "text": "

That is a valid update to 5280

", "time": "2023-03-27T09:11:33Z"}, {"author": "Robert Moskowitz", "text": "

Nope. We have state-level politics so this is a real reality I will have to deal with.

", "time": "2023-03-27T09:11:42Z"}, {"author": "Deb Cooley", "text": "

but NOBODY can actually do it.

", "time": "2023-03-27T09:12:07Z"}, {"author": "Richard Barnes", "text": "

not often we get EXPSPACE problems in IETF!

", "time": "2023-03-27T09:12:42Z"}, {"author": "Stephen Farrell", "text": "

how many certificates are currently valid that use any policy mappings? I'd have thought it was zero

", "time": "2023-03-27T09:12:43Z"}, {"author": "Andrew Campling", "text": "

Turtles all the way down \u2026.

", "time": "2023-03-27T09:12:51Z"}, {"author": "Robert Moskowitz", "text": "

Tell that to country foo and their opinion of country bar.

", "time": "2023-03-27T09:12:53Z"}, {"author": "Deb Cooley", "text": "

yeah, we have them.

", "time": "2023-03-27T09:13:01Z"}, {"author": "Deb Cooley", "text": "

(I hate it)

", "time": "2023-03-27T09:13:16Z"}, {"author": "Jonathan Hoyland", "text": "

I mean PMRS reachability is k-EXPSPACE, so it could be worse.

", "time": "2023-03-27T09:13:23Z"}, {"author": "Robert Moskowitz", "text": "

\"Big\" plans in trials I have had to listen to.

", "time": "2023-03-27T09:13:25Z"}, {"author": "Stephen Farrell", "text": "

@debso you'd like to stop

", "time": "2023-03-27T09:13:33Z"}, {"author": "Deb Cooley", "text": "

indeed

", "time": "2023-03-27T09:13:44Z"}, {"author": "Deb Cooley", "text": "

but who listens to me?

", "time": "2023-03-27T09:13:50Z"}, {"author": "Deb Cooley", "text": "

(nobody)

", "time": "2023-03-27T09:13:58Z"}, {"author": "Robert Moskowitz", "text": "

We listen, but can we act on it?

", "time": "2023-03-27T09:14:09Z"}, {"author": "Jim Fenton", "text": "

Seems that policies used to enforce key escrow for encryption but not for signatures are pretty common

", "time": "2023-03-27T09:14:11Z"}, {"author": "Deb Cooley", "text": "

eh???

", "time": "2023-03-27T09:14:25Z"}, {"author": "Jim Fenton", "text": "

Never mind, I'm babbling.

", "time": "2023-03-27T09:14:45Z"}, {"author": "Robert Moskowitz", "text": "

Been there done that from you, but others say we will do better! Not.

", "time": "2023-03-27T09:15:01Z"}, {"author": "Benjamin Schwartz", "text": "

Dispatch to RFC Editor

", "time": "2023-03-27T09:15:24Z"}, {"author": "Deb Cooley", "text": "

to get rid of this, you'd have to open RFC5280

", "time": "2023-03-27T09:15:49Z"}, {"author": "Richard Barnes", "text": "

seems like LAMPS is the obvious choice

", "time": "2023-03-27T09:15:50Z"}, {"author": "Robert Moskowitz", "text": "

Aviation SWIM will have to use this.

", "time": "2023-03-27T09:15:59Z"}, {"author": "Massimiliano Pala", "text": "

AMPS?!?

", "time": "2023-03-27T09:16:26Z"}, {"author": "Richard Barnes", "text": "

sorry, yes AMPS

", "time": "2023-03-27T09:16:37Z"}, {"author": "Robert Moskowitz", "text": "

Flight manifests for aircraft from airlines foo flying into airspace bar.

", "time": "2023-03-27T09:16:47Z"}, {"author": "Massimiliano Pala", "text": "

:rolling_on_the_floor_laughing:

", "time": "2023-03-27T09:16:51Z"}, {"author": "Richard Barnes", "text": "

Policy Mappings Considered Harmful

", "time": "2023-03-27T09:17:36Z"}, {"author": "Stephen Farrell", "text": "

policy mappings and make life better don't go together

", "time": "2023-03-27T09:17:45Z"}, {"author": "Sean Turner", "text": "

:)

", "time": "2023-03-27T09:18:20Z"}, {"author": "Richard Barnes", "text": "

ARE YOU KNOW OR HAVE YOU EVER BEEN A MEMBER OF AN ORGANIZATION THAT USED POLICY MAPPINGS

", "time": "2023-03-27T09:18:43Z"}, {"author": "Robert Moskowitz", "text": "

I will see it in spades this week...

", "time": "2023-03-27T09:19:00Z"}, {"author": "Deb Cooley", "text": "

@barnes sadly yes

", "time": "2023-03-27T09:19:27Z"}, {"author": "Jonathan Hoyland", "text": "

So you'd go for policy-mappings-die-die-die?

", "time": "2023-03-27T09:19:40Z"}, {"author": "Robert Moskowitz", "text": "

Yes. to a pki that SHOULD do this.,

", "time": "2023-03-27T09:19:49Z"}, {"author": "Deb Cooley", "text": "

LOLOL, cluster

", "time": "2023-03-27T09:20:18Z"}, {"author": "Sean Turner", "text": "

@Jonathan Hoyland some of that is done by the CABF

", "time": "2023-03-27T09:20:39Z"}, {"author": "Robert Moskowitz", "text": "

LAMPS is good.

", "time": "2023-03-27T09:20:40Z"}, {"author": "Rich Salz", "text": "

WebPKI is not the only PKI.

", "time": "2023-03-27T09:21:01Z"}, {"author": "Robert Moskowitz", "text": "

Well this is what I stay up for, but my alarm is for in 40min. :(

", "time": "2023-03-27T09:21:17Z"}, {"author": "Jonathan Hoyland", "text": "

I'd just stay up at that point

", "time": "2023-03-27T09:21:39Z"}, {"author": "Rich Salz", "text": "

Since Robert says aircraft use it, I am not worried about planes falling out of the sky because of policy-validation expontential resource consumption. :)

", "time": "2023-03-27T09:22:03Z"}, {"author": "Robert Moskowitz", "text": "

I have a draft that needs writing.

", "time": "2023-03-27T09:22:16Z"}, {"author": "Rich Salz", "text": "

(Or rather, that they will use it)

", "time": "2023-03-27T09:22:22Z"}, {"author": "Daniel Gillmor", "text": "

@Rich Salz you are now worried, or not worried?

", "time": "2023-03-27T09:22:43Z"}, {"author": "Robert Moskowitz", "text": "

@Rich, this is SUPPOSE to be before start of flight. But how to deal with flight changes? RIght now ignore the digital path and use voice.

", "time": "2023-03-27T09:23:05Z"}, {"author": "Rich Salz", "text": "

@DKG: I'm not telling you my threat model :)

", "time": "2023-03-27T09:23:26Z"}, {"author": "Rich Salz", "text": "

At least not over this plaintext channel.

", "time": "2023-03-27T09:23:39Z"}, {"author": "Richard Barnes", "text": "

i read this draft, there didn't seem to be any actual protocol mechanism in it

", "time": "2023-03-27T09:23:42Z"}, {"author": "Robert Moskowitz", "text": "

No protocol. Just a change in the algorithm for tree building. I like it.

", "time": "2023-03-27T09:24:11Z"}, {"author": "Ted Hardie", "text": "

@Chairs did I hear correctly that there are new slides for this one? Link please, if so.

", "time": "2023-03-27T09:24:13Z"}, {"author": "Stephen Farrell", "text": "

I scanned the two drafts for this item: not enough information to dispatch

", "time": "2023-03-27T09:24:43Z"}, {"author": "Alex Chernyakhovsky", "text": "

I spent a bunch of time reading 5280 and @David Benjamin's proposal, and it has the nice side-effect of making everything a lot easier to understand

", "time": "2023-03-27T09:24:49Z"}, {"author": "Daniel Gillmor", "text": "

does \"user requirements for ISP\" mean \"the ISP as a user of network equipment\" or \"users of the ISP\"?

", "time": "2023-03-27T09:24:50Z"}, {"author": "Richard Barnes", "text": "

this does not seem dispatch-ready

", "time": "2023-03-27T09:25:05Z"}, {"author": "Robert Moskowitz", "text": "

Well I am signing off. Can't listen and write a draft. See you all in 15 hours.

", "time": "2023-03-27T09:25:15Z"}, {"author": "Richard Barnes", "text": "

also, didn't we have a whole SFC working group on this?

", "time": "2023-03-27T09:25:44Z"}, {"author": "David Benjamin", "text": "

It's still harder to understand than I'd like, but when I tried to come up with a simpler algorithm, I failed. :-( There are some really weird corner cases around anyPolicy. TBH, I think those corner cases are wrong, but they're codified in the spec and NIST PKITS now, so it is what it is.

", "time": "2023-03-27T09:26:11Z"}, {"author": "David Benjamin", "text": "

You can actually construct a cert path that, when you add a constraint, the result it is valid for more policies than before it was constrained.

", "time": "2023-03-27T09:27:17Z"}, {"author": "Daniel Gillmor", "text": "

@David Benjamin i'd be interested in reading a draft that describes what you think is wrong with anyPolicy. I'm not convinced that anyone who initially specified this stuff thought about it deeply.

", "time": "2023-03-27T09:27:19Z"}, {"author": "Massimiliano Pala", "text": "

Thank you!

", "time": "2023-03-27T09:28:22Z"}, {"author": "Massimiliano Pala", "text": "

... and good night :D

", "time": "2023-03-27T09:28:33Z"}]