date:20200618

On 18 Jun 2020, at 16:15, Ted Lemon  wrote:
> 
> For what it’s worth, I am in favor of adopting this document. With that said, 
> however, I do have questions, Roy.

Thanks for your support.

> If we use these ccTLDs as squatting domains, that means that we’re going to 
> see a lot of traffic at the root trying to find nonexistent name servers, 
> right?  

“A lot” is relative. 73% of queries to the ICANN managed root servers are for 
domains that do not exist. Close to 50% is done by a single application.

This traffic will likely end up in the margins. When squatted domains are 
traded in for private use domains, there is no difference. 

> And these ccTLDs provably do not exist, right?

Yes, and rightfully so.

> Contrariwise, home.arpa has an un-signed delegation.  Queries for home.arpa 
> are no worse than queries for any other .arpa subdomain, as far as the root 
> is concerned. On the other hand, perhaps they are worse for .arpa, and since 
> in fact .arpa is currently served by the root servers, perhaps this makes no 
> difference.

I have no idea.

> What’s the difference we’ll see in traffic for the root versus traffic for 
> .arpa if people adopt known-unused, securely nonexistent ccTLDs instead of an 
> un-signed delegation under .arpa?

Again, negligible.

> Also, what do you think the operational effect of this will be? Given that 
> these domains are currently provably nonexistent, this means that a resolver 
> looking up names in these domains will have to special-case them.

A resolver has to special provision anything that is used in private, 
regardless of DNSSEC, correct? 

A validating stub resolver needs to have a negative trust anchor for that 
unsigned space, if that unsigned space is actually used privately. 

The inverse is a stunningly bad idea:

If .internal is delegated from the root, there is a security hole that 

(1) is open by default in EVERY network.
(2) every hacker knows about. You can spoof .internal from the outside of the 
victim resolver, in your own time, from your own network. 
(3) every user has to use, since there is no other private space (unless .zz 
and others is a non-delegated, but designated private space). 
(4) every device will be shipped with, because they have been told that 
.internal is the new squatting.

and if you don’t want to be exposed to this security hole EVERYONE has to
(1) redirect .internal elsewhere, even WHEN YOU ARE NOT USING IT. (Some new app 
may be using it, some client on your network may be using it)
(2) deploy a bogus trust anchor on your validating stub resolver everywhere.

And for what? 

For the theoretical validating stub resolver that somehow can't have a negative 
trust anchor for .internal (good luck deploying a signed .internal), while 
having a trust anchor for root. 

But this is just my opinion.

Giving the world an open door into everyone’s private space was not what I had 
in mind when I started working on DNSSEC.

Roy

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

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

2020-06-18 Thread Töma Gavrichenkov

Peace,

On Thu, Jun 18, 2020, 8:39 PM Daniel Migault  wrote:

> To my perspective, holding code point allocation is likely to result in
> non allocated code points being used which represents a higher threat to
> interoperability than adding an algorithm.
>

+1

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

2020-06-18 Thread Philip Homburg

> The root zone and private-use internal zones that anchor private
> namespaces might all benefit from a robust trust anchor distribution
> strategy. If validators have the ability to be configured elegantly
> with all the trust anchors they need without the attention of a
> knowledgeable administrator (as a validating stub resolver might
> need with the root zone trust anchor) we might find that the DNSSEC
> concerns that led to horrors like home.arpa all disappear.

I think it would be good to have support for more trust anchors. Also 
for public domains. 

However, additional root CAs for X509 certs is quite a mess. DNS would be
slightly better, a trust anchor covers only part of the DNS tree, unlike
installing a root CA. However, ultimately trust in your trust anchor is
limited to the trust in the mechanism used to distribute the trust anchor.


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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

On Jun 18, 2020, at 2:24 PM, Warren Kumari  wrote:
> ... and I should point out that this was one of the arguments in
> https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00#section-4.3 
> 
> for an (insecure) delegation (just like home.arpa has). Currently
> operating system vendors (and similar) cannot realistically ship
> validating stub resolvers - having BYOD users suddenly unable to
> resolve www.corp on your shiny new phone/tablet/laptop results in
> outrage, and customers buying your competitors widget instead.

This is another way of framing the issue. What I’m trying to get at is that we 
should be telling people how to do this in a way that doesn’t break validating 
resolvers. At least, I think we should. I think there are two facets to this:

1. If your stub resolver validates, it must be possible to provision a trust 
anchor for a private zone.
2. When you set up a private zone, you should use a zone the existence of which 
isn’t securely denied.

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

2020-06-18 Thread Warren Kumari

On Thu, Jun 18, 2020 at 1:47 PM Ted Lemon  wrote:
>
> It can be solved with a trust anchor as well, but that relies on there being 
> a central validating resolver rather than validating stub resolvers on hosts, 
> and personally I don’t find that deployment model very compelling anymore—I 
> think that stub resolvers should validate.  If I get my way, then we’re going 
> to see these “private” domains start to fail.

... and I should point out that this was one of the arguments in
https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00#section-4.3
for an (insecure) delegation (just like home.arpa has). Currently
operating system vendors (and similar) cannot realistically ship
validating stub resolvers - having BYOD users suddenly unable to
resolve www.corp on your shiny new phone/tablet/laptop results in
outrage, and customers buying your competitors widget instead.

The presentation at
http://slides.com/wkumari/deck-f68ee558-abac-4af2-9357-5669734d3445-5-8#/3/0/0
(slide 6) only briefly touched on it:
Has to be a TLD for non-technical / aesthetic reasons
DNSSEC requires that this be added to the root (with a DNSSEC insecure
delegation).
-happy to cover the reasons off-line
  -no process for this.
- Will require creating one!

People (rightly IMO) said that this isn't DNSOP work, and should be
taken to ICANN instead.

The above presentation also said:
Users want an internal / disconnected namespace
... but we told them not to do this.

Squatting on TLDs causes various issues like:
pollution of the namespace  e.g .home, .corp, .mail, ...
potentially collisions
  excess root / recursive lookups
  somewhat mitigated by Aggressive NSEC
  leaking of "internal" names

Actually we say "Use something under a registered domain"
We are the adults, this is risky behavior, you don't actually want to do this
We also preach abstinence
Regardless of what we think of the behavior, we can't stop people
doing this - but we can make it less risky.

