Subject: Re: [DNSOP] Call for Adoption draft-wouters-sury-dnsop-algorithm-update

From: Roy Arends <[email-masked]>
Date: Wed, 1 Mar 2017 14:30:06 +0000

> On 1 Mar 2017, at 01:56, Paul Wouters <[email-masked]> wrote:
> 
> On Tue, 28 Feb 2017, Roy Arends wrote:
> 
>>> We can't stuff PDF prefixes into this,
>> 
>> We don’t need to.
>> 
>>> there are a lot less bytes
>>> for an attacker to play with.
>> 
>> A CNAME chain will give you plenty of bytes to futz with.
> 
> None of the SHA1 hases we use are covering a chain of records.

The point is not the chain itself, but the right hand side of the first CNAME in a chain. Make it long enough and you’ll have enough bits.

An attacker needs two successive 512 bit blocks and a prefix. 

However, you _do_ hash a chain of records. Forget CNAME, take a DNSKEY RRset with a few DNSKEY records in it. A fake 1024 bit key aligned just right will do the trick. 

All in all. The assumption that there are a lot less bytes for an attacker to play with is incorrect. 

> 
>>>> Please also refrain from using MUST- SHOULD+ and SHOULD-.
>>> For this SHA1 case or in general?
>> 
>> In general.
> 
> I disagree then. Did you read the motivation of why we use
> those terms to clarify that we expect an algorithm to be
> promoted or demoted in a future update?

Yes. I've read it. It is silly.

I expect any algorithm to be demoted in a future update. 
I expect any algorithm to be promoted in a future update.
I expect world peace too. And a pony!

I understand that you want to reflect, at the time of writing, the expectation that in the future some algorithms are king, some algorithms were king and some algorithms will be king. 

However, the only thing you _can_ state is what you know at the time of writing: some algorithms are king, SHA1 algorithms were king. Anything else is guesswork.

Why don’t you leave these future predictions to a future update.

> 
>>> I'd say we could update the DNSSEC
>>> Signing entry from MUST- to SHOULD NOT
>> 
>> Good. That is exactly my request.
> 
> This is still only meaningful if the signer software vendors
> in general agree with this. If they will just ignore this
> document, then I feel there isn't much point in proceeding
> with it.

Vendors are on this list and usually fairly vocal. I welcome their input. 

> 
>>> but I would leave SHA1 for
>>> DNSSEC validation at MUST-.
>> 
>> I’d say you have to update that as well to SHOULD NOT.
> 
> That is just unreasonable. Do you want half the the DNSSEC
> signed zones in the world to go insecure or bogus?

I have different numbers, but I do prefer a zone going bogus rather than falsely secure. 

Can you please show where you got the “half the the DNSSEC signed zones in the world to go insecure or bogus” numbers, or are you just picking a convenient number to make your argument?

> 
> Migration should be done responsibly.

Sure. But a migration doc is something else. This is not it. 

Roy

---

From: Paul Wouters <[email-masked]>
Date: Wed, 1 Mar 2017 12:41:22 -0500 (EST)

On Wed, 1 Mar 2017, Roy Arends wrote:

[cut previously answered items]

> The point is not the chain itself, but the right hand side of the first CNAME in a chain. Make it long enough and you’ll have enough bits.

Still very constrained, 63 octet chunks with a total of 253 octets.

> However, you _do_ hash a chain of records. Forget CNAME, take a DNSKEY RRset with a few DNSKEY records in it. A fake 1024 bit key aligned just right will do the trick.

Those are still intersparsed with mandatory DNS markers, unlike the
variable size giant blob inside a PDF.

> Why don’t you leave these future predictions to a future update.

Because having multiple MUST or SHOULD entries does not help the
implementer knowing which ones are more important for the future,
and which ones are more there for legacy deployment reasons.

> Vendors are on this list and usually fairly vocal. I welcome their input.

Agreed.

