[DNSOP] Genart last call review of draft-ietf-dnsop-rfc2845bis-06

2020-01-21 Thread Jouni Korhonen via Datatracker 
Reviewer: Jouni Korhonen
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-dnsop-rfc2845bis-??
Reviewer: Jouni Korhonen
Review Date: 2020-01-21
IETF LC End Date: 2020-01-21
IESG Telechat date: Not scheduled for a telechat

Summary:

This document was well written and easy read. I found no complaints. There are
bogus IDNits warnings for "non-RFC2606-compliant FQDNs".

Major issues:

None.

Minor issues:

None.

Nits/editorial comments:

1) The sentence in lines 248-250 was hard to parse in the first few reads. I
suggest rewording... somehow. It was like this in RFC2845 already, though.

248If hosts A.site.example and B.example.net share a key,
249  possibilities for the key name include .A.site.example,
250  .B.example.net, and .A.site.example.B.example.net.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [secdir] Secdir review of draft-ietf-dnsop-rfc2845bis-06

2020-01-21 Thread Warren Kumari 
On Tue, Jan 21, 2020 at 12:31 PM Tony Finch  wrote:
>
> Warren Kumari  wrote:
> >
> > I don't think that it is realistic to deprecate SHA-1 in TSIG for the
> > foreseeable future, but stronger recommendations about moving to
> > SHA-256 might be in order.
>
> Yes.
>
> > There is already some text:
>
> For context, the preceding paragraph says:
>
>The only message digest algorithm specified in the first version of
>these specifications [RFC2845] was "HMAC-MD5" (see [RFC1321],
>[RFC2104]).  Although a review of its security [RFC6151] concluded
>that "it may not be urgent to remove HMAC-MD5 from the existing
>protocols", with the availability of more secure alternatives the
>opportunity has been taken to make the implementation of this
>algorithm optional.
>
> >The use of SHA-1 [FIPS180-4], [RFC3174], (which is a 160-bit hash as
> >compared to the 128 bits for MD5), and additional hash algorithms in
> >the SHA family [FIPS180-4], [RFC3874], [RFC6234] with 224, 256, 384,
> >and 512 bits may be preferred in some cases.  This is because
> >increasingly successful cryptanalytic attacks are being made on the
> >shorter hashes.
>
> I think the quoted paragraph should say something like:
>
>[RFC4635] added mandatory support in TSIG for SHA-1 [FIPS180-4],
>[RFC3174]. SHA-1 collisions have been demonstrated so the MD5
>security considerations apply to SHA-1 in a similar manner.
>
>Although support for hmac-sha1 in TSIG is still mandatory for
>compatibility reasons, existing uses should be replaced with
>hmac-sha256 or other SHA-2 digest algorithms [FIPS180-4], [RFC3874],
>[RFC6234].
>
> Tony.


Oooh. I like it - that seems to address both my, and (presumably!)
Magnus' concerns -- anyone object / have any additions?

W

> --
> f.anthony.n.finchhttp://dotat.at/
> German Bight: West veering northwest 4 or 5. Slight or moderate. Occasional
> drizzle. Good, occasionally poor.



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [secdir] Secdir review of draft-ietf-dnsop-rfc2845bis-06

2020-01-21 Thread Tony Finch 
Warren Kumari  wrote:
>
> I don't think that it is realistic to deprecate SHA-1 in TSIG for the
> foreseeable future, but stronger recommendations about moving to
> SHA-256 might be in order.

Yes.

> There is already some text:

For context, the preceding paragraph says:

   The only message digest algorithm specified in the first version of
   these specifications [RFC2845] was "HMAC-MD5" (see [RFC1321],
   [RFC2104]).  Although a review of its security [RFC6151] concluded
   that "it may not be urgent to remove HMAC-MD5 from the existing
   protocols", with the availability of more secure alternatives the
   opportunity has been taken to make the implementation of this
   algorithm optional.