This seems to be related to much of what was said earlier --
regardless of what we think of people using a private/internal name,
there are no protocol police, and we cannot prevent it - but we can
posibly coral the badness into fewer places...

I'm limiting my involvement in this thread - I'm also working on the
SSAC .internal document
(https://mm.icann.org/pipermail/ncap-discuss/2020-June/000432.html),
and take the ICANN SSAC confidentiality agreement seriously.
While I have asked my co-AD to be responsible for the document
(https://mailarchive.ietf.org/arch/msg/dnsop/13iQFI6V3yJ90SxbqSy8UubQ6bU/)
I'm being extra cautious in this thread...

W

>
> Sent from my iPad
>
> On Jun 18, 2020, at 1:36 PM, Vladimír Čunát  
> wrote:
>
> 
> On 6/18/20 7:22 PM, Ted Lemon wrote:
>
> I suspect it will work like every other locally-served domain or every other 
> private namespace that exists today, i.e. just fine with no configuration 
> changes expected or required on dependent (downstream) DNS clients. And if 
> there are new species of resolver that need to be accommodated (e.g. 
> validating, hybrid stub/full service resolvers embedded in applications), 
> whatever configuration or auto-discovery mechanisms are required to support 
> those other locally-served zones can surely be easily extended to these 
> ISO-3166-2 codes if they are used in any particular private network.
>
>
> What I’m getting at is that the secure denial of existence will mean that a 
> DNSSEC-aware resolver, when asked to look up a name under .xa, for example, 
> will always return NXDOMAIN.
>
> Yes, but squatting is usually done at root names already, so the issue isn't 
> new.
>
> Modifying DNS past the last validator is generally troublesome.  Modifying it 
> inside the last validating resolver can be fine, as the implementation can 
> "prioritize" the modifications over validation and aggressive caching (but as 
> an implementor I still find this troublesome).
>
> --Vladimir
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
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] Call for Adoption: draft-arends-private-use-tld

2020-06-18 Thread Joe Abley

On Jun 18, 2020, at 19:22, Ted Lemon  wrote:

> What I’m getting at is that the secure denial of existence will mean that a 
> DNSSEC-aware resolver, when asked to look up a name under .xa, for example, 
> will always return NXDOMAIN.

I think we're speculating about behaviour in software that has not yet been 
written, software that will have a natural requirement to deal with the 
environment it finds itself deployed in.

But it also occurs to me that if we agree that the great root zone KSK roll 
melodrama illustrated that we have a root zone trust anchor distribution 
problem, it's not much of a stretch to generalise that statement and say that 
we have a trust anchor distribution problem.

The root zone and private-use internal zones that anchor private namespaces 
might all benefit from a robust trust anchor distribution strategy. If 
validators have the ability to be configured elegantly with all the trust 
anchors they need without the attention of a knowledgeable administrator (as a 
validating stub resolver might need with the root zone trust anchor) we might 
find that the DNSSEC concerns that led to horrors like home.arpa all disappear.

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

It can be solved with a trust anchor as well, but that relies on there being a 
central validating resolver rather than validating stub resolvers on hosts, and 
personally I don’t find that deployment model very compelling anymore—I think 
that stub resolvers should validate.  If I get my way, then we’re going to see 
these “private” domains start to fail.

Sent from my iPad

> On Jun 18, 2020, at 1:36 PM, Vladimír Čunát  
> wrote:
> 
> 
>> On 6/18/20 7:22 PM, Ted Lemon wrote:
>>> I suspect it will work like every other locally-served domain or every 
>>> other private namespace that exists today, i.e. just fine with no 
>>> configuration changes expected or required on dependent (downstream) DNS 
>>> clients. And if there are new species of resolver that need to be 
>>> accommodated (e.g. validating, hybrid stub/full service resolvers embedded 
>>> in applications), whatever configuration or auto-discovery mechanisms are 
>>> required to support those other locally-served zones can surely be easily 
>>> extended to these ISO-3166-2 codes if they are used in any particular 
>>> private network.
>> 
>> What I’m getting at is that the secure denial of existence will mean that a 
>> DNSSEC-aware resolver, when asked to look up a name under .xa, for example, 
>> will always return NXDOMAIN.
> Yes, but squatting is usually done at root names already, so the issue isn't 
> new.
> 
> Modifying DNS past the last validator is generally troublesome.  Modifying it 
> inside the last validating resolver can be fine, as the implementation can 
> "prioritize" the modifications over validation and aggressive caching (but as 
> an implementor I still find this troublesome).
> 
> --Vladimir
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-18 Thread Daniel Migault

I support adoption of the document. To my perspective, holding code point
allocation is likely to result in non allocated code points being used
which represents a higher threat to interoperability than adding an
algorithm.
Standard track and MAY/OPTIONAL status seem reasonable to me

Yours,
Daniel

On Thu, Jun 18, 2020 at 12:58 PM Eric Rescorla  wrote:

>
>
> On Thu, Jun 18, 2020 at 9:36 AM Paul Wouters  wrote:
>
>> On Thu, 18 Jun 2020, Eric Rescorla wrote:
>>
>> > The way that TLS has handled this is to have the registries have a
>> column called Recommended and we just mark things Y or N. This is slightly
>> > different from RFC 2119 language.
>> >
>> > It's not that uncommon to have new stuff introduced with Recommended =
>> N. In fact this is the likely outcome for the GOST cipher suites:
>> > https://datatracker.ietf.org/doc/draft-smyshlyaev-tls13-gost-suites/
>>
>> I don't see anything like that mentioned in the IANA Considerations
>> section?
>> https://tools.ietf.org/html/draft-smyshlyaev-tls13-gost-suites-02#section-7
>>
>
> The relevant text is in 8447:
> https://tools.ietf.org/html/rfc8447#section-5
>
>Per this document, a "Recommended" column has been added to many of
>the TLS registries to indicate parameters that are generally
>recommended for implementations to support.  Adding a "Recommended"
>parameter (i.e., "Y") to a registry or updating a parameter to
>"Recommended" status requires Standards Action.  Not all parameters
>defined in Standards Track documents need to be marked as
>"Recommended".
>
> As the GOST draft has an informational header and is not a TLS WG item, I 
> would expect any registration to have Recommended = N.
>
>
>
> In fact, the table is specifically missing the Recommended column
>> required by the IANA Registry.
>>
>
> That seems like an omission but given the above, I expect IANA can handle
> it.
>
>
>
>> As a side not, in those Security Considerations I see:
>>
>> 2. 0-RTT data SHOULD NOT be sent during TLS 1.3 connection.  The
>> reasons for this restriction are that the 0-RTT data is not forward
>> secret and is not resistant to replay attacks
>>
>> It seems that the SHOULD NOT is really a very hard MUST NOT.
>>
>
> It's not clear to me if GOST is any different than the existing TLS cipher
> suites in this respect, but if not, then I'm not quite sure what the
> rationale is here.
>
> -Ekr
>
>
>> As another side note, would be nice to have a link to the IANA sections
>> updated in the IANA Considerations Section.
>>
>>
>> Paul
>>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
Daniel Migault
Ericsson
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

2020-06-18 Thread Vladimír Čunát

On 6/18/20 7:22 PM, Ted Lemon wrote:
>> I suspect it will work like every other locally-served domain or
>> every other private namespace that exists today, i.e. just fine with
>> no configuration changes expected or required on dependent
>> (downstream) DNS clients. And if there are new species of resolver
>> that need to be accommodated (e.g. validating, hybrid stub/full
>> service resolvers embedded in applications), whatever configuration
>> or auto-discovery mechanisms are required to support those other
>> locally-served zones can surely be easily extended to these
>> ISO-3166-2 codes if they are used in any particular private network.
>
> What I’m getting at is that the secure denial of existence will mean
> that a DNSSEC-aware resolver, when asked to look up a name under .xa,
> for example, will always return NXDOMAIN.

Yes, but squatting is usually done at root names already, so the issue
isn't new.

Modifying DNS past the last validator is generally troublesome. 
Modifying it inside the last validating resolver can be fine, as the
implementation can "prioritize" the modifications over validation and
aggressive caching (but as an implementor I still find this troublesome).

--Vladimir

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

On Jun 18, 2020, at 12:10 PM, Joe Abley  wrote:
> 
> [As an aside, I have some concerns about RFC 8375 and I wish I was paying 
> more attention at the time it was discussed. Although I can understand some 
> of the technical arguments for the delegation, I'm not especially convinced 
> by them in practice, and the decision to make the unsigned delegation also a 
> *lame* unsigned delegation whilst simultaneously directing all leaked queries 
> with potential information about private networks to be sent to nameservers 
> that by design are intended to have anonymous operators is a poor one, I 
> think. I note that the security considerations section doesn't even address 
> the potential for information leakage.]

Ouch. That’s a depressing observation.  I’m can’t think of a way to completely 
mitigate this risk, however, unfortunately.  Any mitigation requires new code 
on the edge router for the provisioning domain in which the locally-served 
domain is being used.

>> Also, what do you think the operational effect of this will be? Given that 
>> these domains are currently provably nonexistent, this means that a resolver 
>> looking up names in these domains will have to special-case them.
> 
> I suspect it will work like every other locally-served domain or every other 
> private namespace that exists today, i.e. just fine with no configuration 
> changes expected or required on dependent (downstream) DNS clients. And if 
> there are new species of resolver that need to be accommodated (e.g. 
> validating, hybrid stub/full service resolvers embedded in applications), 
> whatever configuration or auto-discovery mechanisms are required to support 
> those other locally-served zones can surely be easily extended to these 
> ISO-3166-2 codes if they are used in any particular private network.

What I’m getting at is that the secure denial of existence will mean that a 
DNSSEC-aware resolver, when asked to look up a name under ..xa, for example, 
will always return NXDOMAIN.

> This draft describes an existing consequence of existing policy. It may be 
> that Ed and Roy are the first ones to think about using them to anchor 
> private namespaces, but in some sense any corner cases that need special 
> handling today also needed special handling before this draft was written; we 
> just didn't know it yet.

I suspect that a discussion of the DNSSEC issue is in-scope. :)

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

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