> Can you please show where you got the “half the the DNSSEC signed zones in the world to go insecure or bogus” numbers, or are you just picking a convenient number to make your argument?

Well, secspider is pretty good?  http://secspider.verisignlabs.com/stats.html

1,641,133 	Production DNSSEC-enabled zones

RSASHA1-NSEC3-SHA1	1,320,540
RSA/MD5			21
RSA/SHA-1 [RSASHA1]	123,575
RSA/SHA256 [RSASHA256]	2,332,855

Number of keys does not directly map to number of zones (we have 3.6M
keys and 1.6M zones) but this shows 1/3 of the keys are still using
SHA1.

To compare, browsers generally are unwilling to kill something if it
affects more then 0.01% of browsers.

Clearly the goal of our draft is moving this in the right direction,
but saying you want to change the security of a third of the zones
to make a point about SHA1 does more damage than good. And the minus
symbols you so dislike is our way or signaling to people to take
note that something we must support today, is being moved to the
chopping block.

> Sure. But a migration doc is something else. This is not it.

It is part of it. Whatever is no longer mandatory to implement is given a
death sentence. The whole point of this document, as we did with 7321 and
4307 in IPsec, is to make things orderly but firmly. Walk, not run. Which
is why we made the distinction between validators and signers. And we
really need the help of the signers to gradually stop signing with the
insecure algorithms while giving them a chance to warn their users,
and more importantly, warn the owners of automated shell scripts.

Paul

---

From: Roy Arends <[email-masked]>
Date: Thu, 2 Mar 2017 11:00:03 +0000

> On 1 Mar 2017, at 17:41, Paul Wouters <[email-masked]> wrote:
> 

This is not true. The shattered.io pdf files contain an embedded jpeg. The difference between the files is in the jpeg comment. The size of the difference is 128 bytes. These are two consecutive 64 byte inputs. The two versions hash to the same output, given the prefix.
The prefix is 192 bytes, and contains the PDF header and the start of the embedded JPEG. This could have been any arbitrary content (such as owner name, TTL, class, type, etc) as long as it is a multiple of 64 bytes (size of input block for sha1).

These 128 bytes can be the content of the DNSKEY. It would therefor not have to be “intersparsed with mandatory DNS markers”.

> and which ones are more there for legacy deployment reasons.

Implementer should follow spec. Spec sez MUST or SHOULD. 

Now it says MUST- MUST+ MUST SHOULD- SHOULD+ and SHOULD. Very confusing. Which one should be implemented? How do I add a grade of importance to specific algorithms, while the protocol itself doesn’t care. DNSSEC has no signalling which algorithm is more or less important in the future. 

> keys and 1.6M zones) but this shows 1/3 of the keys are still using

Okay, so you did make it up.

1/3 is not 1/2. How many of those SHA1 keys are used in conjunction with non-SHA1? That is, how many would still be secure when SHA1 is ignored?

> affects more then 0.01% of browsers.

This is nonsense.

> to make a point about SHA1 does more damage than good.

Again, how many zones does it affect when most of them have SHA2 as well? 

The damage I’m trying to avoid is the false sense of security you are inflicting by not taking the proper action.

It is because the lack of action from specs like these that BIND-9.11.0 still ships with SHA1 defaults:

$dnssec-keygen
Version: 9.11.0
Options:
    -a <algorithm>:
<snip>
       (default: RSASHA1, or NSEC3RSASHA1 if using -3)

> And the minus

oh dear.

I see that further discussion is useless. 

Roy

---

From: Tony Finch <[email-masked]>
Date: Thu, 2 Mar 2017 14:25:05 +0000

Roy Arends <[email-masked]> wrote:
>
> This is not true. The shattered.io pdf files contain an embedded jpeg.
> The difference between the files is in the jpeg comment. The size of the
> difference is 128 bytes. These are two consecutive 64 byte inputs. The
> two versions hash to the same output, given the prefix. The prefix is
> 192 bytes, and contains the PDF header and the start of the embedded
> JPEG.