>The use of SHA-1 [FIPS180-4], [RFC3174], (which is a 160-bit hash as
>compared to the 128 bits for MD5), and additional hash algorithms in
>the SHA family [FIPS180-4], [RFC3874], [RFC6234] with 224, 256, 384,
>and 512 bits may be preferred in some cases.  This is because
>increasingly successful cryptanalytic attacks are being made on the
>shorter hashes.

I think the quoted paragraph should say something like:

   [RFC4635] added mandatory support in TSIG for SHA-1 [FIPS180-4],
   [RFC3174]. SHA-1 collisions have been demonstrated so the MD5
   security considerations apply to SHA-1 in a similar manner.

   Although support for hmac-sha1 in TSIG is still mandatory for
   compatibility reasons, existing uses should be replaced with
   hmac-sha256 or other SHA-2 digest algorithms [FIPS180-4], [RFC3874],
   [RFC6234].

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
German Bight: West veering northwest 4 or 5. Slight or moderate. Occasional
drizzle. Good, occasionally poor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] AD review of draft-ietf-dnsop-multi-provider-dnssec

2020-01-21 Thread Matthijs Mekking 



On 1/21/20 6:03 PM, Tony Finch wrote:
> Matthijs Mekking  wrote:
> 
>> I am not sure how they executed the algorithm rollover precisely.
>> Particularly, were there ever two DS records in the root zone with
>> different algorithms for these zones?
> 
> I can answer that :-)
> 
> Algorithm rollovers have to be double-KSK rollovers because DS records
> have to have a subset of the algorithms of the DNSKEY records. Having both
> algorithms in the DS record can only slow down the rollover so it's hard
> to think of situations where it would make sense (other than Shumon's
> multi-provider disagreement!)

As I suspected, in that case they were never candidate for the multiple
algorithms check.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [secdir] Secdir review of draft-ietf-dnsop-rfc2845bis-06

2020-01-21 Thread Warren Kumari 
[ - secdir for clutter, +DNSOP  ]

Hello DNSOPers,

I'm looking for some advice / discussion...

Below is the security directorate review of
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis/ (posted
to the secdir list) -- normally I'd just start IESG Eval and let the
security ADs review and comment there, but this seems (to me) like it
may deserve more discussion, so I'm posting this here, and will point
the security ADs at it (and ask if there is anyone else who should be
reviewing too).

This -bis was intended to be a relatively simple patch (see Section
10.1, 10.2), and providing stronger advice against using SHA-1 is a
(somewhat) larger change.

I don't think that it is realistic to deprecate SHA-1 in TSIG for the
foreseeable future, but stronger recommendations about moving to
SHA-256 might be in order.

There is already some text:
"The use of SHA-1 [FIPS180-4], [RFC3174], (which is a 160-bit hash as
   compared to the 128 bits for MD5), and additional hash algorithms in
   the SHA family [FIPS180-4], [RFC3874], [RFC6234] with 224, 256, 384,
   and 512 bits may be preferred in some cases.  This is because
   increasingly successful cryptanalytic attacks are being made on the
   shorter hashes."  -- perhaps all that would need to be done would
be to make that much stronger?
I'm sure this isn't a "the sky is falling", but Magnus does raise a
good point, and I think that this is a good hygine opportunity...

Thoughts?
W

On Mon, Jan 20, 2020 at 12:37 AM Magnus Nyström  wrote:
>
> I have reviewed this document as part of the security directorate's ongoing 
> effort to review all IETF documents being processed by the IESG. These 
> comments were written primarily for the benefit of the security area 
> directors.  Document editors and WG chairs should treat these comments just 
> like any other last call comments.
>
> This document defines a mechanism to provide authenticity and integrity of 
> DNS transactions such as update requests.
>
> My main comment about this document is that it recommends use, and mandates 
> support, of HMAC-SHA1, even truncated HMAC-SHA1. In light of recent 
> cryptanalysis results, e.g.,
> - https://eprint.iacr.org/2020/014.pdf
> -  https://www.mitls.org/downloads/transcript-collisions.pdf
> it seems to me that an update to RFC 2845 would be better off not to 
> recommend (or even mandate) use of SHA-1 but rather stronger hash functions 
> such as SHA-256.
> Likewise, the statement "longer [authentication values] are believed to be 
> stronger" is potentially misleading as it is the strength of the algorithm, 
> and not the length of its output, that ultimately determines its security.
>
> Thanks,
> -- Magnus
> ___
> secdir mailing list
> sec...@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] AD review of draft-ietf-dnsop-multi-provider-dnssec