On Thu, Jun 18, 2020 at 9:36 AM Paul Wouters  wrote:

> On Thu, 18 Jun 2020, Eric Rescorla wrote:
>
> > The way that TLS has handled this is to have the registries have a
> column called Recommended and we just mark things Y or N. This is slightly
> > different from RFC 2119 language.
> >
> > It's not that uncommon to have new stuff introduced with Recommended =
> N. In fact this is the likely outcome for the GOST cipher suites:
> > https://datatracker.ietf.org/doc/draft-smyshlyaev-tls13-gost-suites/
>
> I don't see anything like that mentioned in the IANA Considerations
> section?
> https://tools.ietf.org/html/draft-smyshlyaev-tls13-gost-suites-02#section-7
>

The relevant text is in 8447: https://tools.ietf.org/html/rfc8447#section-5

   Per this document, a "Recommended" column has been added to many of
   the TLS registries to indicate parameters that are generally
   recommended for implementations to support.  Adding a "Recommended"
   parameter (i.e., "Y") to a registry or updating a parameter to
   "Recommended" status requires Standards Action.  Not all parameters
   defined in Standards Track documents need to be marked as
   "Recommended".

As the GOST draft has an informational header and is not a TLS WG
item, I would expect any registration to have Recommended = N.

In fact, the table is specifically missing the Recommended column
> required by the IANA Registry.
>

That seems like an omission but given the above, I expect IANA can handle
it.

> As a side not, in those Security Considerations I see:
>
> 2. 0-RTT data SHOULD NOT be sent during TLS 1.3 connection.  The
> reasons for this restriction are that the 0-RTT data is not forward
> secret and is not resistant to replay attacks
>
> It seems that the SHOULD NOT is really a very hard MUST NOT.
>

It's not clear to me if GOST is any different than the existing TLS cipher
suites in this respect, but if not, then I'm not quite sure what the
rationale is here.

-Ekr

> As another side note, would be nice to have a link to the IANA sections
> updated in the IANA Considerations Section.
>
>
> Paul
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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


On Thu, 18 Jun 2020, Eric Rescorla wrote:


The way that TLS has handled this is to have the registries have a column 
called Recommended and we just mark things Y or N. This is slightly
different from RFC 2119 language.

It's not that uncommon to have new stuff introduced with Recommended = N. In 
fact this is the likely outcome for the GOST cipher suites:
https://datatracker.ietf.org/doc/draft-smyshlyaev-tls13-gost-suites/