AIUI it is slightly more complicated than that.

Both shattered.io PDFs contain both versions of the content as two JPEGs -
observe that both files contain two JFIF headers, and that the first JFIF
is after the colliding differences which are between octets 0x00c0 and
0x0140.

$ for i in 1 2; do echo $i; hd shattered-$i.pdf | grep -C1 JFI; done
1
00000230  00 00 ff fe 00 fc 00 00  00 00 00 00 00 00 ff e0  |................|
00000240  00 10 4a 46 49 46 00 01  01 01 00 48 00 48 00 00  |..JFIF.....H.H..|
00000250  ff db 00 43 00 01 01 01  01 01 01 01 01 01 01 01  |...C............|
--
0002da90  a8 87 d0 7f cc ba d0 1d  db 8d 23 a7 c3 89 1a 66  |..........#....f|
0002daa0  66 66 7f ff d9 41 4e 47  45 ff e0 00 10 4a 46 49  |ff...ANGE....JFI|
0002dab0  46 00 01 01 00 00 48 00  48 00 00 ff e1 00 40 45  |F.....H.H.....@E|
2
00000230  00 00 ff fe 00 fc 00 00  00 00 00 00 00 00 ff e0  |................|
00000240  00 10 4a 46 49 46 00 01  01 01 00 48 00 48 00 00  |..JFIF.....H.H..|
00000250  ff db 00 43 00 01 01 01  01 01 01 01 01 01 01 01  |...C............|
--
0002da90  a8 87 d0 7f cc ba d0 1d  db 8d 23 a7 c3 89 1a 66  |..........#....f|
0002daa0  66 66 7f ff d9 41 4e 47  45 ff e0 00 10 4a 46 49  |ff...ANGE....JFI|
0002dab0  46 00 01 01 00 00 48 00  48 00 00 ff e1 00 40 45  |F.....H.H.....@E|

The header before the collision is the start of a binary stream object
that contains the SHA-1 collision followed by both JPEGs. The first two
hunks below are the start and end of this stream object, and the third
hunk is in the PDF rubric towards the end of the file.

$ hd shattered-1.pdf | grep -C1 ream
00000080  43 6f 6d 70 6f 6e 65 6e  74 20 38 3e 3e 0a 73 74  |Component 8>>.st|
00000090  72 65 61 6d 0a ff d8 ff  fe 00 24 53 48 41 2d 31  |ream......$SHA-1|
000000a0  20 69 73 20 64 65 61 64  21 21 21 21 21 85 2f ec  | is dead!!!!!./.|
--
00066e90  a0 02 80 0a 00 28 00 a0  02 80 0a 00 ff d9 0a 65  |.....(.........e|
00066ea0  6e 64 73 74 72 65 61 6d  0a 65 6e 64 6f 62 6a 0a  |ndstream.endobj.|
00066eb0  0a 32 20 30 20 6f 62 6a  0a 31 30 32 34 0a 65 6e  |.2 0 obj.1024.en|
--
00067080  0a 0a 31 32 20 30 20 6f  62 6a 0a 3c 3c 2f 4c 65  |..12 0 obj.<</Le|
00067090  6e 67 74 68 20 33 35 3e  3e 0a 73 74 72 65 61 6d  |ngth 35>>.stream|
000670a0  0a 71 0a 20 20 31 30 32  34 20 30 20 30 20 37 34  |.q.  1024 0 0 74|
000670b0  30 20 30 20 30 20 63 6d  0a 20 20 2f 49 6d 30 20  |0 0 0 cm.  /Im0 |
000670c0  44 6f 0a 51 0a 65 6e 64  73 74 72 65 61 6d 0a 65  |Do.Q.endstream.e|
000670d0  6e 64 6f 62 6a 0a 0a 0a  0a 78 72 65 66 0a 30 20  |ndobj....xref.0 |

PDF files use indirect pointers to pull assets out of a binary stream. I
haven't picked out the details, but I believe the shattered.io PDFs
indirect via the SHA-1 collision garbage near the start of the binary
stream in order to select either the first or second embedded JPEG.

Now you might be able to use this existing collision to attack other file
formats which have PDF-style indirection, if you have Ange Albertini
levels of POC||GFTO polyglot construction skills :-) The main restriction
is that the colliding header must appear at the very start, so your target
has to be happy with files starting %PDF.

