Re: [DNSOP] Alternative Special-Use TLD problem statement draft

[Donald Eastlake]

Adrien,

On Thu, Apr 7, 2016 at 7:13 PM, Adrien de Croy  wrote:
> -- Original Message --
> From: "Stephane Bortzmeyer" 
> To: "Adrien de Croy" 
> Cc: "Philip Homburg" ; "dnsop@ietf.org"
> ; "Ted Lemon" 
> Sent: 8/04/2016 3:06:43 a.m.
> Subject: Re: [DNSOP] Alternative Special-Use TLD problem statement draft
>
>...
>
> OK, I read draft-lewis-domain-names-02.txt
>
> I guess in so far as it deals with this subject matter that is correct.
>
> Even though it has a few issues (e.g. not really contemplating prohibited
> characters in domain tokens) the issue here is philosphical, and given that
> the stated intent in the draft is to provide a justification for allowing
> alternate resolution protocols into the domain name space, it's not really
> discussing that issue.
>
> Most of the examples given of uses of alternate interpretations of domain
> names, in my experience do not do that (e.g. DHCP, FTP, X.509, SSH).  As far
> as I can tell only MDNS and TOR are where the real divergence lies, and it's
> really only TOR that fundamentally departs from DNS design.  MDNS retains
> the hierarchical nature, the token limits etc.  All that is changed is the
> character set (I'm glad punycode was abandoned).
>
> The evaluation of the historical origins of domain names could be argued
> another way, rather than used as an argument to diverge from the point we
> converged on with 1035, we could argue that this convergence was the enabler
> for the DNS to become what it is, and we should discard that (no matter its
> warts) at our peril.
>
> Given that there are so many illegal characters in domain tokens, another
> option would have been to use a final token that contains illegal
> characters.

There are no illegal characters for DNS labels. DNS is a binary clean
protocol. All possible 8-bit bytes are permitted in labels and there
is an easy way to write even kludgy ones like the zero valued byte in
Master Files. See RFC 4343 for example.

> e.g. if the TOR authors wanted to ensure their names would fail in a DNS
> resolver, they could have used any number of illegal characters in the final
> token.  E.g. .[onion] instead of .onion

I would avoid square brackets. To the extent they are supposed to do
anything, they are supposed to indicate that the stuff between the
square brackets is an IP address, as in [8.8.8.8], although admittedly
the IETF has been less than successful in getting this syntactic
distinction to stick.

> And maybe this could be the approach for a new root node name under which
> special use names could live.
>
> e.g.
> .[]
> .()
> .$

I don't see any sense in which these are new roots. They look like OK
two or in the last case one byte TLDs in the DNS to me although you
certainly might have to escape the characters in some interfaces. If
you want to be obscure, how about

.\0  or
.\255

instead of .alt...

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

> Or something.  I'm sure some of these would cause parsing problems in some
> protocols, but I'm sure something could be found.
>
> Although it might look like it, I'm not against novel resolution mechanisms
> per se.  What I have a problem with is creating a requirement to deploy new
> DNS resolvers to all the billions of existing deployments.  Because that's
> simply impossible.
>
> Backward compatibility needs its priority elevated IMO.
>
> Adrien
>
>
>
>
>
>>
>> ___
>> 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 mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] RSASHA512 SHOULD-

[Paul Hoffman]

On 8 Apr 2016, at 10:46, Francis Dupont wrote:


In draft-wouters-sury-dnsop-algorithm-update-01.txt the RSASHA512
(code 10) DNSKEY/RRSIG algo got a SHOULD- for DNSSEC signing.
The argument is it is not currently heavily used but I am afraid
it is not a very good argument.
I have a question for cryptographers in the list: as far as I know
there is a relationship with the RSA key size and the output length
of the hash algorithm. So perhaps we should not plan to move
RSASHA512 to MAY (or worse to MUST NOT) as the SHOULD- means,
i.e., put a SHOULD (vs SHOULD-) for RSASHA512?


There is a relationship between the effective strength of the key (RSA 
or EC) and the length of the output. If you are using 20,000-bit RSA 
keys, SHA512 might be appropriate. If you are using 4096 bit or shorter 
RSA keys, SHA256 is sufficient.


--Paul Hoffman

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

Re: [DNSOP] RSASHA512 SHOULD-

[Evan Hunt]

On this topic, I wasn't quick enough to get to the mic before the line was
closed, but I'd like to suggest a higher degree of caution with the "MUST
NOTs" and "MUST-'s" in the validator column, relative to the signer column.

IIRC, RSAMD5 was originally mandatory to implement.  I certainly don't mind
deprecating it for signing, but to tell validators that they not only don't
have to implement it, but actually MUST NOT do so, seems excessive.  The
only justiication I could see for that would be if MD5 were so
comprehensively broken that MD5-signed data could be trivially falsified,
and we're not there yet.  IMHO it shouldn't go any lower than MAY.

Similarly I think it's fine for {NSEC3,}RSASHA1 to get MUST- in the signer
column, but I don't see any near-term future where they should drop below
MUST in the validator column. It's still the default algorithm in the BIND
signer; it's going to be a long, long time before validators can start
ignoring it.


-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

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

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-maintain-ds

[Jacques Latour]

Hi Olafur,

two things I see;

1) the CDNSKEY, since CDS and CDSNKEY are used interchangeably in the document, 
"inserts the corresponding DS RRset as requested" does not work for the 
CDNSKEY, the parental agent must compute a DS and pick an algorithm & digest 
type based on the Parental Agent policy.

2) if the parental agent does not 'like' the requested CDS parameters, then the 
parental agent can create a DS as per Parental agent policy, with algorithm & 
digest type of choosing.

This supports parental agent that publish the DS as requested by the child, and 
support parental agent that want to publish DS conform to their policies.

Jack



From: Olafur Gudmundsson [o...@ogud.com]
Sent: Thursday, April 07, 2016 10:36 PM
To: Jacques Latour
Cc: Tim Wicinski; dnsop; Olafur Gudmundsson
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-maintain-ds


On Apr 7, 2016, at 11:40 AM, Jacques Latour 
mailto:jacques.lat...@cira.ca>> wrote:

Read it, like it, and

>3.1 ... The parent retrieves the CDS and inserts the corresponding DS RRset as 
>requested,

I think the parent can accept the CDS and insert the DS RRset as requested or 
as per Parent policy.

Meaning the Parent could take the signed child DNSKEY and create DS RRset based 
on parent policy and not being forced to accept the CDS algorithm &  Digest 
type.

Maybe,  the CDS record allows one to refer to a non published key i.e. one that 
is not in the DNSKEY RRset.
Thus the CDS is “more” flexible than the DNSKEY as one can publish future KSK 
w/o placing one in the DNSKEY set (for size reasons)

Olafur




> -Original Message-
> From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Tim Wicinski
> Sent: April-03-16 5:29 PM
> To: dnsop
> Subject: [DNSOP] Working Group Last Call for draft-ietf-dnsop-maintain-ds
>
> This starts a Working Group Last Call  for draft-ietf-dnsop-maintain-ds
>
> Current versions of the draft is available here:
>
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/
>
> Please review the draft and offer relevant comments. Also, if someone feels
> the document is *not* ready for publication, please speak out with your
> reasons.
>
> Feel free to show up at DNSOP's Wednesday session and voice your approval
> or disapproval.
>
> This starts a two week Working Group Last Call process, and ends on
>17 April 2016
>
> thanks
> tim
>
> ___
> 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 mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] expanding on Re: Olafur's "black lies" presentation

[Edward Lewis]

On 4/8/16, 12:08, "DNSOP on behalf of Ray Bellis"  wrote:

>That said, Cloudflare's implementation appears to assert that the
>wildcard doesn't exist either - I've asked Olafur to check out the
>implications of that.

Not to pick, but I'm trying to remove the fact that this is tied to a
specific commercial offering.  Not because I want to ignore the real world
but to maintain proper discipline in thinking this through.

Yes, there is an implicit assumption about the wildcard.  I would restate
it as "the wild card doesn't apply".  Or, a "*" label doesn't exist one
label below the closest encloser (as defined in "The Role of Wildcards in
the Domain Name System" [trying to break the habit of talking in obscure
numbers]) of the QNAME.

The reason I recalled the MUST NOT is that, for the sake of argument, I
wrote it way back when.  I hadn't had in mind the wildcard, but, Ray's
right.  A non-DNSSEC aware zone could be left wondering -  although in
fairness, before DNSSEC, harking back to "Negative Caching of DNS Queries
(DNS NCACHE)" [2308], pre-DNSSEC, negative answers didn't reveal anything
about wildcards.

I do recall the reason why the MUST NOT clause came into being was so that
I could write a signer and keep my sanity.  I didn't want anyone to think
that they had to generate names just because they thought the name had to
say it didn't have any records.  There was some other reason too, when
eliminating names to sign, perhaps related to empty-non-terminals.  They
don't have NSEC records.

Where I see a root cause for concern is that DNSSEC was designed assuming
off-line signing.  This means that all negative answers had to be
precomputed.  With that, and a fairly large range of possible QNAMES, the
best approach to say "no" was to say "well, here's what I have, you can
see what you want isn't there."  NSEC and NSEC3 are both based on that
philosophy.  With on-line signing, you can craft a response to the
incoming QNAME that specifically says "what you want I don't have an
answer for."

This situation is fighting two uphill battles.  One, we are forcing the
use of a over-ly constrained container (meaning NSEC designed for not
having on-line keys).  Two, a zone has to say "no" consistently (this gets
into how a zone admin would work out having a set of servers that have
on-line signing simultaneous with a set that does not have on-line
signing).

What if some servers say QNAME NSEC QNAME++ nsec rrsig and another set say
ONAME NSEC YANAME types and *.something NSEC somethingelse.something
types?  I.e., the "black lies" and canonical NSEC.  Or if the other uses a
canonical NSEC3 response?  Will this confuse any attempts to do aggressive
use of NSEC?  And, not to be throwing FUD but asking out of wild
wondering, QNAME mininalization?

At first I thought that using NSEC would solve "two" above, but I'm not
sure.

What I am beginning to wonder about is how we can merge on-line signing
and off-line signing DNSSEC within a zone.  If we can rule that we can't
mix and match, that does change the assumptions regarding what it means to
interoperate between server implementations that do not support on-line
signing and those that do.

The off-line signing assumption of DNSSEC is not because anyone wanted it
that way.  In the era of the 90's, systems were 0wned so easily that no
one dreamed of putting keys on anything on the internet.  Today I can see
that there is willingness to run with on-line keys - but there are and
always will be - strong reasons for some operators to keep the key away
from the internet.  The choice to do so may work if done zone by zone and
not server set by server set.


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Olafur's "black lies" presentation

[Ray Bellis]

On 08/04/2016 11:39, Edward Lewis wrote:
> I can't find a draft to cite for this talk, so this refers to the slides
> presented.
> 
> "DNSSEC Protocol Modifications"
> (http://www.rfc-editor.org/rfc/rfc4035.txt) has an explicit prohibition on
> names owning only NSEC and RRSIG.
> 
> Yeah.
> 
> I'm not holding this up as a royal edict.  But it's there in plain text.
> 
> Fortunately there's a rationale why the requirement language is there, so
> there's a starting point to "work on this."

If you treat Cloudflare's implementation as a virtual wildcard record
where every owner name implicitly exists, then IMHO the rationale in RFC
4035 (below) doesn't apply:

 "That is, the signing process MUST NOT create NSEC or RRSIG RRs for
  owner name nodes that were not the owner name of any RRset before the
  zone was signed. The main reasons for this are a desire for namespace
  consistency between signed and unsigned versions of the same zone
  and  a desire to reduce the risk of response inconsistency in security
  oblivious recursive name servers."

That said, Cloudflare's implementation appears to assert that the
wildcard doesn't exist either - I've asked Olafur to check out the
implications of that.

Ray

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

[DNSOP] Olafur's "black lies" presentation

[Edward Lewis]

I can't find a draft to cite for this talk, so this refers to the slides
presented.

"DNSSEC Protocol Modifications"
(http://www.rfc-editor.org/rfc/rfc4035.txt) has an explicit prohibition on
names owning only NSEC and RRSIG.

Yeah.

I'm not holding this up as a royal edict.  But it's there in plain text.

Fortunately there's a rationale why the requirement language is there, so
there's a starting point to "work on this."

"2.3.  Including NSEC RRs in a Zone

...

   An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
   RRset at any particular owner name."




smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] AAAA4Free

[Ray Bellis]

May I please remind the WG of draft-bellis-dnsext-multi-qtypes-01
(expired, but seems eminently applicable in this case as a signalling
mechanism, and is more general purpose)

Ray

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

Re: [DNSOP] RSASHA512 SHOULD-

[Paul Wouters]

On Fri, 8 Apr 2016, Francis Dupont wrote:


In draft-wouters-sury-dnsop-algorithm-update-01.txt the RSASHA512
(code 10) DNSKEY/RRSIG algo got a SHOULD- for DNSSEC signing.
The argument is it is not currently heavily used but I am afraid
it is not a very good argument.
I have a question for cryptographers in the list: as far as I know
there is a relationship with the RSA key size and the output length
of the hash algorithm. So perhaps we should not plan to move
RSASHA512 to MAY (or worse to MUST NOT) as the SHOULD- means,
i.e., put a SHOULD (vs SHOULD-) for RSASHA512?
Note the time the I-D will be published and applicable we likely
get a clearer view about this issue (:-)!


The reason behind our initial population of SHOULD- for RSASHA512 was
that:

- It is not used widely
- It causes much larger signatures for the same signature strength
  compared to the existing ECDSA algos and the imminent new EDDSA algos.

Paul

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

[DNSOP] RSASHA512 SHOULD-

[Francis Dupont]

In draft-wouters-sury-dnsop-algorithm-update-01.txt the RSASHA512
(code 10) DNSKEY/RRSIG algo got a SHOULD- for DNSSEC signing.
The argument is it is not currently heavily used but I am afraid
it is not a very good argument.
I have a question for cryptographers in the list: as far as I know
there is a relationship with the RSA key size and the output length
of the hash algorithm. So perhaps we should not plan to move
RSASHA512 to MAY (or worse to MUST NOT) as the SHOULD- means,
i.e., put a SHOULD (vs SHOULD-) for RSASHA512?
Note the time the I-D will be published and applicable we likely
get a clearer view about this issue (:-)!

Regards

francis.dup...@fdupont.fr

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

Re: [DNSOP] Alternative Special-Use TLD problem statement draft

[Philip Homburg]

In your letter dated 7 Apr 2016 21:26:51 - you wrote:
>>Just because TOR asks for .onion doesn't mean it should be given it.
>
>The TOR project has been distributing software that special cases
>the .onion TLD for close to a decade.
>
>If the IETF said "you're wrong, go away", what exactly do you
>think they would do?

They would have been in serious trouble.

The problem with the special use registry is that it comes from a line of
thinking that as long as you properly partition the name space, all is fine.

I.e., names have no other properties than that they are either resolved in 
DNS or not.

For the tor project, onion names leaking into DNS is a problem. But is not
clear if and when the current RFC will have any operational impact. It is more a
would be nice if DNS resolvers would filter onion.

There was no real risk that somebody would start using .onion or even that tor
users would be affect by such use.

There was however a really big issue, CA were going to refuse DV certificates
for .onion because officially it did not exist.

Read for example, https://www.ietf.org/blog/2015/09/onion/

So the IETF, saying no we don't want this would have had an impact on this.

The IETF giving a stamp of approval on either a protocol or a name can have a
lot of impact because other (standards) organizations recognize the IETF as the
authority on this.

Adrien de Croy wrote:
"I understand the IETF is supposed to obtain consensus, but I didn't
"see anything in http WG on this until after the fact.  Special use
"names has wide-ranging repercussions.

This is in line with the concept that the special use register is only about
reserving the name. How this impact users of the name space is essentially
not considered. See the rather poor treatment in RFC 7686.

To use the words 'protocol police'. Yes, the IETF is the protocol police. That's
its role in the internet. We can still refer to our documents as 'requests
for comments'. The outside world sees them as the official seal of approval
of the Internet's standards organization.

And in this sense, the IETF should only say yes to a naming protocol if 
it makes sense in the overall architecture of internet related software.
Explictly considering the rather complex interaction between naming and
security in many applications (such as web browsers).

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

Re: [DNSOP] hostnames vs domain names vs RFC1034/1035 vs RFC2818 vs Wikipedia etc

[Suzanne Woolf]

> On Apr 7, 2016, at 10:49 PM, Adrien de Croy  wrote:
>  
> But it's good to see a clear statement from 1987 about desirability of 
> supporting alternate protocols (although they use CLASS for that).  Maybe 
> onion should have used a new CLASS :)
>  

See draft-sullivan-dns-class-useless (which will be discussed in the WG meeting 
in a few hours) for some analysis of why that’s impractical.


Suzanne


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