2020-01-21 Thread Tony Finch 
Matthijs Mekking  wrote:

> I am not sure how they executed the algorithm rollover precisely.
> Particularly, were there ever two DS records in the root zone with
> different algorithms for these zones?

I can answer that :-)

Algorithm rollovers have to be double-KSK rollovers because DS records
have to have a subset of the algorithms of the DNSKEY records. Having both
algorithms in the DS record can only slow down the rollover so it's hard
to think of situations where it would make sense (other than Shumon's
multi-provider disagreement!)

[ For normal KSK rollovers I think double-DS is slightly better since it
allows smaller DNSKEY RRset sizes, tho it requires more parent zone
updates. ]


--- root.db
+++ root.db
@@ -1,4 +1,4 @@
-.86400 IN SOA  
a.root-servers.net. nstld.verisign-grs.com. 2018082001 1800 900 604800 86400
+.86400 IN SOA  
a.root-servers.net. nstld.verisign-grs.com. 2018082002 1800 900 604800 86400
 .518400 IN NS  
a.root-servers.net.
 .518400 IN NS  
b.root-servers.net.
 .518400 IN NS  
c.root-servers.net.
@@ -2096,7 +2096,7 @@
 br.  172800 IN NS  d.dns.br.
 br.  172800 IN NS  e.dns.br.
 br.  172800 IN NS  f.dns.br.
-br.  86400 IN DS   45673 5 2 
14369AD309CC59FD59C1A422BA93B71F2C522BF3672C2E067B2C53F5 3AE522DF
+br.  86400 IN DS   2471 13 2 
5E4F35998B8F909557FA119C4CBFDCA2D660A26F069EF006B403758A 07D1A2E4
 a.dns.br.172800 IN A   200.160.0.10
 a.dns.br.172800 IN 2001:12ff::10
 b.dns.br.172800 IN A   200.189.41.10

--- root.db
+++ root.db
@@ -1,4 +1,4 @@
-.86400 IN SOA  
a.root-servers.net. nstld.verisign-grs.com. 2017121400 1800 900 604800 86400
+.86400 IN SOA  
a.root-servers.net. nstld.verisign-grs.com. 2017121401 1800 900 604800 86400
 .518400 IN NS  
a.root-servers.net.
 .518400 IN NS  
b.root-servers.net.
 .518400 IN NS  
c.root-servers.net.
@@ -11638,6 +11638,7 @@
 ns3.pknic.net.pk.172800 IN A   199.192.75.54
 root-s.pknic.pk. 172800 IN A   119.81.34.90
 pl.  172800 IN NS  a-dns.pl.
+pl.  172800 IN NS  b-dns.pl.
 pl.  172800 IN NS  c-dns.pl.
 pl.  172800 IN NS  d-dns.pl.
 pl.  172800 IN NS  e-dns.pl.
@@ -11648,6 +11649,8 @@
 pl.  86400 IN DS   14075 8 2 
4D12B53E0A179C5E51719F606FC429EA03F444CDF5370FBBEEB6ECEB 21E99F2B
 a-dns.pl.172800 IN A   194.181.87.156
 a-dns.pl.172800 IN 
2001:a10:121:1::156
+b-dns.pl.172800 IN A   192.195.72.53
+b-dns.pl.172800 IN 2001:7f9:c::53
 c-dns.pl.172800 IN A   93.190.128.146
 c-dns.pl.172800 IN 2a02:38:14::146
 d-dns.pl.172800 IN A   81.15.133.186
@@ -13124,7 +13127,7 @@
 se.  172800 IN NS  i.ns.se.
 se.  172800 IN NS  j.ns.se.
 se.  172800 IN NS  x.ns.se.
-se.  86400 IN DS   59747 5 2 
44388B3DE9A22CAFA8A12883F60A0F984472D0DFEF0F63ED59A29BE0 18658B28
+se.  86400 IN DS   59407 8 2 
67A8E06FCEFDD9397F77F26C41ADE4EC142F299BCFA1827F0EF8FD87 F2F63022
 nsa.netnod.se.   172800 IN A   194.58.192.33
 nsa.netnod.se.   172800 IN 2a01:3f1:33::53
 nsp.netnod.se.   172800 IN A   194.58.198.33

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Cape Wrath to Rattray Head including Orkney: Mainly westerly or southwesterly
3 or 4, occasionally 5 in north. Smooth or slight in east, moderate or rough
in north, occasionally very rough at first in far north. Fair then occasional
rain or drizzle, fog patches developing in north. Moderate or goo

Re: [DNSOP] AD review of draft-ietf-dnsop-multi-provider-dnssec

2020-01-21 Thread Matthijs Mekking 
Shumon,


On 1/21/20 4:05 PM, Shumon Huque wrote:
> Hi Matthijs,
> 
> Sorry, I did miss your original note on this point. Now that I've seen
> it, I'm copying back dnsop@ietf.org  to see if
> there are other comments on your proposal.
> 
> When the Algorithm Considerations section was originally written, I
> intentionally did not prohibit the use of multiple algorithms across
> providers (even though we recommended against it) for a very
> pragmatic reason: I was actually working with 2 DNS providers that
> supported disjoint algorithms (one RSASHA256 and the other ECDSAP256),
> and was seriously contemplating deploying such a multi-signer
> configuration in production. It would be a bit strange to deploy a
> configuration on the one hand, and at the same time write a document
> that explicitly forbid that configuration.
> 
> You mention that authoritative servers cannot simply ignore the rule
> that they must sign all RRsets in the zone with every algorithm in the
> DNSKEY RRset. However, in practice it is clearly being ignored. Neither
> .SE or .BR double signed their zone data during their algorithm
> rollovers and there are other cases.

If so, then technically they were not conform the RFC, but but I am not
sure how they executed the algorithm rollover precisely. Particularly,
were there ever two DS records in the root zone with different
algorithms for these zones?

>From what I could find, both rollovers did actually sign with double
algorithms though:

See https://static.ptbl.co/static/attachments/179548/1529933472.pdf:

Aug 20 .br Algorithm Rollover Begin (all times UTC)at 06:00 Zones
double signed with old and new algorithm

And on this blog
https://www.sidnlabs.nl/en/news-and-blogs/keep-m-rolling-monitoring-ses-dnssec-algorithm-rollover
it looks like .SE was following the RFC 6781 approach.

Please correct me if I am reading this wrong.


> As it turns out, the provider that only supported RSASHA256 exited the
> managed DNS provider business, and the only vendors we are working with
> currently all support our preferred algorithm (ECDSAP256) in common.
> Hence, I am now open to updating the document to prohibit it. But will
> such text cause aggravation for other potential deployers that may run
> into a similar situation with other providers, and do we care?
> 
> This also begs the question: should we (in another document) update RFC
> 4035, Section 2 (last paragraph) to relax or eliminate the rule, if in
> fact it is being ignored?
> 
> Frankly, I've always been a bit perplexed by this text, since it has no
> accompanying rationale. The only compelling rationale I see is downgrade
> protection - to detect that someone hasn't stripped away the signatures
> of a stronger algorithm and forced a validator to authenticate only the
> weaker signatures. But that implies that validators have a documented
> procedure to rank algorithms, which I haven't yet seen. Is a 3072-bit
> RSASHA256 key stronger or weaker than an ECDSAP256SHA256 key for
> example, or Ed25519 vs ECDSAP256SHA256?

Yes, this is exactly the rationale, and it is a valid one. And this is
how unbound works, see
https://nlnetlabs.nl/documentation/unbound/info-algo/ for more information.

Best regards,

Matthijs



> Shumon.
> 
> On Tue, Jan 21, 2020 at 3:59 AM Matthijs Mekking  > wrote:
> 
> Hi Shumon,
> 
> On 1/20/20 9:21 PM, Shumon Huque wrote:
> >     4: The document uses one inceanse of RFC2119 language
> (RECOMMENDED) -
> >     please either drop this, or add the 2119 / 8174 boilerplate.
> >
> >
> > Ok, I'm inclined to lowercase it, since we don't use 2119/8174
> keywords
> > anywhere else in this document.
> 
> Did you see my mail related to this? If you are going with the lowercase
> approach, please use the word "must" instead of "should".
> 
> Best regards,
> 
> Matthijs
> 
> 
>  Forwarded Message 
> Subject: Re: [DNSOP] Working Group Last Call for
> draft-ietf-dnsop-multi-provider-dnssec
> Date: Mon, 13 Jan 2020 09:57:50 +0100
> From: Matthijs Mekking  >
> To: dnsop@ietf.org 
> 
> Late to the party, I am sorry.
> 
> I am positive about this document, and support publication. I do have
> one comment on the document, requesting an update.
> 
> In section 4 it is said it is RECOMMENDED that providers use a common
> signing algorithm.  I think this is too weak and it must be a MUST.
> 
> The reason given for RECOMMENDED is that the "liberal approach" works.
> The liberal approach says that authoritative zones MUST sign RRsets with
> every algorithm in the DNSKEY RRset, but validating resolvers don't have
> to enforce this requirement. However, that does not mean the
> authoritative server can simply ignore this rule.
> 
> Also, if two different providers are using different alg

Re: [DNSOP] AD review of draft-ietf-dnsop-multi-provider-dnssec

2020-01-21 Thread Frederico A C Neves 
Hi Shumon,

On Tue, Jan 21, 2020 at 10:05:56AM -0500, Shumon Huque wrote:
> Hi Matthijs,
> 
> Sorry, I did miss your original note on this point. Now that I've seen it,
> I'm copying back dnsop@ietf.org to see if there are other comments on your
> proposal.
> 
> When the Algorithm Considerations section was originally written, I
> intentionally did not prohibit the use of multiple algorithms across
> providers (even though we recommended against it) for a very
> pragmatic reason: I was actually working with 2 DNS providers that
> supported disjoint algorithms (one RSASHA256 and the other ECDSAP256), and
> was seriously contemplating deploying such a multi-signer configuration in
> production. It would be a bit strange to deploy a configuration on the one
> hand, and at the same time write a document that explicitly forbid that
> configuration.
> 
> You mention that authoritative servers cannot simply ignore the rule that
> they must sign all RRsets in the zone with every algorithm in the DNSKEY
> RRset. However, in practice it is clearly being ignored. Neither .SE or .BR
> double signed their zone data during their algorithm rollovers and there
> are other cases.

Actually the algorithm rollover, following the liberal approach, is a
pure double signing process. With TTLs tuned it is during a short
interval but still double signing the zone.

ftp://ftp.registro.br/pub/gts/gts32/01-br-algorithm-rollover.pdf

> 
> As it turns out, the provider that only supported RSASHA256 exited the
> managed DNS provider business, and the only vendors we are working with
> currently all support our preferred algorithm (ECDSAP256) in common. Hence,
> I am now open to updating the document to prohibit it. But will such text
> cause aggravation for other potential deployers that may run into a similar
> situation with other providers, and do we care?
> 
> This also begs the question: should we (in another document) update RFC
> 4035, Section 2 (last paragraph) to relax or eliminate the rule, if in fact
> it is being ignored?

I guess 6840 sec 5.11 already clarifies it. 4035 sec 2.2 is talking
about signers.

Fred

> 
> Frankly, I've always been a bit perplexed by this text, since it has no
> accompanying rationale. The only compelling rationale I see is downgrade
> protection - to detect that someone hasn't stripped away the signatures of
> a stronger algorithm and forced a validator to authenticate only the weaker
> signatures. But that implies that validators have a documented procedure to
> rank algorithms, which I haven't yet seen. Is a 3072-bit RSASHA256 key
> stronger or weaker than an ECDSAP256SHA256 key for example, or Ed25519 vs
> ECDSAP256SHA256?
> 
> Shumon.
> 
> On Tue, Jan 21, 2020 at 3:59 AM Matthijs Mekking 
> wrote:
> 
> > Hi Shumon,
> >
> > On 1/20/20 9:21 PM, Shumon Huque wrote:
> > > 4: The document uses one inceanse of RFC2119 language (RECOMMENDED) -
> > > please either drop this, or add the 2119 / 8174 boilerplate.
> > >
> > >
> > > Ok, I'm inclined to lowercase it, since we don't use 2119/8174 keywords
> > > anywhere else in this document.
> >
> > Did you see my mail related to this? If you are going with the lowercase
> > approach, please use the word "must" instead of "should".
> >
> > Best regards,
> >
> > Matthijs
> >
> >
> >  Forwarded Message 
> > Subject: Re: [DNSOP] Working Group Last Call for
> > draft-ietf-dnsop-multi-provider-dnssec
> > Date: Mon, 13 Jan 2020 09:57:50 +0100
> > From: Matthijs Mekking 
> > To: dnsop@ietf.org
> >
> > Late to the party, I am sorry.
> >
> > I am positive about this document, and support publication. I do have
> > one comment on the document, requesting an update.
> >
> > In section 4 it is said it is RECOMMENDED that providers use a common
> > signing algorithm.  I think this is too weak and it must be a MUST.
> >
> > The reason given for RECOMMENDED is that the "liberal approach" works.
> > The liberal approach says that authoritative zones MUST sign RRsets with
> > every algorithm in the DNSKEY RRset, but validating resolvers don't have
> > to enforce this requirement. However, that does not mean the
> > authoritative server can simply ignore this rule.
> >
> > Also, if two different providers are using different algorithms, that
> > means two DS records with different algorithms are distributed to the
> > parent. And now the algorithm is signaled in the parent and a validator
> > may execute the multiple algorithms protection check, expecting both
> > chain of trusts to work.
> >
> > In other words, please adapt section 4 to be more strict when it comes
> > to multiple algorithms. If you agree, I am happy to provide the
> > suggested text.
> >
> > Again my apologies for bringing this up so late.
> >
> > Best regards,
> >
> > Matthijs
> >

> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list

Re: [DNSOP] AD review of draft-ietf-dnsop-multi-provider-dnssec

2020-01-21 Thread Steve Crocker 
Shumon,

You're asking the right questions:

This also begs the question: should we (in another document) update RFC
4035, Section 2 (last paragraph) to relax or eliminate the rule, if in fact
it is being ignored?

Frankly, I've always been a bit perplexed by this text, since it has no
accompanying rationale. The only compelling rationale I see is downgrade
protection - to detect that someone hasn't stripped away the signatures of
a stronger algorithm and forced a validator to authenticate only the weaker
signatures. But that implies that validators have a documented procedure to
rank algorithms, which I haven't yet seen. Is a 3072-bit RSASHA256 key
stronger or weaker than an ECDSAP256SHA256 key for example, or Ed25519 vs
ECDSAP256SHA256?

On the face of it, absent a good counter argument, this does indeed seem
like an appropriate time to revise RFC 4035 as you suggest.  Strict
adherence to the rule would require a somewhat awkward multi-step process
for switching from a provider who only supports algorithm x to a provider
that supports -- or at least prefers -- algorithm y.  The transition would
first have to be to a provider that supports both x and y but is willing to
use just x.  After the transition, the new provider would then introduce
algorithm y, and then would eliminate algorithm x.  This seems like an
unnecessary and lengthy sequence.

Thanks,

Steve


On Tue, Jan 21, 2020 at 10:06 AM Shumon Huque  wrote:

> Hi Matthijs,
>
> Sorry, I did miss your original note on this point. Now that I've seen it,
> I'm copying back dnsop@ietf.org to see if there are other comments on
> your proposal.
>
> When the Algorithm Considerations section was originally written, I
> intentionally did not prohibit the use of multiple algorithms across
> providers (even though we recommended against it) for a very
> pragmatic reason: I was actually working with 2 DNS providers that
> supported disjoint algorithms (one RSASHA256 and the other ECDSAP256), and
> was seriously contemplating deploying such a multi-signer configuration in
> production. It would be a bit strange to deploy a configuration on the one
> hand, and at the same time write a document that explicitly forbid that
> configuration.
>
> You mention that authoritative servers cannot simply ignore the rule that
> they must sign all RRsets in the zone with every algorithm in the DNSKEY
> RRset. However, in practice it is clearly being ignored. Neither .SE or .BR
> double signed their zone data during their algorithm rollovers and there
> are other cases.
>
> As it turns out, the provider that only supported RSASHA256 exited the
> managed DNS provider business, and the only vendors we are working with
> currently all support our preferred algorithm (ECDSAP256) in common. Hence,
> I am now open to updating the document to prohibit it. But will such text
> cause aggravation for other potential deployers that may run into a similar
> situation with other providers, and do we care?
>
> This also begs the question: should we (in another document) update RFC
> 4035, Section 2 (last paragraph) to relax or eliminate the rule, if in fact
> it is being ignored?
>
> Frankly, I've always been a bit perplexed by this text, since it has no
> accompanying rationale. The only compelling rationale I see is downgrade
> protection - to detect that someone hasn't stripped away the signatures of
> a stronger algorithm and forced a validator to authenticate only the weaker
> signatures. But that implies that validators have a documented procedure to
> rank algorithms, which I haven't yet seen. Is a 3072-bit RSASHA256 key
> stronger or weaker than an ECDSAP256SHA256 key for example, or Ed25519 vs
> ECDSAP256SHA256?
>
> Shumon.
>
> On Tue, Jan 21, 2020 at 3:59 AM Matthijs Mekking 
> wrote:
>
>> Hi Shumon,
>>
>> On 1/20/20 9:21 PM, Shumon Huque wrote:
>> > 4: The document uses one inceanse of RFC2119 language (RECOMMENDED)
>> -
>> > please either drop this, or add the 2119 / 8174 boilerplate.
>> >
>> >
>> > Ok, I'm inclined to lowercase it, since we don't use 2119/8174 keywords
>> > anywhere else in this document.
>>
>> Did you see my mail related to this? If you are going with the lowercase
>> approach, please use the word "must" instead of "should".
>>
>> Best regards,
>>
>> Matthijs
>>
>>
>>  Forwarded Message 
>> Subject: Re: [DNSOP] Working Group Last Call for
>> draft-ietf-dnsop-multi-provider-dnssec
>> Date: Mon, 13 Jan 2020 09:57:50 +0100
>> From: Matthijs Mekking 
>> To: dnsop@ietf.org
>>
>> Late to the party, I am sorry.
>>
>> I am positive about this document, and support publication. I do have
>> one comment on the document, requesting an update.
>>
>> In section 4 it is said it is RECOMMENDED that providers use a common
>> signing algorithm.  I think this is too weak and it must be a MUST.
>>
>> The reason given for RECOMMENDED is that the "liberal approach" works.
>> The liberal approach says that authoritative zones MUST sign RRsets with
>> every

Re: [DNSOP] AD review of draft-ietf-dnsop-multi-provider-dnssec