So I don't think you can use this particular collision to attack DNSSEC,
but if you can spend 6000 CPU-years of work, and if you can get a crafted
key into a DNSKEY record, then you could do some interesting things :-)
But you'll need to spend 6000 CPU-years per targeted attack, because the
RRset starts with the targeted domain name, and each collision depends on
a fixed prefix.

It's worth comparing with MD5 collisions. For SHA-1 they haven't yet got
to the point where they can construct a collision from two different
chosen prefixes, as they can for MD5, and which was necessary for creating
the rogue CA certificate.

https://www.iacr.org/conferences/eurocrypt2007/slides/s01t1.pdf
http://www.phreedom.org/research/rogue-ca/

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Fitzroy, Sole: Southwest becoming cyclonic later 5 to 7, increasing gale 8 for
a time in southeast Fitzroy. Rough or very rough. Rain or thundery showers.
Good, occasionally poor.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 2 Mar 2017 13:00:30 -0500 (EST)

> Implementer should follow spec. Spec sez MUST or SHOULD.

Implementers may decide to implent some algorithms and not some others,
depending on the level.

> Now it says MUST- MUST+ MUST SHOULD- SHOULD+ and SHOULD. Very confusing.

I understand _you_ find it confusing. It has been used for years in the
ipsec working group without having caused confusion.

> Which one should be implemented?

Saving you the time to re-read Section 1.2 and Section 2:

    SHOULD+   This term means the same as SHOULD.  However, it is likely
              that an algorithm marked as SHOULD+ will be promoted at some
              future time to be a MUST.

    SHOULD-   This term means the same as SHOULD.  However, an algorithm
              marked as SHOULD- may be deprecated to a MAY in a future
              version of this document.
    MUST-     This term means the same as MUST.  However, we expect at
              some point that this algorithm will no longer be a MUST in a
              future document.  Although its status will be determined at
              a later time, it is reasonable to expect that if a future
              revision of a document alters the status of a MUST-
              algorithm, it will remain at least a SHOULD or a SHOULD-.

MUST+ is something you made up, but if you have any divine algorithms
to share, maybe we can do something :P

> How do I add a grade of importance to specific algorithms, while the protocol itself doesn’t care.

I don't understand this remark.

What the + and - symbols are conveying is a likely trend. It is an
effort to ramp up secure algorithms more quickly and to make the long
tail shorter. Without being naive and writing in flag days into RFCs
that implementers are forced to ignore. If we write MUST NOT for SHA1
one, it would be extremely damaging to the current deployment.

You indicated you find this useless. That's fine. If the majority of
the WG agrees with you, we can remove it. I think it will make the
document less informative to implementers.

> DNSSEC has no signalling which algorithm is more or less important in the future.

Which seems to only be a reason in favour of describing this in the RFCs
for implementers?

> 1/3 is not 1/2.

There are people willing to break 1/3 of the internet but not willing to
break 1/2 of the internet?

> How many of those SHA1 keys are used in conjunction with non-SHA1? That is, how many would still be secure when SHA1 is ignored?

Yes, it is theoretically possible that the 1.3 million keys with SHA1 that
are currently deployed are in a zone that is currently in the process of
an algorithm rollover with SHA2. Maybe we can ask Geof since secspider
does not log this.

> Again, how many zones does it affect when most of them have SHA2 as well?