I don't see anything like that mentioned in the IANA Considerations
section? 
https://tools.ietf.org/html/draft-smyshlyaev-tls13-gost-suites-02#section-7

In fact, the table is specifically missing the Recommended column
required by the IANA Registry.

If we make a consistent decision regarding algorithm recommendations
IETF-wide, than I could agree with your approach. But I would like to avoid
different WGs doing slightly different things. I don't think DNSOP
(or TLS) should decide these things separately.

Perhaps SAAG could publish a generic guidance document on nation state
algorithms and their recommendations?

As a side not, in those Security Considerations I see:

   2. 0-RTT data SHOULD NOT be sent during TLS 1.3 connection.  The
   reasons for this restriction are that the 0-RTT data is not forward
   secret and is not resistant to replay attacks

It seems that the SHOULD NOT is really a very hard MUST NOT.

As another side note, would be nice to have a link to the IANA sections
updated in the IANA Considerations Section.


Paul

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

On 18 Jun 2020, at 17:16, Philip Homburg  wrote:
> 
>> basically all the domains you list here could have used one of
>> their own domains (eg local.telus.com instead of .telus, etc)
> 
> I wonder how that would interact with EU privacy regulations. In the common
> case of an ISP providing the customer with a CPE, the ISP is resposible for
> anything that goes wrong.
> 
> We can be sure that there will be plenty of queries that leak out. How does
> an ISP deal with a report that the ISP provided device leads to traffic
> going to the manufacturer of said device?
> 
> The obvious next problem is where the manufacturer registers a domain name for
> a product line and then forgets to renew the domain when the product line 
> is no longer sold.

+1

Roy

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

.gnu and .onion were never intended as private use. Gnu was meant as just 
another top level domain, and .onion is supposed to work over a (private but 
remote) network. 

Maybe “.local” would have been a candidate to use one of the iso3166-1 Alpha-2 
user assigned string.



On 18 Jun 2020, at 17:00, Paul Wouters  wrote:

> 
> On Thu, 18 Jun 2020, Roy Arends wrote:
> 
>>> To me it seems that most dnsop people (me included) do not want to 
>>> legitimize use unnecessary use of private names as it often causes 
>>> unnecessary pain down the road - but at the same time I personally 
>>> recognize the motivation for home.arpa. etc.
>> 
>> I want to recognise two points here:
>> 
>> 1) The lack of a private DNS domain is the main motivation to squat.
> 
> I would say the main motivation is a short and memorable TLD for their
> purpose. The importance here is "their purpose". Do you think tor would
> have settled for .zz instead of .onion ? Or that GNUnet people who
> wanted .gnu will settle for .zz ? And if they did, how would you expect
> browser plugins for these two _different_ uses of .zz to work?

.gnu and .onion were never intended as private use. Gnu was meant as just 
another top level domain, and .onion is supposed to work over a (private but 
remote) network. 

> i think people who want a memorable name, will still squat one, and not
> use .zz.

Yes, and folks will cross a red light and there will be collisions, instead of 
using a zebra path.

>> 2) Using a private namespace is sometimes necessary, and its use needs to be 
>> legitimised 
>> Device makers ship their device with “dlinkrouter”, “belkin”, “modem”, 
>> “gateway”; phones are shipped with “getcacheddhcpresultsforcurrentconfig”; 
>> software is shipped with default configurations like  “openstacklocal”; 
>> renowned companies advise to configure “corp” and “internal” for private 
>> use, and ISPs are shipping home routers with “.telus” and “.home”. We have 
>> all seen those examples, have frowned upon it, and rant on various lists and 
>> fora.
> 
>> These companies all had motivations to choose these labels.
> 
> basically all the domains you list here could have used one of their own
> domains (eg local.telus.com instead of .telus, etc)

You are wilfully ignoring what I wrote. I know that seems convenient, but it is 
unhelpful in this discussion. Read the “bad idea” part below for your answer.

>> I know of two (imho legitimate) reasons, having learned this from a few 
>> organisations about why they prefer a squatted domain over a registered 
>> domain:
>> 
>> They could have shipped with a label under their own brand, but that would 
>> be an astonishingly bad idea, considering the volume (reason one) and type 
>> of traffic that was meant to be private (reason two), they would receive, as 
>> all these configurations will cause something to “phone home” to them.
> 
> So why not have no local domain instead? Or just pickup the DHCP domain
> name. This is just bad software design. But this group isn't going to
> fix that.
> 
> However, if these bad engineers start using .zz for this. What will
> happen is that ISPs are going to specially handle this queries, leading
> to a new set of issues for users. For example, dropping the queries
> instead of answering NXDOMAIN.

Really? No you think you know what ISPs will do?

> Lumping all these users together in .zz is just going to make each
> individual group inside .zz want to not be there. So I don't think
> your premise of letting them squat in one place will actually end up
> happening.

It is clear to me that you haven’t read the latest version of the draft. ZZ was 
an example that I have removed.

>> Additionally, why these organisations could to tell their users to not 
>> “squat”, find a registrar, buy a domain, renew it annually, etc, these users 
>> would move on to an organisation that says “just use .internal and you’ll be 
>> fine.”.
> 
> And those same people would not pick .zz but still pick their own more
> appropriate names.

We can’t help folks wilfully ignoring traffic signs.

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

2020-06-18 Thread Philip Homburg

>But that problem is independent of the domain names used. If the CPE
>sends queries to the ISP, the deed has already been done, regardless of
>what the ISP does with the query (send it to the root, to telus.com or
>drops it)

Sending a query to the root, which is considered a collection of neutral
parties that try to respect privacy, sounds better on paper than sending
traffic to a random manufacturer without having the relevant contracts for
data processing in place.

Futhermore, for a non-existing TLD, queries don't have to go further than 
the resolver.

Of course, the ISP can try to filter those queries. But a significant 
fraction of users and/or applications use a public resolver which will not
filter.


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

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

On Thu, Jun 18, 2020 at 9:13 AM Paul Wouters  wrote:

> On Thu, 18 Jun 2020, Eric Rescorla wrote:
>
> > On Thu, Jun 18, 2020 at 6:47 AM Tim Wicinski  wrote:
> >   Eric
> >
> > One of the reasons we've published 8624 was to offer usage
> recommendations,
> > and especially this table:
> >
> > https://tools.ietf.org/html/rfc8624#page-5
> >
> > I believe I saw that one of the authors mentioned earlier they are
> looking to
> > do a -bis update, to update this table.
> >
> >
> > Thanks for the pointer. And I suppose I could live with an Informational
> RFC with a  NOT RECOMMENDED entry in this table.
>
> It would be very strange to introduce a new algorithm as NOT RECOMMENDED.
> The weakest I think we should introduce something is as MAY.
>

The way that TLS has handled this is to have the registries have a column
called Recommended and we just mark things Y or N. This is slightly
different from RFC 2119 language.

It's not that uncommon to have new stuff introduced with Recommended = N.
In fact this is the likely outcome for the GOST cipher suites:
https://datatracker.ietf.org/doc/draft-smyshlyaev-tls13-gost-suites/

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld


On Thu, 18 Jun 2020, Philip Homburg wrote:


basically all the domains you list here could have used one of
their own domains (eg local.telus.com instead of .telus, etc)


I wonder how that would interact with EU privacy regulations. In the common
case of an ISP providing the customer with a CPE, the ISP is resposible for
anything that goes wrong.

We can be sure that there will be plenty of queries that leak out. How does
an ISP deal with a report that the ISP provided device leads to traffic
going to the manufacturer of said device?

The obvious next problem is where the manufacturer registers a domain name for
a product line and then forgets to renew the domain when the product line
is no longer sold.


But that problem is independent of the domain names used. If the CPE
sends queries to the ISP, the deed has already been done, regardless of
what the ISP does with the query (send it to the root, to telus.com or
drops it)

Paul

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

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


On Thu, 18 Jun 2020, Paul Hoffman wrote:


On Jun 18, 2020, at 7:59 AM, Dmitry Belyavsky  wrote:

The 2nd registry
Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms
(https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1 
)
has the "Standards Action" update policy


I had forgotten that the DS registry is "standards action". This document shows 
why that was a bad idea.

It might be better, and faster, for this WG to adopt a one-paragraph draft that makes the 
DS registry "RFC required", like the other DNSSEC-related registries.


I agree.

However, whether it is faster for the document, I don't know. The ISE
stream is currently very slow moving. Perhaps these documents could
flow faster than the two other ISE stream ones I am I'm tracking.

I'm fine with the RFCs being standard track.

Paul

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

2020-06-18 Thread Philip Homburg

> basically all the domains you list here could have used one of
> their own domains (eg local.telus.com instead of .telus, etc)

I wonder how that would interact with EU privacy regulations. In the common
case of an ISP providing the customer with a CPE, the ISP is resposible for
anything that goes wrong.

We can be sure that there will be plenty of queries that leak out. How does
an ISP deal with a report that the ISP provided device leads to traffic
going to the manufacturer of said device?

The obvious next problem is where the manufacturer registers a domain name for
a product line and then forgets to renew the domain when the product line 
is no longer sold.

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

2020-06-18 Thread Joe Abley

Hi Ted,

On Jun 18, 2020, at 17:15, Ted Lemon  wrote:

> If we use these ccTLDs as squatting domains, that means that we’re going to 
> see a lot of traffic at the root trying to find nonexistent name servers, 
> right?  And these ccTLDs provably do not exist, right?

RFC 8198 was implemented in BIND9.12 and Unbound 1.7.0 and I think in other 
implementations too, although I don't have references immediately to hand. I 
thought I had seen the results of some experiments that tried to measure the 
effectiveness of aggressive negative caching but I can't seem to find anything 
obvious, so maybe I was mistaken.

However, I would expect that as the deployment of 8198 increases in the 
resolver population (it defaults on in BIND9 and I think Unbound too) the extra 
traffic observed at the root should trend downwards. I think it's possible that 
if the question you pose is still a concern, it's at least a concern that is 
tending to decrease over time.

> Contrariwise, home.arpa has an un-signed delegation.

[As an aside, I have some concerns about RFC 8375 and I wish I was paying more 
attention at the time it was discussed. Although I can understand some of the 
technical arguments for the delegation, I'm not especially convinced by them in 
practice, and the decision to make the unsigned delegation also a *lame* 
unsigned delegation whilst simultaneously directing all leaked queries with 
potential information about private networks to be sent to nameservers that by 
design are intended to have anonymous operators is a poor one, I think. I note 
that the security considerations section doesn't even address the potential for 
information leakage.]

> Also, what do you think the operational effect of this will be? Given that 
> these domains are currently provably nonexistent, this means that a resolver 
> looking up names in these domains will have to special-case them.

I suspect it will work like every other locally-served domain or every other 
private namespace that exists today, i.e. just fine with no configuration 
changes expected or required on dependent (downstream) DNS clients. And if 
there are new species of resolver that need to be accommodated (e.g. 
validating, hybrid stub/full service resolvers embedded in applications), 
whatever configuration or auto-discovery mechanisms are required to support 
those other locally-served zones can surely be easily extended to these 
ISO-3166-2 codes if they are used in any particular private network.

This draft describes an existing consequence of existing policy. It may be that 
Ed and Roy are the first ones to think about using them to anchor private 
namespaces, but in some sense any corner cases that need special handling today 
also needed special handling before this draft was written; we just didn't know 
it yet.

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld


On Thu, 18 Jun 2020, Roy Arends wrote:


To me it seems that most dnsop people (me included) do not want to legitimize 
use unnecessary use of private names as it often causes unnecessary pain down 
the road - but at the same time I personally recognize the motivation for 
home.arpa. etc.


I want to recognise two points here:

1) The lack of a private DNS domain is the main motivation to squat.


I would say the main motivation is a short and memorable TLD for their
purpose. The importance here is "their purpose". Do you think tor would
have settled for .zz instead of .onion ? Or that GNUnet people who
wanted .gnu will settle for .zz ? And if they did, how would you expect
browser plugins for these two _different_ uses of .zz to work?

i think people who want a memorable name, will still squat one, and not
use .zz.

2) Using a private namespace is sometimes necessary, and its use needs to be legitimised 


Device makers ship their device with “dlinkrouter”, “belkin”, “modem”, 
“gateway”; phones are shipped with “getcacheddhcpresultsforcurrentconfig”; 
software is shipped with default configurations like  “openstacklocal”; 
renowned companies advise to configure “corp” and “internal” for private use, 
and ISPs are shipping home routers with “.telus” and “.home”. We have all seen 
those examples, have frowned upon it, and rant on various lists and fora.



These companies all had motivations to choose these labels.


basically all the domains you list here could have used one of their own
domains (eg local.telus.com instead of .telus, etc)


I know of two (imho legitimate) reasons, having learned this from a few 
organisations about why they prefer a squatted domain over a registered domain:

They could have shipped with a label under their own brand, but that would be 
an astonishingly bad idea, considering the volume (reason one) and type of 
traffic that was meant to be private (reason two), they would receive, as all 
these configurations will cause something to “phone home” to them.


So why not have no local domain instead? Or just pickup the DHCP domain
name. This is just bad software design. But this group isn't going to
fix that.

However, if these bad engineers start using .zz for this. What will
happen is that ISPs are going to specially handle this queries, leading
to a new set of issues for users. For example, dropping the queries
instead of answering NXDOMAIN.

Lumping all these users together in .zz is just going to make each
individual group inside .zz want to not be there. So I don't think
your premise of letting them squat in one place will actually end up
happening.


Additionally, why these organisations could to tell their users to not “squat”, 
find a registrar, buy a domain, renew it annually, etc, these users would move 
on to an organisation that says “just use .internal and you’ll be fine.”.


And those same people would not pick .zz but still pick their own more
appropriate names.

Also, people will get confused about "zee-zee" versus "zed-zed" :)


I’d like to get this space recognised as “better than squatting”.


One bad actor using their space will mark other good actors are
potentially bad ones. I wouldn't want to share my squatting place
with sketchy individuals and protocols.

Paul

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

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

2020-06-18 Thread Jim Reid

> On 18 Jun 2020, at 16:01, Joe Abley  wrote:
> 
> On Jun 18, 2020, at 16:48, Paul Hoffman  wrote:
> 
>> Why is this WG considering making this document Standards Track instead of 
>> Informational? Also, why is the WG considering putting the document in our 
>> work stream at all? Can the WG can bring much value to the document itself? 
>> We do have lots of other things we are working on.
> 
> I think the question of the value the wg can bring is the important one.

I think we’re over-thinking this. Just issue new code point(s) for the new 
algorithm(s) and be done with it.

IMO there’s no need for the WG or the IETF to make any statements about the 
suitability of the underlying crypto used for optional signing and validation. 
That’s largely a matter for those who use these algorithms. Higher-level 
concerns about the crypto’s suitability should only come into play whenever an 
algorithm is a MUST/SHOULD recommendation in a standards-track RFC.

Maybe we need an RFC6895-like process for maintaining this IANA registry, like 
we have for RRtype codes?

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

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

2020-06-18 Thread Jim Reid



> On 18 Jun 2020, at 16:30, Paul Hoffman  wrote:
> 
> It might be better, and faster, for this WG to adopt a one-paragraph draft 
> that makes the DS registry "RFC required", like the other DNSSEC-related 
> registries.

+1



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-18 Thread Paul Hoffman

On Jun 18, 2020, at 7:59 AM, Dmitry Belyavsky  wrote:
> The 2nd registry
> Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms
> (https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1 
> )
> has the "Standards Action" update policy

I had forgotten that the DS registry is "standards action". This document shows 
why that was a bad idea.

It might be better, and faster, for this WG to adopt a one-paragraph draft that 
makes the DS registry "RFC required", like the other DNSSEC-related registries.

--Paul Hoffman

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

For what it’s worth, I am in favor of adopting this document. With that said,
however, I do have questions, Roy.

If we use these ccTLDs as squatting domains, that means that we’re going to see
a lot of traffic at the root trying to find nonexistent name servers, right?
And these ccTLDs provably do not exist, right?

Contrariwise, home.arpa has an un-signed delegation. Queries for home.arpa are
no worse than queries for any other .arpa subdomain, as far as the root is
concerned. On the other hand, perhaps they are worse for .arpa, and since in
fact .arpa is currently served by the root servers, perhaps this makes no
difference.

What’s the difference we’ll see in traffic for the root versus traffic for
.arpa if people adopt known-unused, securely nonexistent ccTLDs instead of an
un-signed delegation under .arpa?

Also, what do you think the operational effect of this will be? Given that
these domains are currently provably nonexistent, this means that a resolver
looking up names in these domains will have to special-case them. This is not
true for home.arpa. Are we okay with the operational effects of this? Or is it
a gap in the current version of your document that IANA is not instructed to
delegate these domains in the same way that home.arpa is delegated (see section
7 of RFC8375)?

Similarly, is it an omission in the current document that these domains are not
listed in the “transport-independent locally-served zones” IANA registry
(https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml)?

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

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

2020-06-18 Thread Joe Abley

On Jun 18, 2020, at 16:48, Paul Hoffman  wrote:

> Why is this WG considering making this document Standards Track instead of 
> Informational? Also, why is the WG considering putting the document in our 
> work stream at all? Can the WG can bring much value to the document itself? 
> We do have lots of other things we are working on.

I think the question of the value the wg can bring is the important one.

In this case it seems unlikely that dnsop has the expertise to review this 
document to the depths of the crypto. The degree to which the advice for DNSSEC 
implementers is clear and unambiguous can surely be assessed without putting it 
through the working group machinery.

An individual submission will still require conflict review by the IESG and 
that will involve credible DNS people to express an opinion, so there will no 
doubt be some familiar faces from dnsop that are still involved in an 
individual capacity, but I think (as I think Paul infers above) that there is 
little benefit to adding this to the workload of the wg chairs and AD if we 
don't expect the document to benefit from corresponding levels of improvement.

For what it's worth if this was to proceed on the individual submission stream 
and if the authors needed independent reviewers to express an opinion as part 
of that process I'd happily put my hand up with a DNS perspective. I almost 
certainly can't help with the crypto.

The question of how dnsop tracks algorithms that exist and whether they are 
recommended or not is reasonably separate from whether this document should be 
published, I think.

Joe

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

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

2020-06-18 Thread Valery Smyslov

Hi Paul,

> Why is this WG considering making this document Standards Track instead of 
> Informational? Also, why is the
> WG considering putting the document in our work stream at all? Can the WG can 
> bring much value to the
> document itself? We do have lots of other things we are working on.
> 
> There is no procedural need for this document to be part of the DNSOP working 
> group. In order for this
> algorithm to get an algorithm number from IANA, all that is needed is an RFC. 
> National crypto algorithms is
> one of the common use cases for the Independent Stream in the RFC Series. 
> Suggesting that the authors
> publish it there will take less time for all of us, will conceivably get it 
> published as an RFC sooner, and fulfills
> the requirement for them to get their assignment from IANA.

The draft is going to allocate a code point from the "Delegation Signer (DS) 
Resource Record (RR) Type Digest Algorithms" registry
(https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1). 
which has a "Standards Action" update policy.

It would be much easier if publication via ISE was possible.

Regards,
Valery Smyslov.

> --Paul Hoffman

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

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

2020-06-18 Thread Dmitry Belyavsky

Dear Paul,

On Thu, Jun 18, 2020 at 5:48 PM Paul Hoffman  wrote:

> Why is this WG considering making this document Standards Track instead of
> Informational? Also, why is the WG considering putting the document in our
> work stream at all? Can the WG can bring much value to the document itself?
> We do have lots of other things we are working on.
>
> There is no procedural need for this document to be part of the DNSOP
> working group. In order for this algorithm to get an algorithm number from
> IANA, all that is needed is an RFC. National crypto algorithms is one of
> the common use cases for the Independent Stream in the RFC Series.
> Suggesting that the authors publish it there will take less time for all of
> us, will conceivably get it published as an RFC sooner, and fulfills the
> requirement for them to get their assignment from IANA.
>

Unfortunately, Independent Stream is impossible for this document.

This document requires updates to 2 IANA registries:
Domain Name System Security (DNSSEC) Algorithm Numbers
(
https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml
)
has the "RFC Required" update policy

The 2nd registry
Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms
(
https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1
)
has the "Standards Action" update policy

So it makes impossible to use the Independent Stream process.

-- 
SY, Dmitry Belyavsky
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

2020-06-18 Thread Paul Hoffman

Why is this WG considering making this document Standards Track instead of 
Informational? Also, why is the WG considering putting the document in our work 
stream at all? Can the WG can bring much value to the document itself? We do 
have lots of other things we are working on.

There is no procedural need for this document to be part of the DNSOP working 
group. In order for this algorithm to get an algorithm number from IANA, all 
that is needed is an RFC. National crypto algorithms is one of the common use 
cases for the Independent Stream in the RFC Series. Suggesting that the authors 
publish it there will take less time for all of us, will conceivably get it 
published as an RFC sooner, and fulfills the requirement for them to get their 
assignment from IANA.

--Paul Hoffman

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

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

> On 18 Jun 2020, at 08:03, Petr Špaček  wrote:

>> 
>> I support adoption but share opinion that the document should not be 
>> published as is.

Ack. Please help the editors to mold it into the right structure when (if) the 
idea is adopted. And thank you for your support!

> 1. _If possible_ use a subdomain you own, it will save you headache later on 
> (e.g. when you decide to set up VPN to your supplier, but I do not insist on 
> this specific example).
> 2. If you think you need non-unique private subtree read list of problems 
> listed in ... [link to some other document] and think again.
> 3. Never ever squat
> 4. If this document did not change you mind use one of /zz/

I agree with you!

> To me it seems that most dnsop people (me included) do not want to legitimize 
> use unnecessary use of private names as it often causes unnecessary pain down 
> the road - but at the same time I personally recognize the motivation for 
> home.arpa. etc.

I want to recognise two points here:

1) The lack of a private DNS domain is the main motivation to squat.

Squatting is not a good idea.

2) Using a private namespace is sometimes necessary, and its use needs to be 
legitimised  

Device makers ship their device with “dlinkrouter”, “belkin”, “modem”, 
“gateway”; phones are shipped with “getcacheddhcpresultsforcurrentconfig”; 
software is shipped with default configurations like  “openstacklocal”; 
renowned companies advise to configure “corp” and “internal” for private use, 
and ISPs are shipping home routers with “.telus” and “.home”. We have all seen 
those examples, have frowned upon it, and rant on various lists and fora. 

These companies all had motivations to choose these labels. 

I know of two (imho legitimate) reasons, having learned this from a few 
organisations about why they prefer a squatted domain over a registered domain:

They could have shipped with a label under their own brand, but that would be 
an astonishingly bad idea, considering the volume (reason one) and type of 
traffic that was meant to be private (reason two), they would receive, as all 
these configurations will cause something to “phone home” to them. 

Additionally, why these organisations could to tell their users to not “squat”, 
find a registrar, buy a domain, renew it annually, etc, these users would move 
on to an organisation that says “just use .internal and you’ll be fine.”. 

So for now, the query stops at the root, and with a carved out space, like the 
one I’m proposing, the query stops at the root, _indefinitely_.

If the intent is that the query should never reach the root, but handled 
internally, then I get that. Maybe RFC6303 or 6761 is an option here, but you’d 
still need a legitimate private space in order not to squat. 

I’d like to get this space recognised as “better than squatting”.

Warmly, and respectfully

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

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

On Thu, Jun 18, 2020 at 6:47 AM Tim Wicinski  wrote:

> Eric
>
> One of the reasons we've published 8624 was to offer usage recommendations,
> and especially this table:
>
> https://tools.ietf.org/html/rfc8624#page-5
>
> I believe I saw that one of the authors mentioned earlier they are looking
> to
> do a -bis update, to update this table.
>

Thanks for the pointer. And I suppose I could live with an Informational
RFC with a  NOT RECOMMENDED entry in this table.

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

Re: [DNSOP] SVCB ALPN value presentation format

2020-06-18 Thread lcampbel=40akamai . com

OK, I think I now understand the intent, and refactored my code accordingly, 
and it is now simpler and cleaner. Yay.

I think it would be clearer to implementers if section 2.1.1 said that all 
values are initially parsed as character-strings (allowed to exceed 255 
characters), and then further parsed by SvcParamKey-specific parsing which may, 
for example, split on comma. I think the current text isn't entirely clear on 
the functional separation between generic parsing and key-specific parsing.

- lc


> On Jun 15, 2020, at 22:04, Mark Andrews  wrote:
> 
> 
> 
>> On 14 Jun 2020, at 05:01, Larry Campbell 
>> > > wrote:
>> 
>> I think there's an implementation difficulty. Consider:
>> 
>> 1.  alpn=h2  ; clear enough
>> 2.  alpn="h2"; should be equivalent
>> 3.  alpn=\h\2; should also be equivalent
>> 4.  alpn=h2,h3   ; ok (two values)
>> 5.  alpn="h2","h3"   ; should be equivalent
> 
> No, as it is key=quoted-string as per 2.1.1 not 
> key=quoted-string(,quoted-string\)*
> 
>> 6.  alpn="h2,h3" ; malformed? or a single alpn value of h2,h3? or two 
>> three-character values, "h2 and h3”?
> 
> this is correct
> 
>> 7.  alpn=h2\,h3,h4   ; how should this be parsed?
> 
> 0x05 0x68 0x32 0xc2 0x68 0x33 0x02 0x68 0x34
> 
>> Section 2.1.1 tempts one to build the obvious implementation of using one's 
>> existing character-string parser, and then passing the parsed 
>> character-string to the individual handler for each key type. The alpn and 
>> ipv*hint handlers are going to want to split that character-string on comma. 
>> That would treat #6 as two two-character values (h2,h3). But #7 is 
>> problematic: the generic character-string parser would remove the backslash, 
>> and then the alpn handler would treat this as three alpn values when you 
>> probably wanted just two
> 
> When you are also parsing domain names you have to deal with \. being a 
> literal period not a domain separator.
> exa\.mple.com  and “exa\.mple.com ” aree 
> being two labels ‘exa.mple’ and ‘com’.  This is not really different.
> 
> That said we do need to address this issue.
> 
> In BIND we extract quoted-string preserving the escapes (except for ‘\”’) 
> then pass the token to a domain name parser or a text parser. Having ‘key=‘ 
> preceding the quoted-string is more of a issue and we have to shift modes 
> mid-token.
> 
>> We could make a special character-string parser for alpn and ipv*hint, that 
>> handles commas, but it feels odd to have to use a special parser just for 
>> certain key types. However, if we must allow commas in alpn names, then we 
>> have no choice.
> 
> You need to reparse value for port, alpn, ipv*hint,
> 
>> Perhaps it would be clearer to simply remove the three paragraphs of section 
>> 2.1.1 beginning with "The presentation for for SvcFieldValue is..." and 
>> ending with "...not limited to 255 characters.)". Since the previous 
>> paragraph says "Values are in a format specific to the SvcParamKey", perhaps 
>> it would be best to leave the description of each value format in the 
>> appropriate part of section 6 and for section 2.1.1 to discuss only how to 
>> represent and parse unrecognized keys.
> 
> 
>> 
>> To keep the implementation simple, the alpn value could be defined as a 
>> comma-separated list of sequences of printing ASCII characters, with 
>> embedded comma represented as \, backslash as \\, and all nonprinting and 
>> non-ASCII characters reprsented as \nnn. (In other words, the full 
>> generality of character-string, particularly double-quotes, is not needed 
>> here.
>> 
>> The other comma-separated value types -- ipv4hint and ipv6hint -- do not 
>> have this difficulty; they also don't need the full generality of 
>> character-string handling, because the individual values can contain only 
>> hex digits, periods, and colons, so their specification and implementation 
>> can be much simpler.
>> 
>> And I think section 2.1.1 would be clearer if
>> 
>>   using decimal escape codes (e.g. \255) when necessary
>> 
>> were replaced by
>> 
>>   using decimal escape codes (e.g. \255) for all nonprinting and non-ASCII 
>> characters, and using \\ to represent backslash
>> 
>> - lc
>> 
>> 
>>> On Jun 13, 2020, at 11:25, Ben Schwartz 
>>>  wrote:
>>> 
>>> Larry,
>>> 
>>> I think that's the intent of the current text, especially the ABNF for 
>>> "element".  If you think it's unclear, we should adjust it.  Please suggest 
>>> text!
>>> 
>>> --Ben Schwartz
>>> 
>>> On Sat, Jun 13, 2020, 10:53 AM Larry Campbell 
>>>  wrote:
>>> Seciont 6.1 says:
>>> 
 The presentation value of "alpn" is a comma-separated list of one or more 
 "alpn-id"s. Any commas present in the protocol-id are escaped by a 
 backslash:
 
   escaped-octet = %x00-2b / "\," / %x2d-5b / "\\" / %x5D-FF
   escaped-id = 1*(escaped-octet)
   alpn-value = escaped-id *(","

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

2020-06-18 Thread Tim Wicinski

Eric

One of the reasons we've published 8624 was to offer usage recommendations,
and especially this table:

https://tools.ietf.org/html/rfc8624#page-5

I believe I saw that one of the authors mentioned earlier they are looking
to
do a -bis update, to update this table.

(But hear the rest of the message clearly)

tim



On Thu, Jun 18, 2020 at 9:42 AM Eric Rescorla  wrote:

>
>
> On Wed, Jun 17, 2020 at 8:51 PM Martin Thomson  wrote:
>
>> 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.
>>
>
> largely concur with MT and Olafur.
>
> At a high level, additional algorithms create additional complexity
> and interoperability issues. In some cases there are good reasons for
> that (for instance, one algorithm is much faster than another),
> however that does not appear to be the case here. In the past we were
> often quite liberal about standardizing national algorithms but I
> believe this was a mistake which created confusion about what
> algorithms the IETF actually was encouraging people to use. In
> addition to the factors that Martin notes, it created pressure on
> implementations to add those algorithms.
>
> I don't see any good argument for the IETF recommending that people
> adopt this algorithm, which does not seem to be in any way clearly
> superior to EdDSA and which would open the door to us recommending a
> proliferation of other national algorithms which also don't seem to
> have any real technical advantages. As MT says, the argument for
> assigning a code point while not recommending the algorithm seems
> weaker here because you want DNSSEC signed data to be universally
> verifiable.
>
> My preference would be to not publish this at all, but if it is to
> be published, do so in a way that makes clear that the IETF is just
> allocating the code point and does not recommend it.
>
> -Ekr
>
>>
>> ___
> 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] Call for Adoption: draft-belyavskiy-rfc5933-bis