Re: [DNSOP] Favor: Weigh in on draft-ietf-ipsecme-split-dns?

[Paul Wouters]

> On Nov 29, 2018, at 09:20, Mark Andrews  wrote:
> 
> You can also just publish DS records for both DNSKEY RRsets with the caveat 
> that
> both RRsets have to have all algorithms as is published in the combined DS 
> RRset.

True. But than you are publishing non-public internal network details on the 
public internet. And you still have to get different DNS groups to work 
together to update these in time. We thought it better to just whitelist the 
domains in the provisioning system and have the VPN gateway (automatically or 
manually) pull/update the proper DS records.

Paul

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

Re: [DNSOP] Favor: Weigh in on draft-ietf-ipsecme-split-dns?

[Paul Wouters]

> On Nov 29, 2018, at 08:49, Ted Lemon  wrote:


> but I'd definitely be happier if the use case were more constrained

How could the use case be more constrained without breaking functionality?


> and the implementation advice were clearer.

What is unclear ? Do you have suggested improvement text?

> One thing that I really don't like is the text that talks about users being 
> presented with confirmation messages.   That is an extremely bad message to 
> put into this document.   The user should never ever ever see an offer to 
> install one of these whitelists.   That's just the wrong UI flow.

Have you ever installed a Configuration Profile on iOS device? If your profile 
contains a VPN profile which contains a PkCS12 it will warn (entity installing 
this can monitor all your traffic) and show you the root CA.

The idea of the text is that this can be similarly done and warning you about 
the domains whitelisted. That would help if it suddenly lists gmail.com or 
yahoo.com. I believe this adds value and is better than not presenting the 
whitelist. Ignorant users will just click click click regardless and 
knowledgeable users can go “wait a minute”

Paul


> 
>> On Wed, Nov 28, 2018 at 4:54 PM Warren Kumari  wrote:
>> So, thank you everyone for commenting / the feedback...
>> 
>> I've been mulling this over, and, while I really don't like it, I think that 
>> the:
>> "IKE clients willing to accept INTERNAL_DNSSEC_TA attributes MUST use
>> a whitelist of one or more domains that can be updated out of band.
>> IKE clients with an empty whitelist MUST NOT use any
>> INTERNAL_DNSSEC_TA attributes received over IKE.  Such clients MAY
>> interpret receiving an INTERNAL_DNSSEC_TA attribute for a non-
>> whitelisted domain as an indication that their local configuration
>> may need to be updated out of band."
>> 
>> helps mitigate this -- as Tero says above, the user would have to jump 
>> through many stupid hoops in order to make themselves vulnerable.
>> If think that if the text around "that can be updated out of band" were 
>> strengthened (the current wording sounds like being updated out of band is 
>> one option, but e.g being updated in-band and "approved" by the user is 
>> another), and it were made a bit clearer how the whitelist might be managed 
>> I'd be (grudgingly) willing to remove my DISCUSS.
>> 
>> Again, I don't love this, but I think that the mitigations can be made to 
>> work, and it *does* solve a real world problem.
>> 
>> Can anyone *not* live with this?
>> W
>> 
>> 
>>> On Wed, Nov 28, 2018 at 8:12 AM Tero Kivinen  wrote:
>>> Tony Finch writes:
>>> > Joe Abley  wrote:
>>> > >
>>> > > It seems to me that the intended use-case is access to corporate-like
>>> > > network environments where intranet.corporate-like.com might exist on
>>> > > the inside but not on the outside.
>>> > 
>>> > More likely cases like corporate-like.local or corporate-like.int or
>>> > like.corp etc. usw. :-(
>>> 
>>> Yes, this is the more common practice to use. I.e., several companies
>>> quite often have (multiple) internal domains they use. Because those
>>> are internal domains they cannot get real certificates for them.
>>> Because they cannot use real certificates they use self signed
>>> certificates, thus users have to click on "trust this web site having
>>> invalid certificate yes/no". The idea is that with TLSA we could get
>>> some kind of security for those internal sites.
>>> 
>>> More competent companies might also run their own CA and use that to
>>> sign internal web sites, but unfortunately those more competent
>>> companies usually then also have heavy IT processes that requires all
>>> kind of complicated stuff to get things be signed by corporate CA, and
>>> then developers setting up intranet / chat system / testing setup etc
>>> revert to self signed certificates, because it is easy. On the other
>>> hand getting DNS names added to the internal DNS is usually something
>>> that happens often, and is not too hard to do, getting TLSA record
>>> along with the name should also be quite easy.
>>> 
>>> Now when browsers start to make it harder and harder to allow access
>>> to self signed certificates, users are seeing more and more problems
>>> with that.
>>> 
>>> > Private DNSSEC trust anchors should be distributed in the same way
>>> > that you would distribute corporate X.509 trust anchors.
>>> 
>>> This is exactly what is proposed by the draft, execpt that it is split
>>> in two parts, i.e., the names for which TAs can be given are
>>> distributed in same way as X.509 trust anchors, the actual contents
>>> for the TA for that whitelisted name is distributed inside IKE.
>>> 
>>> The draft requires the whitelist to pre-configured before starting up
>>> the VPN connection. It also do require implementations to ignore all
>>> those settings unless user have explictly configured split-tunnel on
>>> for that connection.
>>> 
>>> I.e., in the example the VPNs-R-Us would not be able to set 

Re: [DNSOP] Favor: Weigh in on draft-ietf-ipsecme-split-dns?

[Mark Andrews]

> On 29 Nov 2018, at 11:47 am, Paul Wouters  wrote:
> 
> On Nov 29, 2018, at 04:53, Warren Kumari  wrote:
> 
>> 
>> helps mitigate this -- as Tero says above, the user would have to jump 
>> through many stupid hoops in order to make themselves vulnerable.
> 
> That’s what we came up with when we talked to ekr.
> 
>> If think that if the text around "that can be updated out of band" were 
>> strengthened (the current wording sounds like being updated out of band is 
>> one option, but e.g being updated in-band and "approved" by the user is 
>> another), and it were made a bit clearer how the whitelist might be managed 
>> I'd be (grudgingly) willing to remove my DISCUSS.
> 
> I have no problem making that text stronger / clearer.
> 
>> Again, I don't love this, but I think that the mitigations can be made to 
>> work, and it *does* solve a real world problem.
> 
> Yes, if we want enterprises to deploy DNSSEC, we need this. The 
> internal/external views are almost always administrated by a different party, 
> so the likelihood of sharing private key is extremely unlikely (plus we would 
> be telling them how to run their infrastructure). 

You can also just publish DS records for both DNSKEY RRsets with the caveat that
both RRsets have to have all algorithms as is published in the combined DS 
RRset.

>> Can anyone *not* live with this?
>> W
> 
> I’m fine with the phrasing changes you are requesting.
> 
> Paul
> 
>> 
>> On Wed, Nov 28, 2018 at 8:12 AM Tero Kivinen  wrote:
>> Tony Finch writes:
>> > Joe Abley  wrote:
>> > >
>> > > It seems to me that the intended use-case is access to corporate-like
>> > > network environments where intranet.corporate-like.com might exist on
>> > > the inside but not on the outside.
>> > 
>> > More likely cases like corporate-like.local or corporate-like.int or
>> > like.corp etc. usw. :-(
>> 
>> Yes, this is the more common practice to use. I.e., several companies
>> quite often have (multiple) internal domains they use. Because those
>> are internal domains they cannot get real certificates for them.
>> Because they cannot use real certificates they use self signed
>> certificates, thus users have to click on "trust this web site having
>> invalid certificate yes/no". The idea is that with TLSA we could get
>> some kind of security for those internal sites.
>> 
>> More competent companies might also run their own CA and use that to
>> sign internal web sites, but unfortunately those more competent
>> companies usually then also have heavy IT processes that requires all
>> kind of complicated stuff to get things be signed by corporate CA, and
>> then developers setting up intranet / chat system / testing setup etc
>> revert to self signed certificates, because it is easy. On the other
>> hand getting DNS names added to the internal DNS is usually something
>> that happens often, and is not too hard to do, getting TLSA record
>> along with the name should also be quite easy.
>> 
>> Now when browsers start to make it harder and harder to allow access
>> to self signed certificates, users are seeing more and more problems
>> with that.
>> 
>> > Private DNSSEC trust anchors should be distributed in the same way
>> > that you would distribute corporate X.509 trust anchors.
>> 
>> This is exactly what is proposed by the draft, execpt that it is split
>> in two parts, i.e., the names for which TAs can be given are
>> distributed in same way as X.509 trust anchors, the actual contents
>> for the TA for that whitelisted name is distributed inside IKE.
>> 
>> The draft requires the whitelist to pre-configured before starting up
>> the VPN connection. It also do require implementations to ignore all
>> those settings unless user have explictly configured split-tunnel on
>> for that connection.
>> 
>> I.e., in the example the VPNs-R-Us would not be able to set those
>> configuration settings, nor would it be able to provide dialog asking
>> that.
>> 
>> VPN-R-Us would require provide instructions how to configure your VPN
>> client to do that, i.e., it would need to ask users to do following:
>> 
>>   - In your IPsec VPN configuration dialog click "Add" to add new VPN. 
>>   - Type in VPNs-R-Us for name, and IP of f00::BA5 as IP-address.
>>   - Click advanced
>>   - In Advanced settings to go the enterprise VPN tab
>>   - In there click the Enable Split-tunnel setup check box.
>>   - Answer YES to question verifying that you really want to configure
>> this manually, and do not want to use the managment profile
>> provided by the enterprise (normally enterprise VPN setups are
>> managed automatically by profiles provided by the company, normal
>> users usually do not even have option to change anything).
>>   - After that click "Add items to DNSSEC whitelist".
>>   - Type in "farfetch.com", and click OK.
>>   - (vpn client would probably forbid him adding .com to list as or if
>> it is added it would be ignored), so VPN-R-Us is smart and asks
>> following:

Re: [DNSOP] Favor: Weigh in on draft-ietf-ipsecme-split-dns?

[Paul Wouters]

On Nov 29, 2018, at 04:53, Warren Kumari  wrote:
> 
> 
> helps mitigate this -- as Tero says above, the user would have to jump 
> through many stupid hoops in order to make themselves vulnerable.

That’s what we came up with when we talked to ekr.

> If think that if the text around "that can be updated out of band" were 
> strengthened (the current wording sounds like being updated out of band is 
> one option, but e.g being updated in-band and "approved" by the user is 
> another), and it were made a bit clearer how the whitelist might be managed 
> I'd be (grudgingly) willing to remove my DISCUSS.

I have no problem making that text stronger / clearer.

> Again, I don't love this, but I think that the mitigations can be made to 
> work, and it *does* solve a real world problem.

Yes, if we want enterprises to deploy DNSSEC, we need this. The 
internal/external views are almost always administrated by a different party, 
so the likelihood of sharing private key is extremely unlikely (plus we would 
be telling them how to run their infrastructure). 

> Can anyone *not* live with this?
> W

I’m fine with the phrasing changes you are requesting.

Paul

> 
>> On Wed, Nov 28, 2018 at 8:12 AM Tero Kivinen  wrote:
>> Tony Finch writes:
>> > Joe Abley  wrote:
>> > >
>> > > It seems to me that the intended use-case is access to corporate-like
>> > > network environments where intranet.corporate-like.com might exist on
>> > > the inside but not on the outside.
>> > 
>> > More likely cases like corporate-like.local or corporate-like.int or
>> > like.corp etc. usw. :-(
>> 
>> Yes, this is the more common practice to use. I.e., several companies
>> quite often have (multiple) internal domains they use. Because those
>> are internal domains they cannot get real certificates for them.
>> Because they cannot use real certificates they use self signed
>> certificates, thus users have to click on "trust this web site having
>> invalid certificate yes/no". The idea is that with TLSA we could get
>> some kind of security for those internal sites.
>> 
>> More competent companies might also run their own CA and use that to
>> sign internal web sites, but unfortunately those more competent
>> companies usually then also have heavy IT processes that requires all
>> kind of complicated stuff to get things be signed by corporate CA, and
>> then developers setting up intranet / chat system / testing setup etc
>> revert to self signed certificates, because it is easy. On the other
>> hand getting DNS names added to the internal DNS is usually something
>> that happens often, and is not too hard to do, getting TLSA record
>> along with the name should also be quite easy.
>> 
>> Now when browsers start to make it harder and harder to allow access
>> to self signed certificates, users are seeing more and more problems
>> with that.
>> 
>> > Private DNSSEC trust anchors should be distributed in the same way
>> > that you would distribute corporate X.509 trust anchors.
>> 
>> This is exactly what is proposed by the draft, execpt that it is split
>> in two parts, i.e., the names for which TAs can be given are
>> distributed in same way as X.509 trust anchors, the actual contents
>> for the TA for that whitelisted name is distributed inside IKE.
>> 
>> The draft requires the whitelist to pre-configured before starting up
>> the VPN connection. It also do require implementations to ignore all
>> those settings unless user have explictly configured split-tunnel on
>> for that connection.
>> 
>> I.e., in the example the VPNs-R-Us would not be able to set those
>> configuration settings, nor would it be able to provide dialog asking
>> that.
>> 
>> VPN-R-Us would require provide instructions how to configure your VPN
>> client to do that, i.e., it would need to ask users to do following:
>> 
>>   - In your IPsec VPN configuration dialog click "Add" to add new VPN. 
>>   - Type in VPNs-R-Us for name, and IP of f00::BA5 as IP-address.
>>   - Click advanced
>>   - In Advanced settings to go the enterprise VPN tab
>>   - In there click the Enable Split-tunnel setup check box.
>>   - Answer YES to question verifying that you really want to configure
>> this manually, and do not want to use the managment profile
>> provided by the enterprise (normally enterprise VPN setups are
>> managed automatically by profiles provided by the company, normal
>> users usually do not even have option to change anything).
>>   - After that click "Add items to DNSSEC whitelist".
>>   - Type in "farfetch.com", and click OK.
>>   - (vpn client would probably forbid him adding .com to list as or if
>> it is added it would be ignored), so VPN-R-Us is smart and asks
>> following:
>>   - Type in "paypal.com" and click OK.
>>   - Click OK to few times and get the VPN configuration setup.
>>   - Then fire up the VPN client.
>> 
>> More likely VPN-R-Us would say if you do not want to do that, just
>> download this easy binary exe that will do all 

Re: [DNSOP] Request for Adoption (draft-moura-dnsop-authoritative-recommendations)

[John Levine]

In article  
you write:
>-=-=-=-=-=-
>Do you have any authoritative server operators that have signed on to these
>recommendations other than the authors?

I run authoritative servers for about 500 small domains, but I suspect
I am not the operator you are looking for.

Perhaps a next step would be to clarify what kind of server operators
this advice is intended for, or perhaps different parts of it are
intended for different kinds of operators.  I doubt I will ever use
anycast, but the advice on latency and TTL might be useful to my
smallish setup.

R's,
John

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

Re: [DNSOP] Favor: Weigh in on draft-ietf-ipsecme-split-dns?

[Warren Kumari]

So, thank you everyone for commenting / the feedback...

I've been mulling this over, and, while I really don't like it, I think
that the:
"IKE clients willing to accept INTERNAL_DNSSEC_TA attributes MUST use
a whitelist of one or more domains that can be updated out of band.
IKE clients with an empty whitelist MUST NOT use any
INTERNAL_DNSSEC_TA attributes received over IKE.  Such clients MAY
interpret receiving an INTERNAL_DNSSEC_TA attribute for a non-
whitelisted domain as an indication that their local configuration
may need to be updated out of band."

helps mitigate this -- as Tero says above, the user would have to jump
through many stupid hoops in order to make themselves vulnerable.
If think that if the text around "that can be updated out of band" were
strengthened (the current wording sounds like being updated out of band is
one option, but e.g being updated in-band and "approved" by the user is
another), and it were made a bit clearer how the whitelist might be managed
I'd be (grudgingly) willing to remove my DISCUSS.

Again, I don't love this, but I think that the mitigations can be made to
work, and it *does* solve a real world problem.

Can anyone *not* live with this?
W


On Wed, Nov 28, 2018 at 8:12 AM Tero Kivinen  wrote:

> Tony Finch writes:
> > Joe Abley  wrote:
> > >
> > > It seems to me that the intended use-case is access to corporate-like
> > > network environments where intranet.corporate-like.com might exist on
> > > the inside but not on the outside.
> >
> > More likely cases like corporate-like.local or corporate-like.int or
> > like.corp etc. usw. :-(
>
> Yes, this is the more common practice to use. I.e., several companies
> quite often have (multiple) internal domains they use. Because those
> are internal domains they cannot get real certificates for them.
> Because they cannot use real certificates they use self signed
> certificates, thus users have to click on "trust this web site having
> invalid certificate yes/no". The idea is that with TLSA we could get
> some kind of security for those internal sites.
>
> More competent companies might also run their own CA and use that to
> sign internal web sites, but unfortunately those more competent
> companies usually then also have heavy IT processes that requires all
> kind of complicated stuff to get things be signed by corporate CA, and
> then developers setting up intranet / chat system / testing setup etc
> revert to self signed certificates, because it is easy. On the other
> hand getting DNS names added to the internal DNS is usually something
> that happens often, and is not too hard to do, getting TLSA record
> along with the name should also be quite easy.
>
> Now when browsers start to make it harder and harder to allow access
> to self signed certificates, users are seeing more and more problems
> with that.
>
> > Private DNSSEC trust anchors should be distributed in the same way
> > that you would distribute corporate X.509 trust anchors.
>
> This is exactly what is proposed by the draft, execpt that it is split
> in two parts, i.e., the names for which TAs can be given are
> distributed in same way as X.509 trust anchors, the actual contents
> for the TA for that whitelisted name is distributed inside IKE.
>
> The draft requires the whitelist to pre-configured before starting up
> the VPN connection. It also do require implementations to ignore all
> those settings unless user have explictly configured split-tunnel on
> for that connection.
>
> I.e., in the example the VPNs-R-Us would not be able to set those
> configuration settings, nor would it be able to provide dialog asking
> that.
>
> VPN-R-Us would require provide instructions how to configure your VPN
> client to do that, i.e., it would need to ask users to do following:
>
>   - In your IPsec VPN configuration dialog click "Add" to add new VPN.
>   - Type in VPNs-R-Us for name, and IP of f00::BA5 as IP-address.
>   - Click advanced
>   - In Advanced settings to go the enterprise VPN tab
>   - In there click the Enable Split-tunnel setup check box.
>   - Answer YES to question verifying that you really want to configure
> this manually, and do not want to use the managment profile
> provided by the enterprise (normally enterprise VPN setups are
> managed automatically by profiles provided by the company, normal
> users usually do not even have option to change anything).
>   - After that click "Add items to DNSSEC whitelist".
>   - Type in "farfetch.com", and click OK.
>   - (vpn client would probably forbid him adding .com to list as or if
> it is added it would be ignored), so VPN-R-Us is smart and asks
> following:
>   - Type in "paypal.com" and click OK.
>   - Click OK to few times and get the VPN configuration setup.
>   - Then fire up the VPN client.
>
> More likely VPN-R-Us would say if you do not want to do that, just
> download this easy binary exe that will do all that configuration for
> you (and some others they do 

Re: [DNSOP] Request for Adoption (draft-moura-dnsop-authoritative-recommendations)

[Joe Abley]

Hey Giovane,

On 28 Nov 2018, at 04:55, Giovane Moura  wrote:

> We have a new draft and we'd like to ask the WG to adopt it:
> 
> https://datatracker.ietf.org/doc/draft-moura-dnsop-authoritative-recommendations/
> 
> This is an informational draft that presents recommendations for
> authoritative DNS operators, based on research works we have been
> conducting over the last few years.

I have read this document. This is not a detailed review, just a more general 
reaction to the adoption question.

This document reads a bit like it wants to give operational advice but in fact 
it seems much more like a literature review that has been culturally adapted to 
an IETF audience. This is not intended to be a negative comment; I think the 
references and the context are useful and I think it's a great idea to find a 
way to push pointers to operational research into the RFC series, but I think 
it would be as well to make it clear that the operational advice contained 
within is not comprehensive and in many cases is quite superficial. I can give 
examples if you want more detail.

I also think that the document is not clear on what problem it is solving; in 
particular, it doesn't define "performance". It's inferred that the performance 
metric that matters is round-trip query latency for some nominal client at an 
average distance; what if the operator's priority is availability? That makes 
R1 potentially bad advice; no doubt there are other motivations that would also 
not fit the recommendations convincingly.

Much of the document is specifically concerned with the implementation of 
anycast strategies for DNS, not with authoritative DNS in particular. The 
advice would hold for any stateless (or short-duration transaction, where short 
is relative to routing stability). One direction the authors might consider 
taking this is to update the advice in RFC 4786 with reference to the 
repeatable experiments that you cite. Ironically 4786 was criticised for being 
a document about DNS that was pretending to be more general; perhaps when 
welded to your document the result would be more pleasantly neutral :-)


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

Re: [DNSOP] Request for Adoption (draft-moura-dnsop-authoritative-recommendations)

[Töma Gavrichenkov]

Hello Giovane,

On Wed, Nov 28, 2018 at 12:56 PM Giovane Moura  wrote:
> This is an informational draft that presents recommendations for
> authoritative DNS operators, based on research works we have been
> conducting over the last few years.

Thank you for sharing this!

A few suggestions:

> 5. R4 [..]
>  -  It can withdraw or pre-prepend its route to some or to all of its
>  neighbors, shrinking its catchment (the number of clients that BGP
>  maps to it), shifting both legitimate and attack traffic to other
>  anycast sites.  The other sites will hopefully have greater
>  capacity and be able to service the queries.

Not necessarily so.
First, one can (may?) use BGP communities to limit the route
announcement propagation, thus making the distribution between sites
more even.
Second, Flowspec/DOTS/selective BH/et cetera.

> 6. R5 [..]

Shouldn't we wait before the faith of draft-ietf-dnsop-serve-stale is
determined? The outcome of this one may be then heavily influenced.

Anyway, it's not quite clear what this section suggests. Should I set
the TTL to 10s? What are the consequences of that? How's that related
to my threat model?

> 2: R1 [..]
(yes, out of order)

Well, *one* (and there may be more) of the reasons to maintain
authoritative servers with uneven latency distribution may be to have
a) some fast servers you can afford to get brought down by a DDoS
attack, b) a "lightning rod" — a purposefully degraded absorber,
mentioned in (5).

> 2: R1 [..]
> But the distribution of queries tend to be skewed towards authoritatives with 
> lower

There's a reason for that that you may want to mention, namely, smoothed RTT.

| Töma Gavrichenkov
| gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
| mailto: xima...@gmail.com
| fb: ximaera
| telegram: xima_era
| skype: xima_era
| tel. no: +7 916 515 49 58

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

Re: [DNSOP] Request for Adoption (draft-moura-dnsop-authoritative-recommendations)

[Paul Ebersman]

moura> We have a new draft and we'd like to ask the WG to adopt it:
 
moura> 
[[https://datatracker..ietf.org/doc/draft-moura-dnsop-authoritative-recommendations/]]
 
msj> Do you have any authoritative server operators that have signed on
msj> to these recommendations other than the authors?

I'll be going through it. $DAYJOB includes gTLD, ccTLD and second level
domains (Neustar).

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

[DNSOP] FW: New Version Notification for draft-mglt-dnsop-dnssec-validator-requirements-07.txt

[Daniel Migault]

Hi, 

Please find an updated version of the DNSSEC validator requirements document. 
The document reflect discussions we had in the Montreal and Bangkok meeting. 
In particular we describe the DNSSEC trust model. We suppose that is an 
important piece DNSSEC resolver operators needs to understand.  We reduce the 
number of requirements to remain more aligned with the DNSSEC architecture.  
Overall the document seems reasonable to us.  

Feed backs are always welcome!

Yours, 
Daniel

-Original Message-
From: internet-dra...@ietf.org  
Sent: Wednesday, November 28, 2018 1:02 PM
To: Edward Lewis ; Daniel Migault 
; Dan York 
Subject: New Version Notification for 
draft-mglt-dnsop-dnssec-validator-requirements-07.txt


A new version of I-D, draft-mglt-dnsop-dnssec-validator-requirements-07.txt
has been successfully submitted by Daniel Migault and posted to the IETF 
repository.

Name:   draft-mglt-dnsop-dnssec-validator-requirements
Revision:   07
Title:  DNSSEC Validator Requirements
Document date:  2018-11-28
Group:  Individual Submission
Pages:  17
URL:
https://www.ietf.org/internet-drafts/draft-mglt-dnsop-dnssec-validator-requirements-07.txt
Status: 
https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/
Htmlized:   
https://tools.ietf.org/html/draft-mglt-dnsop-dnssec-validator-requirements-07
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-mglt-dnsop-dnssec-validator-requirements
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-mglt-dnsop-dnssec-validator-requirements-07

Abstract:
   The DNS Security Extensions define a process for validating received
   data and assert them authentic and complete as opposed to forged.

   This document describes what is needed in implementations to make the
   validation process manageable Considerations for accurate time as
   well as management of the trust anchor store.


  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

Re: [DNSOP] Request for Adoption (draft-moura-dnsop-authoritative-recommendations)

[StJohns, Michael]

Hi -

Do you have any authoritative server operators that have signed on to these
recommendations other than the authors?  if not, I’d suggest deferring this
as a WG document pending some buy in from a few ops that are using these
recommendations and can provide some real world context.  E.g. how does
research translate to reality here?

Just a thought - Mike

On Wed, Nov 28, 2018 at 04:56 Giovane Moura  wrote:

> Folks,
>
> We have a new draft and we'd like to ask the WG to adopt it:
>
>*
>
> https://datatracker.ietf.org/doc/draft-moura-dnsop-authoritative-recommendations/
>
> This is an informational draft that presents recommendations for
> authoritative DNS operators, based on research works we have been
> conducting over the last few years.
>
> We are using Github to edit this draft as well:
>
> https://github.com/gmmoura/draft-moura-dnsop-authoritative-recommendations
>
> Thanks,
>
> /giovane
> ___
> 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] RFC 8501 on Reverse DNS in IPv6 for Internet Service Providers

[rfc-editor]

A new Request for Comments is now available in online RFC libraries.


RFC 8501

Title:  Reverse DNS in IPv6 for 
Internet Service Providers 
Author: L. Howard
Status: Informational
Stream: IETF
Date:   November 2018 
Mailbox:lee.how...@retevia.net
Pages:  15
Characters: 34189
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-dnsop-isp-ip6rdns-07.txt

URL:https://www.rfc-editor.org/info/rfc8501

DOI:10.17487/RFC8501

In IPv4, Internet Service Providers (ISPs) commonly provide
IN-ADDR.ARPA information for their customers by prepopulating the zone
with one PTR record for every available address.  This practice does
not scale in IPv6.  This document analyzes different approaches and
considerations for ISPs in managing the IP6.ARPA zone.

This document is a product of the Domain Name System Operations Working Group 
of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


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

Re: [DNSOP] [Ext] Alexey Melnikov's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

[Jim Hague]

On 28/11/2018 14:45, Alexey Melnikov wrote:
> On Wed, Nov 28, 2018, at 1:38 PM, Sara Dickinson wrote:

>> Paul is correct in that the _intention_ of including these fields is
>> just to provide informational meta data about the capturing process. I
>> would suggest we change the first sentence of the section to be:
>>
>> “Parameters providing information to how data in the file was
>> collected (applicable for some, but not all collection environments).
>> The values are informational only and serve as hints to downstream
>> analysers as to the configuration of a collecting implementation. They
>> can provide context when interpreting what data is present/absent from
>> the capture but cannot necessarily be validated against the data
>> captured.”
> I can live with that, but I would like you to in particular add a note
> that pcap filter value should not be trusted, as it effectively can
> contain arbitrary text string.

OK, thanks. We will do that.

>> Given that, I’m hoping the short reference is
>> acceptable http://www.tcpdump.org/manpages/pcap-filter.7.html? 
> Yes.

Thanks.
-- 
Jim Hague - j...@sinodun.com  Never trust a computer you can't lift.

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

Re: [DNSOP] [Ext] Alexey Melnikov's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

[Alexey Melnikov]

On Wed, Nov 28, 2018, at 1:38 PM, Sara Dickinson wrote:
> 
>> *From: *Paul Hoffman 
>> *Subject: **Re: [DNSOP] [Ext] Alexey Melnikov's Discuss on 
>> draft-ietf-dnsop-dns-capture-format-
>> 08: (with DISCUSS and COMMENT)*>> *Date: *27 November 2018 at 14:59:51 GMT
>> *To: *Alexey Melnikov 
>> *Cc: *dnsop , The IESG 
>> 
>> On Nov 27, 2018, at 3:05 AM, Alexey Melnikov
>>  wrote:>>> 
>>> On Tue, Nov 27, 2018, at 2:10 AM, Paul Hoffman wrote:
  | filter   | O | T | "tcpdump" [pcap] style filter
  | for  |  |  |   |   | input.
  |  |   |   | | 
 
 On Nov 26, 2018, at 6:05 PM, Warren Kumari 
 wrote:> ... that is where we started.
> The concern was what happens if there are new filters added, and
> implementations written don't know how to deal with them. 
 New filters being added to tcpdump (or even removed) doesn't
 affect a C- DNS application from reading or writing that field. It's 
 just
 a text string. 
>>> 
>>> I think this depends on how the field is used.
>>> 
>>> If you want to write an application that validates or does something
>>> with this field, that wouldn't be true.>>> If you think that writing such 
>>> an application is a dumb idea, then
>>> the draft should clearly state that.>> 
>> My interpretation of the spec has been all along that this field, as
>> well as the other fields in CollectionParameters, were informational
>> for whomever is looking at the particular capture. "Parameters
>> relating to how data in the file was collected" seemed sufficient for
>> that. If the authors added "These parameters are informational are
>> only informational and cannot necessarily be validated by looking in
>> the data captured", would that satisfy your concern?> 
> Paul is correct in that the _intention_ of including these fields is
> just to provide informational meta data about the capturing process. I
> would suggest we change the first sentence of the section to be:> 
> “Parameters providing information to how data in the file was
> collected (applicable for some, but not all collection environments).
> The values are informational only and serve as hints to downstream
> analysers as to the configuration of a collecting implementation. They
> can provide context when interpreting what data is present/absent from
> the capture but cannot necessarily be validated against the data
> captured.”I can live with that, but I would like you to in particular add a 
> note
that pcap filter value should not be trusted, as it effectively can
contain arbitrary text string.
> Given that, I’m hoping the short reference is acceptable
> http://www.tcpdump.org/manpages/pcap-filter.7.html?Yes.

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

Re: [DNSOP] request for adoption

[Paul Wouters]

On Tue, 27 Nov 2018, Petr Špaček wrote:


MB 7 a mailbox domain name (EXPERIMENTAL) [RFC1035] MG
8 a mail group member (EXPERIMENTAL) [RFC1035] MR 9 a
mail rename domain name (EXPERIMENTAL) [RFC1035]



Is there any *technical* use for this field? Do we need it in the YANG
model?


The technical reason would be "It's dead Jim! Don't bother implementing this"

But if people pick up the yang model and it has all these obsolete
entries, those people in turn will start some basic implementation /
support of these. So I understand yang is not the group that should
make this decision, hence my thought of quickly adding a column to the
registry to obsolete/deprecate so that yang can skip these.


Maybe we can just omit it while transforming the registry into model and
be done with it ...


But then people think the yang model is incomplete?

Paul

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

Re: [DNSOP] [Ext] Alexey Melnikov's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

[Sara Dickinson]

> From: Paul Hoffman 
> Subject: Re: [DNSOP] [Ext] Alexey Melnikov's Discuss on 
> draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)
> Date: 27 November 2018 at 14:59:51 GMT
> To: Alexey Melnikov 
> Cc: dnsop , The IESG 
> 
> On Nov 27, 2018, at 3:05 AM, Alexey Melnikov  wrote:
>> 
>> On Tue, Nov 27, 2018, at 2:10 AM, Paul Hoffman wrote:
>>>  | filter   | O | T | "tcpdump" [pcap] style filter for  |
>>>  |  |   |   | input. |
>>> 
>>> 
>>> On Nov 26, 2018, at 6:05 PM, Warren Kumari  wrote:
 ... that is where we started.
 The concern was what happens if there are new filters added, and 
 implementations written don't know how to deal with them.
>>> 
>>> New filters being added to tcpdump (or even removed) doesn't affect a C-
>>> DNS application from reading or writing that field. It's just a text 
>>> string. 
>> 
>> I think this depends on how the field is used.
>> 
>> If you want to write an application that validates or does something with 
>> this field, that wouldn't be true.
>> If you think that writing such an application is a dumb idea, then the draft 
>> should clearly state that.
> 
> My interpretation of the spec has been all along that this field, as well as 
> the other fields in CollectionParameters, were informational for whomever is 
> looking at the particular capture. "Parameters relating to how data in the 
> file was collected" seemed sufficient for that. If the authors added "These 
> parameters are informational are only informational and cannot necessarily be 
> validated by looking in the data captured", would that satisfy your concern?

Paul is correct in that the _intention_ of including these fields is just to 
provide informational meta data about the capturing process. I would suggest we 
change the first sentence of the section to be:

“Parameters providing information to how data in the file was collected 
(applicable for some, but not all collection environments). The values are 
informational only and serve as hints to downstream analysers as to the 
configuration of a collecting implementation. They can provide context when 
interpreting what data is present/absent from the capture but cannot 
necessarily be validated against the data captured.”

Given that, I’m hoping the short reference is acceptable 
http://www.tcpdump.org/manpages/pcap-filter.7.html? 
 

Regards

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

Re: [DNSOP] Favor: Weigh in on draft-ietf-ipsecme-split-dns?

[Tero Kivinen]

Tony Finch writes:
> Joe Abley  wrote:
> >
> > It seems to me that the intended use-case is access to corporate-like
> > network environments where intranet.corporate-like.com might exist on
> > the inside but not on the outside.
> 
> More likely cases like corporate-like.local or corporate-like.int or
> like.corp etc. usw. :-(

Yes, this is the more common practice to use. I.e., several companies
quite often have (multiple) internal domains they use. Because those
are internal domains they cannot get real certificates for them.
Because they cannot use real certificates they use self signed
certificates, thus users have to click on "trust this web site having
invalid certificate yes/no". The idea is that with TLSA we could get
some kind of security for those internal sites.

More competent companies might also run their own CA and use that to
sign internal web sites, but unfortunately those more competent
companies usually then also have heavy IT processes that requires all
kind of complicated stuff to get things be signed by corporate CA, and
then developers setting up intranet / chat system / testing setup etc
revert to self signed certificates, because it is easy. On the other
hand getting DNS names added to the internal DNS is usually something
that happens often, and is not too hard to do, getting TLSA record
along with the name should also be quite easy.

Now when browsers start to make it harder and harder to allow access
to self signed certificates, users are seeing more and more problems
with that.

> Private DNSSEC trust anchors should be distributed in the same way
> that you would distribute corporate X.509 trust anchors.

This is exactly what is proposed by the draft, execpt that it is split
in two parts, i.e., the names for which TAs can be given are
distributed in same way as X.509 trust anchors, the actual contents
for the TA for that whitelisted name is distributed inside IKE.

The draft requires the whitelist to pre-configured before starting up
the VPN connection. It also do require implementations to ignore all
those settings unless user have explictly configured split-tunnel on
for that connection.

I.e., in the example the VPNs-R-Us would not be able to set those
configuration settings, nor would it be able to provide dialog asking
that.

VPN-R-Us would require provide instructions how to configure your VPN
client to do that, i.e., it would need to ask users to do following:

  - In your IPsec VPN configuration dialog click "Add" to add new VPN. 
  - Type in VPNs-R-Us for name, and IP of f00::BA5 as IP-address.
  - Click advanced
  - In Advanced settings to go the enterprise VPN tab
  - In there click the Enable Split-tunnel setup check box.
  - Answer YES to question verifying that you really want to configure
this manually, and do not want to use the managment profile
provided by the enterprise (normally enterprise VPN setups are
managed automatically by profiles provided by the company, normal
users usually do not even have option to change anything).
  - After that click "Add items to DNSSEC whitelist".
  - Type in "farfetch.com", and click OK.
  - (vpn client would probably forbid him adding .com to list as or if
it is added it would be ignored), so VPN-R-Us is smart and asks
following:
  - Type in "paypal.com" and click OK.
  - Click OK to few times and get the VPN configuration setup.
  - Then fire up the VPN client.

More likely VPN-R-Us would say if you do not want to do that, just
download this easy binary exe that will do all that configuration for
you (and some others they do not mention).

I.e., that whitelist needs to be modified out of band. Usually it is
done by the management system taking care of the enterprise profiles,
i.e., the same program that installs X.509 roots for the company CA,
and mandates that virus checkers are up to date before allowing
connection to the corporate network, and which also configures the VPN
connection too.

If you are running that kind of programs you have already given all
control to whoever provided you that program (VPN-R-Us, or the
enterprise).

In enterprise case, you usually do not have option not to, as those
softwares come pre-installed and you cannot uninstall or not to use
them. On the other hand do not use your work laptop to go to paypal,
if you do not trust your company...

And yes, the enterprise (or VPN-R-Us) management.exe could also
install those TAs directly for the global system use without any
problems. This would not be problem for the VPN-R-Us (they would be
happy to have fake TA in your system even when you are not using their
VPN), but enterprise might not want to have its TA there when you are
not connected to its network, just to limit the exposure, and they
might want to update the TA contens, even when the whitelisted domain
name stays same.

I.e., if the TAs cannot be transmitted and agreed to be taken in use
(after comparing them to whitelist) inside the IKE, then enterprises
will 

Re: [DNSOP] request for adoption

[Ladislav Lhotka]

Petr Špaček  writes:

> On 13. 11. 18 7:03, Paul Wouters wrote:
>> On Mon, 12 Nov 2018, Ladislav Lhotka wrote:
>>> we would like to ask the working group to adopt the following I-D as a
>>> WG item:
>>>
>>> https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-00
>> 
>> I'll leave that call up to the chairs bit it sounds like a good idea.
>> 
>> I have reviewed the document.
>> 
>> First, the yand model is correct in the draft. But unfortunately, the
>> IANA registry
>> itself has flaws.
>> 
>> I am also confused by the difference between deprecated and obsoleted. I
>> guess the
>> yang model interprets the IANA regitry, but the registry has no official
>> column
>> designation for this. I wonder if it should be given one. I also then
>> suggest that
>> the terms obsoleted and deprecated be merged into one term.
>> 
>> I see some RRTYPES are listed as EXPERIMENTAL in the IANA registry while
>> these are
>> really OBSOLETED. I wonder if we can do a quick draft that moves those
>> to HISTORIC,
>> so this yang model can use the proper "obsoleted" entry for these. I am
>> referring to:
>> 
>> MB 7 a mailbox domain name (EXPERIMENTAL) [RFC1035] MG
>> 8 a mail group member (EXPERIMENTAL) [RFC1035] MR 9 a
>> mail rename domain name (EXPERIMENTAL) [RFC1035]
>
>
> Is there any *technical* use for this field? Do we need it in the YANG
> model?
>
> Maybe we can just omit it while transforming the registry into model and
> be done with it ...

FWIW, I asked IANA whether they have a fixed list of these status terms
and what is their semantics. I got one reply so far saying that they
will discuss it with YANG experts, which of course misses my point. In
YANG, status terms are reasonably well defined, so once we know what they
mean in IANA registries, we can try to map it to YANG.

BTW, there is now a proposal to introduce "preliminary" or
"experimental" status in the next version of YANG:

https://github.com/netmod-wg/yang-next/issues/59

Lada

>
> -- 
> Petr Špaček  @  CZ.NIC
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

[DNSOP] Request for Adoption (draft-moura-dnsop-authoritative-recommendations)

[Giovane Moura]

Folks,

We have a new draft and we'd like to ask the WG to adopt it:

   *
https://datatracker.ietf.org/doc/draft-moura-dnsop-authoritative-recommendations/

This is an informational draft that presents recommendations for
authoritative DNS operators, based on research works we have been
conducting over the last few years.

We are using Github to edit this draft as well:

https://github.com/gmmoura/draft-moura-dnsop-authoritative-recommendations

Thanks,

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

Re: [DNSOP] Review of draft-ietf-dnsop-rfc2845bis-02.txt

[Mukund Sivaraman]

On Mon, Nov 19, 2018 at 07:15:34PM +0530, Mukund Sivaraman wrote:
> Hi Stephen, Francis
> 
> On Mon, Nov 19, 2018 at 04:56:50AM -0800, internet-dra...@ietf.org wrote:
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> > This draft is a work item of the Domain Name System Operations WG of the 
> > IETF.
> > 
> > Title   : Secret Key Transaction Authentication for DNS 
> > (TSIG)
> > Authors : Francis Dupont
> >   Stephen Morris
> >   Paul Vixie
> >   Donald E. Eastlake 3rd
> >   Olafur Gudmundsson
> >   Brian Wellington
> > Filename: draft-ietf-dnsop-rfc2845bis-02.txt
> > Pages   : 26
> > Date: 2018-11-19


When investigating a TKEY related implementation bug, I notice that the
text in RFC 3645 is not very clearly written about prohibiting TSIG
signed responses for some error conditions (e.g., section 4.1.3 where
the writing seems to assume paragraph contexts). I recommend that you
check the various cases in RFC 3645 to make sure the protocol doesn't
allow inclusion of arbitrary or invalid request MAC in response TSIG MAC
computation, and state this so in the bis draft.

In any case, the text in the draft has to be updated for the relaxation
in RFC 3645 section 2.2. It wouldn't be so bad if the two RFCs can be
merged as part of this bis work.

Mukund

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