"Do you have the data or are you making this up"

> The damage I’m trying to avoid is the false sense of security you are inflicting by not taking the proper action.

The proper action being to make millions of zones lose SHA1 based DNSSEC
protection and leaving them vulnerable to simple DNS spoofing that does
not take 6500 CPU years?

You are afraid this document obsoletes too slowly, yet we have vendors who
says this document is moving way too quickly and they will never ever
remove anything. As an author, it is not my goal to produce a document
that has to be ignored.

> It is because the lack of action from specs like these that BIND-9.11.0 still ships with SHA1 defaults:

Hmm. If you look at algorithm selection in Section 3.1, you can see SHA1
based algorithms listed as MUST- and SHA256 based algorithms listed as
MUST. So our +/- signaling would actually be a great way for
implementers to decide that RSASHA256 is a better default then RSASHA1.

And had we both had to list them as MUST without any qualifier,
implementers wouldn't have been given that guidance.

Paul

---

From: Petr Špaček <[email-masked]>
Date: Fri, 3 Mar 2017 09:49:11 +0100

> document less informative to implementers.

Personally I find this +/- notation useful in general but the document
version 02 is hard to follow. I grasped its meaning after reading
conversation in this thread.

To improve the document I propose:
- somehow add shortened version of (sometimes implied) advices from 1.2.
 Updating Algorithm Requirement Levels into SHOULD+/SHOULD-/MUST-
definitions in 2.  Conventions Used in This Document.

Examples I would like to see:
   SHOULD-   This term means the same as SHOULD.  However, an algorithm
             marked as SHOULD- may be deprecated to a MAY in a future
             version of this document. It SHOULD be supported for
             interoperability reasons.
             Implementations which give control over used algorithms
             to user SHOULD NOT use algorithms labeled with "SHOULD-"
             as default choice. Algorithms with label "MUST" SHOULD
             [yuck, rephrase this] be preferred.

And so on. This would convey the important message in much cleaner way
than the looong text in 1.2. I understand that this somehow semantically
duplicates 5.  Operational Considerations but IMHO it is much easier to
follow if definition of the term and reasonably short advices are at one
place.

Speaking of 3.  Algorithm Selection, I would like to see definitions of
columns headers "DNSSEC Signing", "DNSSEC Validation", "DNSSEC
Delegation" and "DNSSEC Validation" again either in 2.  Conventions Used
in This Document or in text preceding the tables.

Table headers in 3.1.  DNSKEY Algorithms seem somehow clear (signer vs.
validator) but table 3.2.  DS and CDS Algorithms seems vague to me.

My guesses:
- "DNSSEC Validation" = usage in configuration file as Trust Anchor
- "DNSSEC Delegation" = other uses than Trust Anchor in config file

Is that right? Why are these two different? It would deserve
clarification in the document.

Section 5.  Operational Considerations could emphasise recommendation to
phase out SHOULD- algorithms in signers and other recommendations for
MUST- etc. should be added here as well (or the section can be somehow
merged with 2. Conventions)

Editorial nits:
Section 3.1.  DNSKEY Algorithms would be much easier to follow if text
comments were labeled with algorithm number from the table and ordered
by number. E.g.:

   1: RSAMD5 is not widely deployed and there is an industry-wide trend
      to deprecate MD5 usage.

The very same applies to 3.2.  DS and CDS Algorithms (and it would allow
to get rid of special-case asterisk.)

Let me know if something above is not clear ;-)

-- 
Petr Špaček  @  CZ.NIC

---

From: Paul Wouters <[email-masked]>
Date: Fri, 3 Mar 2017 17:56:13 -0500 (EST)

>             [yuck, rephrase this] be preferred.

In the past for ipsec, we have stayed away from telling implementers
what defaults to use. Perhaps this makes a little more sense in the
DNSSEC context, so that's something we should consider.

> in This Document or in text preceding the tables.

