[{"author": "Robert Moskowitz", "text": "

End of week. It is tired of being clicked.

", "time": "2025-03-21T02:30:15Z"}, {"author": "Yoav Nir", "text": "

Aren't we all?

", "time": "2025-03-21T02:31:13Z"}, {"author": "Alicja Kario", "text": "

:tada:

", "time": "2025-03-21T02:32:49Z"}, {"author": "Thom Wiggers", "text": "

<joke in the room: did you say \"drop c or drop seed\">

", "time": "2025-03-21T02:35:25Z"}, {"author": "Alicja Kario", "text": "

big issue is that in DNSSEC use of SHA-1 is considered acceptable...

", "time": "2025-03-21T02:42:05Z"}, {"author": "Alicja Kario", "text": "

and they really don't have a story of post-quantum

", "time": "2025-03-21T02:42:44Z"}, {"author": "Alicja Kario", "text": "

s/of/for/

", "time": "2025-03-21T02:42:56Z"}, {"author": "Thom Wiggers", "text": "

SHA-1 is not great, but it's not catastrophic because in this case you only care about second preimage which AFAIK is still fine?

", "time": "2025-03-21T02:44:50Z"}, {"author": "Michael StJohns", "text": "

did he say \"critical\" bit referring to the CAA tag? or am I conflating DNS stuff with certificate extension stuff..

", "time": "2025-03-21T02:44:54Z"}, {"author": "Tim Hollebeek", "text": "

CAA has it's own definition of critical

", "time": "2025-03-21T02:45:25Z"}, {"author": "Tim Hollebeek", "text": "

It's about what you'd expect

", "time": "2025-03-21T02:45:29Z"}, {"author": "Jonathan Hammell", "text": "

There are efforts to incorporate post-quantum algorithms in DNSSEC. There was a side-meeting on Tuesday. https://wiki.ietf.org/en/group/pq-dnssec

", "time": "2025-03-21T02:46:24Z"}, {"author": "Michael StJohns", "text": "

@tim - thanks...

", "time": "2025-03-21T02:48:11Z"}, {"author": "Alicja Kario", "text": "

@Thom sorry, but delaying migration off of insecure algorithms until there are practical wide-scale attacks against a protocol is not what I expect of _security_ protocols

", "time": "2025-03-21T02:52:50Z"}, {"author": "Jonathan Hammell", "text": "

https://datatracker.ietf.org/doc/draft-ietf-dnsop-must-not-sha1/

", "time": "2025-03-21T02:54:03Z"}, {"author": "Tim Hollebeek", "text": "

\"Existing certificate\" previously existed in the BRs, and was removed

", "time": "2025-03-21T02:54:36Z"}, {"author": "Tim Hollebeek", "text": "

It was also IPR constrained IIRC

", "time": "2025-03-21T02:54:59Z"}, {"author": "Thom Wiggers", "text": "

@Alicja Kario I didn't say that it was fine, I said it was not catastrophic. There are many valid complaints to be raised at DNSSEC, such as its lack of use or its fragility

", "time": "2025-03-21T02:55:30Z"}, {"author": "Mike Ounsworth", "text": "

Tim Hollebeek said:

\n
\n

\"Existing certificate\" previously existed in the BRs, and was removed

\n
\n

Bring this to the mic please.

", "time": "2025-03-21T02:55:36Z"}, {"author": "Jonathan Hammell", "text": "

Jonathan Hammell said:

\n
\n

https://datatracker.ietf.org/doc/draft-ietf-dnsop-must-not-sha1/

\n
\n

\"Deprecating the use of SHA-1 in DNSSEC signature algorithms\"

", "time": "2025-03-21T02:56:19Z"}, {"author": "Alicja Kario", "text": "

browsers stopped accepting SHA-1 in certificates in 2017... proposing removal of SHA-1 in 2024 in DNSSEC is late...

", "time": "2025-03-21T02:56:47Z"}, {"author": "Tim Hollebeek", "text": "

And 2017 was already late

", "time": "2025-03-21T02:57:17Z"}, {"author": "Alicja Kario", "text": "

@Tim: precisely

", "time": "2025-03-21T02:57:29Z"}, {"author": "Jonathan Hammell", "text": "

DNSSEC being late? /s

", "time": "2025-03-21T02:57:30Z"}, {"author": "Robert Moskowitz", "text": "

Oh course, SKI is SHA-1 in almost all CA products?

", "time": "2025-03-21T02:57:50Z"}, {"author": "Tim Hollebeek", "text": "

SKI isn't security critical

", "time": "2025-03-21T02:59:10Z"}, {"author": "Tim Hollebeek", "text": "

(this question comes up a lot)

", "time": "2025-03-21T02:59:18Z"}, {"author": "Robert Moskowitz", "text": "

Fortunately. But I am dealing with a group that is crying about their cert size and won't use shake128 for SKI because their CA software won't do that .

", "time": "2025-03-21T03:00:22Z"}, {"author": "Robert Moskowitz", "text": "

got to love this stuff.

", "time": "2025-03-21T03:00:27Z"}, {"author": "Russ Housley", "text": "

SKI/AKI are names, and they help with path building and CMS identifying the proper cert

", "time": "2025-03-21T03:00:30Z"}, {"author": "Alicja Kario", "text": "

SKI is a hint to optimise path building, not a security link

", "time": "2025-03-21T03:01:03Z"}, {"author": "Bob Beck", "text": "

Anything involving keeping DNS up to sync is always entertaining

", "time": "2025-03-21T03:01:05Z"}, {"author": "Robert Moskowitz", "text": "

@Russ, exactly. Understand. Customer understands.

", "time": "2025-03-21T03:01:10Z"}, {"author": "Robert Moskowitz", "text": "

Still it stops removing SHA1 from the code base. :)

", "time": "2025-03-21T03:01:41Z"}, {"author": "Alicja Kario", "text": "

no, you can put CRC32 in SKI and it will work just fine

", "time": "2025-03-21T03:02:01Z"}, {"author": "Russ Housley", "text": "

Why? Use SHA-256 and truncate is needed

", "time": "2025-03-21T03:02:33Z"}, {"author": "Robert Moskowitz", "text": "

You can put a seqnum and it works fine. I do all sorts of things. The customer lacks some mental flexibility. :)

", "time": "2025-03-21T03:02:55Z"}, {"author": "Tim Hollebeek", "text": "

I'm actually somewhat sympathetic to these discussions, given the amount of time in my life has been spent explaining why non-security critical usages of SHA-1 are still there. It is an improvement to remove them when we can. But we can't always.

", "time": "2025-03-21T03:02:56Z"}, {"author": "Corey Bonnell", "text": "

Last year, Let\u2019s Encrypt switched to method 1 of RFC 7093 to dump SHA-1 in favor of a truncated SHA-256 hash

", "time": "2025-03-21T03:03:28Z"}, {"author": "Robert Moskowitz", "text": "

Yea them.

", "time": "2025-03-21T03:03:44Z"}, {"author": "Robert Moskowitz", "text": "

Actually only the CA software needs to know how it is generated. Clients are dumb about this. this helps in the discussions when we are putting code into little receivers.

", "time": "2025-03-21T03:04:50Z"}, {"author": "Corey Bonnell", "text": "

AFAIK nothing broke as a result. Which makes sense, because the SKI is supposed to be an opaque value

", "time": "2025-03-21T03:04:55Z"}, {"author": "Alicja Kario", "text": "

yes, and it's not even required to be unique for a given CA

", "time": "2025-03-21T03:05:30Z"}, {"author": "Robert Moskowitz", "text": "

@Corey. Yes. But get the customer to yell at their CA provider for a smaller SKI/AKI. Fun conversation!

", "time": "2025-03-21T03:05:40Z"}, {"author": "Tim Hudson", "text": "

Now that was refreshingly straight forward and simple to follow!

", "time": "2025-03-21T03:08:53Z"}, {"author": "Alicja Kario", "text": "

but to go to the point: if you want to use DNSSEC for actual _security_ you need to define plenty of stuff that you are not OK that the DNSSEC is at this moment OK with

\n

which I find rather horrible way to do protocols

", "time": "2025-03-21T03:09:10Z"}, {"author": "Robert Moskowitz", "text": "

Got to love how diverse our consumers of this stuff is. \"Oh, but wait, this groups does it this way!\" I am always amazed about how creative people are and assumptions that result.

", "time": "2025-03-21T03:14:44Z"}, {"author": "Tadahiko Ito", "text": "

I was thinking how to migrate security policy of security tag. it would be easier if we come up with fixed specification we do not need to change, but we might update that specification.

", "time": "2025-03-21T03:17:55Z"}, {"author": "Rich Salz", "text": "

I like the idea of adding a \"used for\", similar to how HTML link relations identify why/what the link is pointing to.

", "time": "2025-03-21T03:18:31Z"}, {"author": "Bob Beck", "text": "

Can I put purposes to make your email client chase a new one perpetually?

", "time": "2025-03-21T03:22:29Z"}, {"author": "Corey Bonnell", "text": "

The descriptor is an access method in the subject information attributes extension, so you can have multiple

", "time": "2025-03-21T03:22:38Z"}, {"author": "Bob Beck", "text": "

I.E. I make certs that force the client to make a loop of fetching

", "time": "2025-03-21T03:23:04Z"}, {"author": "Robert Moskowitz", "text": "

Of course you can.

", "time": "2025-03-21T03:23:16Z"}, {"author": "Bob Beck", "text": "

possibly across multiple CA's so they don't individualy know I am being a jerkface

", "time": "2025-03-21T03:23:19Z"}, {"author": "Robert Moskowitz", "text": "

The clients have to be smart enough to track for looping.

", "time": "2025-03-21T03:23:39Z"}, {"author": "Orie Steele", "text": "

purpose-> while(true){ fork()}

", "time": "2025-03-21T03:23:47Z"}, {"author": "Bob Beck", "text": "

while with a client it's mildly annoying, if anyone made use of this in something vaguely server like it is potentially a lot more annoying

", "time": "2025-03-21T03:24:26Z"}, {"author": "Bob Beck", "text": "

perhaps this should be dealt with somehow in htere

", "time": "2025-03-21T03:24:34Z"}, {"author": "Robert Moskowitz", "text": "

Or clients limit to how long of a chain they will process.

", "time": "2025-03-21T03:24:39Z"}, {"author": "Tim Hollebeek", "text": "

@Orie please don't post code I accidentally wrote in college

", "time": "2025-03-21T03:24:45Z"}, {"author": "Orie Steele", "text": "

XD

", "time": "2025-03-21T03:24:54Z"}, {"author": "Robert Moskowitz", "text": "

@Bob, kind of like some examples of X.500 chasing its tail and why we killed that in LDAP.

", "time": "2025-03-21T03:25:49Z"}, {"author": "Robert Moskowitz", "text": "

Yea Russ!

", "time": "2025-03-21T03:26:56Z"}]