2020-01-21 Thread Shumon Huque 
Hi Matthijs,

Sorry, I did miss your original note on this point. Now that I've seen it,
I'm copying back dnsop@ietf.org to see if there are other comments on your
proposal.

When the Algorithm Considerations section was originally written, I
intentionally did not prohibit the use of multiple algorithms across
providers (even though we recommended against it) for a very
pragmatic reason: I was actually working with 2 DNS providers that
supported disjoint algorithms (one RSASHA256 and the other ECDSAP256), and
was seriously contemplating deploying such a multi-signer configuration in
production. It would be a bit strange to deploy a configuration on the one
hand, and at the same time write a document that explicitly forbid that
configuration.

You mention that authoritative servers cannot simply ignore the rule that
they must sign all RRsets in the zone with every algorithm in the DNSKEY
RRset. However, in practice it is clearly being ignored. Neither .SE or .BR
double signed their zone data during their algorithm rollovers and there
are other cases.

As it turns out, the provider that only supported RSASHA256 exited the
managed DNS provider business, and the only vendors we are working with
currently all support our preferred algorithm (ECDSAP256) in common. Hence,
I am now open to updating the document to prohibit it. But will such text
cause aggravation for other potential deployers that may run into a similar
situation with other providers, and do we care?

This also begs the question: should we (in another document) update RFC
4035, Section 2 (last paragraph) to relax or eliminate the rule, if in fact
it is being ignored?

Frankly, I've always been a bit perplexed by this text, since it has no
accompanying rationale. The only compelling rationale I see is downgrade
protection - to detect that someone hasn't stripped away the signatures of
a stronger algorithm and forced a validator to authenticate only the weaker
signatures. But that implies that validators have a documented procedure to
rank algorithms, which I haven't yet seen. Is a 3072-bit RSASHA256 key
stronger or weaker than an ECDSAP256SHA256 key for example, or Ed25519 vs
ECDSAP256SHA256?

Shumon.

On Tue, Jan 21, 2020 at 3:59 AM Matthijs Mekking 
wrote:

> Hi Shumon,
>
> On 1/20/20 9:21 PM, Shumon Huque wrote:
> > 4: The document uses one inceanse of RFC2119 language (RECOMMENDED) -
> > please either drop this, or add the 2119 / 8174 boilerplate.
> >
> >
> > Ok, I'm inclined to lowercase it, since we don't use 2119/8174 keywords
> > anywhere else in this document.
>
> Did you see my mail related to this? If you are going with the lowercase
> approach, please use the word "must" instead of "should".
>
> Best regards,
>
> Matthijs
>
>
>  Forwarded Message 
> Subject: Re: [DNSOP] Working Group Last Call for
> draft-ietf-dnsop-multi-provider-dnssec
> Date: Mon, 13 Jan 2020 09:57:50 +0100
> From: Matthijs Mekking 
> To: dnsop@ietf.org
>
> Late to the party, I am sorry.
>
> I am positive about this document, and support publication. I do have
> one comment on the document, requesting an update.
>
> In section 4 it is said it is RECOMMENDED that providers use a common
> signing algorithm.  I think this is too weak and it must be a MUST.
>
> The reason given for RECOMMENDED is that the "liberal approach" works.
> The liberal approach says that authoritative zones MUST sign RRsets with
> every algorithm in the DNSKEY RRset, but validating resolvers don't have
> to enforce this requirement. However, that does not mean the
> authoritative server can simply ignore this rule.
>
> Also, if two different providers are using different algorithms, that
> means two DS records with different algorithms are distributed to the
> parent. And now the algorithm is signaled in the parent and a validator
> may execute the multiple algorithms protection check, expecting both
> chain of trusts to work.
>
> In other words, please adapt section 4 to be more strict when it comes
> to multiple algorithms. If you agree, I am happy to provide the
> suggested text.
>
> Again my apologies for bringing this up so late.
>
> Best regards,
>
> Matthijs
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop