Re: [DNSOP] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Paul Vixie]

ships are passing in the night on this topic. GOST is what the russian 
government has to use for its crypto. if GOST is not a standard, then the 
russian federation's government won't be using DNSSEC, or they'll do it with a 
pirated code point. neither of those is desirable and there's no third way.

IETF has not been ruled by good engineering for many years now. the rule for 
publication of a standards document now is, if you want to do "this thing", 
here is a way to do it interoperably.

even known-bad ideas get consensus sometimes. (including some of mine, fwiw.) 
there is nothing particularly bad about GOST. we cannot hold it back based on 
some long-dead ideal Internet System having minimum complexity.

i'm in favour of adoption, and will review.

vixie


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

Re: [DNSOP] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Martin Thomson]

On Wed, Jun 17, 2020, at 04:49, Dmitry Belyavsky wrote:
> I don't think there are good or bad time periods to adopt nation-wide 
> crypto profiles. For me, the difference between the GOST profile and 
> hypothetical Korean or German profile is close to zero, and if anybody 
> brings such a profile for standardization, I'd like to support it.

I agree with Olafur on this.  The reason we standardize is so that we can have 
a single - ideally very small - set of algorithms that are widely implemented.  
Because you want every one of those algorithms in every implementation.

In a system like the DNS, you can't really limit the people who might need to 
consume your signature, so the set of acceptable signing algorithms needs to be 
small.  Ideally you have just two: one that is established, and one that is 
new; or one using one technique and a backup using a different technique.

TLS has mostly gotten this part right.  We're much closer to the point of 
having just two in TLS 1.3.  There are a few algorithms that exist to address 
narrow application domains (IoT, *cough*), but at least you can make a case for 
TLS deployments in a closed environment.  For that case, TLS allows for 
codepoint allocation, but avoids an IETF recommendation for those algorithms.  
I don't think that DNS needs that same capability; deciding based on whether 
algorithms are good for global system is the only relevant criterion.

If we all agree that GOST is superior to RSA (it probably is) and EdDSA (I 
doubt it, but I don't have an opinion), then adoption to replace an existing 
algorithm would be fine.  That didn't happen last time, so that suggests it 
would be better for RFC 5933 to be deprecated entirely.

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

Re: [DNSOP] Algorithm implementation recommendations in 8624

[Paul Wouters]

On Wed, 17 Jun 2020, Vladimír Čunát wrote:


On 6/17/20 8:30 AM, Mats Dufberg wrote:
I wonder if there is a way to extend 
https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml

to add signing/validation recommendations.  This seems "hard" from the world of 
IANA, but I'm not an expert.


We did the same at IPsec, where we are instructing IANA to do something
similar:

https://tools.ietf.org/html/draft-pwouters-ikev1-ipsec-graveyard-04#section-6

   This document instructs IANA to mark all IKEv1 registries as
   DEPRECATED.

   Additionally, this document instructs IANA to add an additional
   Status column to the IKEv2 Transform Type registries and mark the
   following entries as DEPRECATED:

   [...]


What strikes me is that IANA has no reference to RFC 8624 and that IANA still 
seems to consider SHA-1 and GOST to be algorithms
to be used.


Technically, IANA does not "consider" anything. They just assign
numbers. I agree it is helpful to list more information to the latest
relevant RFCs in the IANA section though. But the text from 8624
does not map cleanly into the existing registry.

We have had a similar discussion in IPsec on how much we want to be
in the RFC and how much we want to have in the IANA registry. People
have different views.


According to that last RFC, GOST in particular MAY be supported in validators, but there 
are others.  Maybe the "Zone Signing" column
in the registry is not meant to represent whether an algorithm has been obsoleted but 
just the purpose?  Or did "we forget" to add
IANA section into that RFC?  (I'm no good around these process-related 
knowledge.)


I think it refers to the DNSKEY flag, but I admit I find the colum for
Zone Signing and "Trans. Sec." confusing - but I'm not a DNS
implementer.


In any case, it would be nice from my perspective if the table could contain... 
basically the table from the RFC.


It is something we should discuss for the 8624bis document.

Paul

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

Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-https

[Mark Andrews]

Well 2 is a DNS requirement from the word dot.  I’m surprised any DNS developer 
would not know that. It allows records to pass through servers that don’t know 
the rdata fields structure. 

-- 
Mark Andrews

> On 17 Jun 2020, at 22:57, libor.peltan  wrote:
> 
> Hi all,
> 
> i'm a developer of Knot DNS authoritative server. I have some comments on the 
> SVCB draft and some suggestions for improvements. Just consider my thoughts 
> and then do whatever is best.
> 
> (1) The format of SVCB (and HTTPS) RR is too complicated, especially for 
> parsing presentation format to wireformat and back, including consistency 
> checks. Perhaps instead of
> 
> www 3600 IN HTTPS 1 . alpn=h2 port=8443
> 
> It could be
> 
> www 3600 IN HTTPS 1 . alpn h2
>   1 . port 8443
> 
> Which gives slightly bigger RRSet wireformat, but not by much.
> 
> (2) Paragraph 2.2 explicitly requires that SvcDomainName must not be 
> compressed. Is there a reason? Especially when the response packets are large 
> (and I expect that for SVCB they will), any compression helps.
> 
> (3) Paragraph 2.5 contradicts itself: "SvcDomainName MUST be the name of a 
> domain that has SVCB, , or A records" versus "SvcDomainName MAY be the 
> owner of a CNAME record". What is the meaning here?
> 
> (4) Let's assume that CNAME is allowed under SvcDomainName. Paragraph 4.1 is 
> too vague and I don't see what an authoritative (not recursive!) server shall 
> answer in situation SVCB->CNAME->A (all in-bailiwick). Shall the CNAME and A 
> be added to additional section? For comparison, in situation MX->CNAME->A we 
> don't bother since this situation is forbidden (see RFC 2181).
> 
> (5) Wouldn't one octet for priority field be enough?
> 
> (6) There are not enough examples in the document. There are many variants of 
> SVCB records, the formal ABNF description is difficult to read, and it would 
> also illustrate what kind of services those records are designed to handle.
> 
> Best regards and thanks for your effort,
> 
> Libor Peltan
> CZ.NIC
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] Comments on draft-ietf-dnsop-svcb-https

[Tommy Pauly]

> On Jun 17, 2020, at 5:10 AM, libor.peltan  wrote:
> 
> Hi all,
> 
> i'm a developer of Knot DNS authoritative server. I have some comments on the 
> SVCB draft and some suggestions for improvements. Just consider my thoughts 
> and then do whatever is best.
> 
> (1) The format of SVCB (and HTTPS) RR is too complicated, especially for 
> parsing presentation format to wireformat and back, including consistency 
> checks. Perhaps instead of
> 
> www 3600 IN HTTPS 1 . alpn=h2 port=8443
> 
> It could be
> 
> www 3600 IN HTTPS 1 . alpn h2
>   1 . port 8443
> 
> Which gives slightly bigger RRSet wireformat, but not by much.

I find this format suggestion to be far more confusing to read, since these 
really are key-value pairs, and the SvcDomainName and the SvcDomainPriority 
fields are shared across the different key-value pairs.

What specifically is too hard to parse in the draft’s format? Is that something 
that more clarifying examples can help with instead?

Tommy

> 
> (2) Paragraph 2.2 explicitly requires that SvcDomainName must not be 
> compressed. Is there a reason? Especially when the response packets are large 
> (and I expect that for SVCB they will), any compression helps.
> 
> (3) Paragraph 2.5 contradicts itself: "SvcDomainName MUST be the name of a 
> domain that has SVCB, , or A records" versus "SvcDomainName MAY be the 
> owner of a CNAME record". What is the meaning here?
> 
> (4) Let's assume that CNAME is allowed under SvcDomainName. Paragraph 4.1 is 
> too vague and I don't see what an authoritative (not recursive!) server shall 
> answer in situation SVCB->CNAME->A (all in-bailiwick). Shall the CNAME and A 
> be added to additional section? For comparison, in situation MX->CNAME->A we 
> don't bother since this situation is forbidden (see RFC 2181).
> 
> (5) Wouldn't one octet for priority field be enough?
> 
> (6) There are not enough examples in the document. There are many variants of 
> SVCB records, the formal ABNF description is difficult to read, and it would 
> also illustrate what kind of services those records are designed to handle.
> 
> Best regards and thanks for your effort,
> 
> Libor Peltan
> CZ.NIC
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

[DNSOP] Comments on draft-ietf-dnsop-svcb-https

[libor.peltan]

Hi all,

i'm a developer of Knot DNS authoritative server. I have some comments 
on the SVCB draft and some suggestions for improvements. Just consider 
my thoughts and then do whatever is best.


(1) The format of SVCB (and HTTPS) RR is too complicated, especially for 
parsing presentation format to wireformat and back, including 
consistency checks. Perhaps instead of


www 3600 IN HTTPS 1 . alpn=h2 port=8443

It could be

www 3600 IN HTTPS 1 . alpn h2
  1 . port 8443

Which gives slightly bigger RRSet wireformat, but not by much.

(2) Paragraph 2.2 explicitly requires that SvcDomainName must not be 
compressed. Is there a reason? Especially when the response packets are 
large (and I expect that for SVCB they will), any compression helps.


(3) Paragraph 2.5 contradicts itself: "SvcDomainName MUST be the name of 
a domain that has SVCB, , or A records" versus "SvcDomainName MAY be 
the owner of a CNAME record". What is the meaning here?


(4) Let's assume that CNAME is allowed under SvcDomainName. Paragraph 
4.1 is too vague and I don't see what an authoritative (not recursive!) 
server shall answer in situation SVCB->CNAME->A (all in-bailiwick). 
Shall the CNAME and A be added to additional section? For comparison, in 
situation MX->CNAME->A we don't bother since this situation is forbidden 
(see RFC 2181).


(5) Wouldn't one octet for priority field be enough?

(6) There are not enough examples in the document. There are many 
variants of SVCB records, the formal ABNF description is difficult to 
read, and it would also illustrate what kind of services those records 
are designed to handle.


Best regards and thanks for your effort,

Libor Peltan
CZ.NIC

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

Re: [DNSOP] Algorithm implementation recommendations in 8624

[Vladimír Čunát]

On 6/17/20 8:30 AM, Mats Dufberg wrote:
>> I wonder if there is a way to extend 
>> https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml
>>
>> to add signing/validation recommendations.  This seems "hard" from
>> the world of IANA, but I'm not an expert.
>
> What strikes me is that IANA has no reference to RFC 8624 and that
> IANA still seems to consider SHA-1 and GOST to be algorithms to be used.

According to that last RFC, GOST in particular MAY be supported in
validators, but there are others.  Maybe the "Zone Signing" column in
the registry is not meant to represent whether an algorithm has been
obsoleted but just the purpose?  Or did "we forget" to add IANA section
into that RFC?  (I'm no good around these process-related knowledge.)

In any case, it would be nice from my perspective if the table could
contain... basically the table from the RFC.

--Vladimir

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

Re: [DNSOP] DNS RR Type Allocation Request

[Vladimír Čunát]

On 6/16/20 11:05 PM, Brian Dickson wrote:
> Nit: I think this should be "code points" (plural), one for HTTPS and
> one for SVCB, right?

There's even a new registry to be added.  Whole IANA section should get
"executed", I expect.

--Vladimir

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

Re: [DNSOP] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Dick Franks]

Strength - equivalent to ECDSA p256, assuming no fundamental weakness in
the curve parameters.
The Net::DNS::SEC implementation of algorithm 12 verification involves an
algebraic transformation of ECC-GOST into a mathematically equivalent ECDSA
verification. Unless I am missing something, the same approach appears to
be feasible for GOST R34.10-2012 (256 bit).

Apart from a brief flowering in Verisign DNSSEC Analyser
,
algorithm 12 achieved almost no traction.
Implementers may have been discouraged by the mistake
 in R34.10-2001 test parameters.

But there is also a timeliness issue here.  A GOST R34.10 revision appears
every 11 years or so, and is deprecated 5 years after adoption of its
successor.  Next revision ETA 2023.

The sunset date specified in GOST R34.10-2012 having already passed,
algorithm 12 should be marked N in the DNSSEC Algorithm Numbers
 registry.


Dick Franks



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

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

Re: [DNSOP] Algorithm implementation recommendations in 8624

[Mats Dufberg]

On 17 Jun 2020, at 00:35, Tim Wicinski 
mailto:tjw.i...@gmail.com>> wrote:

All

The more time I spend referring to the implementation recommendation table in 
8624

https://www.rfc-editor.org/rfc/rfc8624.html#page-5

The more time I wonder if there is a way to extend
https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml

to add signing/validation recommendations.  This seems "hard" from the world of 
IANA, but I'm not an expert.

Any opinions or suggestions?


What strikes me is that IANA has no reference to RFC 8624 and that IANA still 
seems to consider SHA-1 and GOST to be algorithms to be used.


Mats

---
Mats Dufberg
mats.dufb...@internetstiftelsen.se
Technical Expert
Internetstiftelsen (The Swedish Internet Foundation)
Mobile: +46 73 065 3899
https://internetstiftelsen.se/




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