Okay.

> - "DNSSEC Validation" = usage in configuration file as Trust Anchor

What we mean is "consuming DS/CDS records"

> - "DNSSEC Delegation" = other uses than Trust Anchor in config file

And here we mean "producing DS/CDS records"

> merged with 2. Conventions)

The idea is that those terms indicate that already. And Section 5 is
meant to point to potential pitfalls for implementers.

>   1: RSAMD5 is not widely deployed and there is an industry-wide trend

It was not done like that because although in this case we felt we
should describe all table entries, that is not neccesarilly true in
the future. So we did not want to make it an enumerated list. I'll
think about how to increase the readability.

> Let me know if something above is not clear ;-)

I'd be interested if you as an implementer would be willing to follow
these recommendations. And for instance would stop creating new zones
with SHA1, or would stop producing SHA1 based DS records.

Paul

---

From: Petr Špaček <[email-masked]>
Date: Mon, 6 Mar 2017 09:56:36 +0100

> And here we mean "producing DS/CDS records"

Oh, this was totally unclear to me. Please clarify that in 2.
Conventions Used in This Document, or even better re-phase table headers
to make it obvious at the first glance.

> meant to point to potential pitfalls for implementers.

Understood. Unfortunately it is not that obvious after first read.
Please clarify it either in 2.  Conventions Used in This Document or in
section 5.

I will be happy to re-review potential new versions.

> think about how to increase the readability.

I see. IMHO it would be sufficient to prefix the list with a label
indicating that these are only notes. Maybe this?

   Footnotes:

> with SHA1, or would stop producing SHA1 based DS records.

It is important to keep in mind that all of the parameters we are
talking about are user-configurable, so any recommendation will affect
*defaults* which can be overriden by user. I.e. we are not talking about
"stop producing SHA1 based DS records", we can talk about "stop
producing SHA1 based DS records by default".

>From my point of view, having recommendations for interoperable defaults
is very good. Also it lifts burden from implementer as finding good
defaults is a hard thing so I would welcome it.

-- 
Petr Špaček  @  CZ.NIC

---

From: Roy Arends <[email-masked]>
Date: Wed, 15 Mar 2017 11:26:16 +0100

Dear Paul (and wg)

I apologise for the tone. This went south quick and was due to my confrontational style of writing. The secspider-stats are indeed a good indicator, and convinced me that we shouldn’t make SHA1 related DNSKEY algorithms a "MUST NOT”.

In the spirit of being constructive, we (Jakob Schlyter, Matt Larson and I) have written a small draft (draft-arends-dnsop-dnssec-algorithm-update) that does two things:

it changes RSASHA1 from “Must Implement” to “Recommended to Implement”. (RSASHA1 is the only “MUST IMPLEMENT”)
it changes RSASHA256 from “Recommended to Implement” to “Must Implement”. 

The main motivator for this is that implementors have an incentive to move their implementations “default use” away from RSASHA1 (for instance, when a user generates a DNSKEY without specifying an algorithm, or when choosing an algorithm for signing in the presence of more than one algorithm.

This is done in the style of RFC6944, which states that anything that updates the registry table must obsolete RFC6944 (not just update). Therefor, it is as minimal as possible, with no guidelines and no recommendations for the future.

This is NOT a competing draft, though the titles look alike, and I do like to see advice and guidelines for developers and operators in a draft on the BCP track, not proposed standard.

I’m looking forward to discuss this with the working group on the list and during the Chicago IETF DNSOP session.

Warmly

Sometimes Grumpy.
(Roy Arends)

---

From: Paul Wouters <[email-masked]>
Date: Wed, 15 Mar 2017 07:14:21 -0400 (EDT)

> I apologise for the tone. This went south quick and was due to my confrontational style of writing. The secspider-stats are indeed a good indicator, and convinced me that we shouldn’t make SHA1 rel…

Thanks for reaching out Roy. I'm looking forward to talking about both
documents and ensuring that we can speed up the phasing out of SHA1,
and speed up the phasing in of newer prefered algorithms.

Paul

---

From: Michael StJohns <[email-masked]>
Date: Wed, 15 Mar 2017 13:22:05 -0400

> The main motivator for this is that implementors have an incentive to move their implementations “default use” away from RSASHA1 (for instance, when a user generates a DNSKEY without specifying an…

Hi Roy -

I did read through the draft and it looks fairly benign, but I'm 
wondering if perhaps giving some warning and planning a transition might 
be possible while still meeting the spirit of the registry table.

E.g.

Must Implement:   RSASHA1 (Until 5/31/2018), RSASHA256 (after 6/1/2018))

Must Not Implement:  RSASHA1 (After 1/1/2021)

Recommended: RSASHA1 (From 6/1/2018 to 12/31/2020), RSASHA256 (until 
5/31/2018)

This allows immediate use of SHA256 and starts the deprecation process 
for SHA1 but gives some warning to both the vendors and the operators of 
what's coming when.

Mike

---

From: Doug Barton <[email-masked]>
Date: Wed, 15 Mar 2017 21:38:41 -0700

I can't help finding this discussion funny, as I proposed prior to the 
-bis docs that we make RSA-SHA256 mandatory, and SHA1 optional; for the 
simple reason that it was overwhelmingly likely that the root would be 
signed with the former, making it as close to mandatory to implement as 
possible without documenting it as such; and the latter as interesting 
as day-old bread.

Now here we are 13 years later, still having the same discussion, 7 
years after the root was signed with (you guessed it) RSA-SHA256. :)

DNS has a long tail indeed.

On 03/15/2017 10:22 AM, Michael StJohns wrote:
>> In the spirit of being constructive, we (Jakob Schlyter, Matt Larson
>> and I) have written a small draft
>> (draft-arends-dnsop-dnssec-algorithm-update) that does two things:
>>
>> it changes RSASHA1 from “Must Implement” to “Recommended to
>> Implement”. (RSASHA1 is the only “MUST IMPLEMENT”)
>> The main motivator for this is that implementors have an incentive to
>> move their implementations “default use” away from RSASHA1 (for
>> instance, when a user generates a DNSKEY without specifying an
>> algorithm, or when choosing an algorithm for signing in the presence
>> of more than one algorithm.

FWIW I agree with Roy that we should make 256 a must-implement ASAP 
(since for all practical purposes it is already), and encourage 
implementors in the strongest possible terms to make it the default.

> Must Implement:   RSASHA1 (Until 5/31/2018), RSASHA256 (after 6/1/2018))

Michael, this is pointless, unless you can demonstrate how an existing 
implementation works without being able to use the root key.

> Recommended: RSASHA1 (From 6/1/2018 to 12/31/2020), RSASHA256 (until

Mostly pointless, although there was an interesting point raised about 
the difference between producing signatures with SHA1, and being able to 
validate them. Telling people that we're creating a long tail by letting 
them continue to use SHA1 for N years will result in a tail of minimum N 
+ 10 years. So telling people to stop using it NOW is the right answer.

I'm torn on how to deal with validation though. "Compliant 
implementations MUST generate a warning when validating signatures with 
algorithms weaker than RSA-SHA56. Compliant implementations MUST 
generate an error for such algorithms starting 4 years from the 
publication of this document as a draft standard, and unless the records 
are signed with a compliant algorithm they should be considered unsigned."

Something like that, although obviously it needs polishing.

Doug

---

From: tjw ietf <[email-masked]>
Date: Thu, 16 Mar 2017 05:31:22 -0400

Hi

The Call for Adoption ended some time ago with very little discussion in
that period, but a significant and fruitful discussions since.

Considering the strong hum of the room in Seoul and the conversations on
this version, the chairs consider the draft adopted,  If there are items
that wish to be raised during Chicago, the chairs will set aside time in
the meeting to bring these up.

thanks
tim

On Thu, Jan 5, 2017 at 4:28 PM, Tim Wicinski <[email-masked]> wrote:

> All
>
> Since we're having so much fun on adopting work, let's have another one.
> We discussed this work in Seoul, and there was a solid hum on adopting this
> work.
>
> This starts a Call for Adoption for:
> draft-wouters-sury-dnsop-algorithm-update
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-wouters-sury-dnsop-al
> gorithm-update/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> This call for adoption ends: 19 January 2017
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>

---

From: Michael StJohns <[email-masked]>
Date: Mon, 20 Mar 2017 11:51:53 -0400

On 3/16/2017 12:38 AM, Doug Barton wrote:
> -bis docs that we make RSA-SHA256 mandatory, and SHA1 optional; for 
> the simple reason that it was overwhelmingly likely that the root 
> would be signed with the former, making it as close to mandatory to 
> implement as possible without documenting it as such; and the latter 
> as interesting as day-old bread.
>

Hi Doug -

I don't disagree.  But part of the problem is that there are probably 
zones that are only signed with SHA1.   There ought to be a second 
document that says "Signing with SHA1 ends on this date", but that can't 
be done as a registry update AFAICT.    What can be done is sort of give 
the hint to the implementers that there's a transition in progress and 
that the MTI will be changing, and that the current MTI is going away.

In any event, this (my note) was a procedural suggestion that *_we 
generally don't do operationally critical changes to code without some 
warnings to the community_*.  While most folk knew this was coming - 
until its a "standard", many will not care. Once it's a standard, not 
doing the change becomes costly in terms of liability.

We're (the community/ICANN) in the process of doing a root key change 
for the first time ever - the notices and planning on that took years.  
Giving some notice that the MTI for signing is changing before actually 
changing the implementation guidance seems useful.

> implementation works without being able to use the root key.

Fair enough.  But again, this isn't completely about the implementation, 
it's about the operation even though this document will only directly 
affect the implementation.

> the difference between producing signatures with SHA1, and being able 
> to validate them. Telling people that we're creating a long tail by 
> letting them continue to use SHA1 for N years will result in a tail of 
> minimum N + 10 years. So telling people to stop using it NOW is the 
> right answer.

This guidance applies both to the server side and client side.  The idea 
here is that as of 6/1/2018 no one should be able to count on a client 
being able to validate SHA1 (and zones shouldn't be signed with it, but 
could be for legacy reasons), and that after 1/1/2021 the chances of a 
zone signed with SHA1 being able to be validated go down quickly and 
that zones must not be signed with it.

Sorry - I look at this the same way I looked at building 5011.   The 
servers and clients are very loosely coupled - so loosely coupled that 
the servers are sending data to the clients fairly blindly without any 
real knowledge of what they can understand in terms of the data 
content.  (EDNS gives you information on  DNS transport, not DNS data).  
So providing implementation guidance has to understand that split, has 
to understand that when you move Required to Recommended and Recommend 
to Required some implementers will only implement the new required, and 
that the implementers of the clients may not be in sync with the 
implementers of the servers leading to disconnects.

If you want to add SHA256 as a Required immediately, I have no issues 
with that (and you are correct in that that should have been done years 
ago), but I would object to removing SHA1 as a required without a 
deprecation phase for the reasons above.   I'd also *really* like to 
have a final phase out date for SHA1 as well.

If DNSOP instead issues an operational guidance document to be released 
in conjunction with this algorithm update explaining when the zones 
should stop signing with SHA1, I think *that* would be the best of both 
worlds.

Mike

> implementations MUST generate a warning when validating signatures 
> with algorithms weaker than RSA-SHA56. Compliant implementations MUST 
> publication of this document as a draft standard, and unless the 
> records are signed with a compliant algorithm they should be 
> considered unsigned."
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop