Re: [DNSOP] I-D Action: draft-pwouters-powerbind-04.txt

[Vladimír Čunát]

On 5/7/20 6:06 AM, Paul Wouters wrote:
> On Tue, 5 May 2020, Vladimír Čunát wrote:
>> 1. Validation without logging.
>> At the end of 3.1 you claim that mode is still useful.  When I focus on
>> intentional attacks, signing a malicious DS seems among the easiest
>> ones, and that can't be detected without the attacked machine doing
>> logging (the DS might be served to specific targets only).
>
> Serving to specific targets is getting harder and harder, because we
> see more and more people defaulting to not use their DHCP obtained DNS
> server. And when picking another non-local server, DoH or DoT is
> preventing man in the middles from replacing DS records in responses.
>
> So they would either have to publicly replace the DS for everyone, or
> add a DS for everyone. That becomes a very visible event.

If they lie to your resolver, they replace it for everyone sharing the
same cache (for TTL duration).  So you say that people should hope that
someone else will also obtain the same "forged" DS by chance (say,
thanks to caching) and log it?  Perhaps it is an improvement... but in
me personally such a setup would not inspire confidence.

Speaking of non-DHCP DNS servers, if their provider promises to do all
the DELEGATION_ONLY validation *and* logging (and we authenticate their
servers, e.g. via TLS), that mode would actually make sense to me.  It's
a bit similar to trusting your DNS provider with DNSSEC validation and
not repeating it locally (though I personally prefer to do it again when
forwarding), but the tradeoff seems better here: security severity is
lower than bogus records and the logging surely won't be as cheap and
simple to deploy.


>>   Consequently
>> I'm doubtful about implementing and deploying such a "half-secure"
>> approach in validators, especially as the RFC draft feels very hazy
>> about the way logging might be done.
>
> This draft is not trying to specify the DNSSEC logging. But I described
> things in earlier messages already. The way we had our experimental
> logging done with Linus Nordberg, is that we used dnssec-chains (RFC
> 7901) as the record format for the DNS data, wrapped in the regular
> append-only style transparency log using merckle trees.

Perhaps it's just me, but I'd expect the RFC to contain a plan on *what*
would be logged, in connection to the security assurances this should
get us (without most of the technical details on how to do the logging
exactly).  I think you mostly confirmed what would be logged below.


>> 2. Amount of logging.
>> The draft implies it would allow to very significantly decrease the
>> amount of data that needs to be logged.  Zones without the bit perhaps
>> won't be logged, but I hope that wasn't a significant point.
>
> Right. Anything without DNSSEC cannot be helped.

To be clear, I meant the proposed DELEGATION_ONLY flag, but that
sentence doesn't seem important.


>>   The draft
>> doesn't explicitly say what would be logged; my conclusion for zones
>> using this bit is that "we" would need basically any authoritative (i.e.
>> signed) data except for NSEC* records that have DS bit and miss opt-out
>> bit.  Am I missing something?
>
> You would need to log the DS, and possibly log the denial of existence
> of the DS record. If the delegation-only bit it set, you can further log
> anything that should not have been signed but was signed, so any records
> outside of the apex that are signed. But this data is already dropped
> by supporting validators as BOGUS, so those hooks could be used for
> logging it. It should not be common. As soon as you see any of this,
> the zone is basically malicious and a public inquery should be started.
>
> As for opt-out, again zones without DNSSEC cannot be helped. Zones with
> DNSSEC, you log the DS and the denial of existence of DS.
>
> When to log this is a bit similar to the CT gossip protocol that was
> proposed. You log things when you see a modification (no-DS to DS or
> visa versa, or old-DS to new-DS). But that is outside the scope of
> this draft.

OK.  Nit: I'd expect that in practice most breakages would be
unintentional non-malicious errors, but they should still be only a tiny
fraction of all logged data (I hope).


>>   As for large TLD zones, even in best
>> currently practical case the reduction seems by less than a half? 
>
> You are missing the point that currently resolvers cannot determine if
> a TLD is delegation-only. For example, if you assume all TLDs are
> delegation-only, you break things, such as .de where registrations can
> be done without NS record, straight signed by the .de key. The point of
> the DNSKEY DELEGATION_ONLY flag is to indicate that yes this zone does
> not do this and THUS you can log these things when you see them.

I was aware of that (the "zones without the bit" sentence).  I just
somehow thought the plan was to significantly reduce the amount of
logging *in* the DELEGATION_ONLY zones (in some "realistic" cases).  It
seems that I haven't missed any sub

Re: [DNSOP] New draft on delegation revalidation

[Giovane C. M. Moura]

>>  Do you plan to maintain the parent/child disjoint NS 
>> domain (marigliano.xyz ) going forward? And what
>> about the test
>> domains for other types of misconfigurations?
> 
> Great idea. Let me look into this, will get back to with that.


Done. Check http://superdns.nl :)

Marco and I (mostly Marco, I've got say) set up this website and all the
delegations/records that replicates the setup of the paper.

We did under a diff domain for sake of simplicity for us and differently
from the paper, we create 4 delegations, each one corresponding to one
of the scenarios (in the paper we change the NS configurations in
between experiments, we want a static setup here for folks to test).

Hope it helps and if you need any help, let me know.

/giovane

ps: Raffaele, the first author of our paper, will present the study on
RIPE80 on Tuesday's plenary:
https://ripe80.ripe.net/programme/meeting-plan/plenary/#tue4 , in case
you want to check it out

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

Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements

[Daniel Migault]

Thanks Brian. That is really much appreciated!
Yours,

Daniel

On Thu, May 7, 2020 at 1:56 PM Brian Dickson 
wrote:

>
>
> On Mon, May 4, 2020 at 12:10 PM Tim Wicinski  wrote:
>
>>
>>
>> All,
>>
>> As we stated in the meeting and in our chairs actions, we're going to run
>> regular call for adoptions over next few months.
>> We are looking for *explicit* support for adoption.
>>
>>
>> This starts a Call for Adoption for
>> draft-mglt-dnsop-dnssec-validator-requirements
>>
>> The draft is available here:
>> https://datatracker.ietf..org/doc/draft-mglt-dnsop-dnssec-validator-requirements/
>> 
>>
>>
>> Please review this draft to see if you think it is suitable for adoption
>> by DNSOP, and comments to the list, clearly stating your view.
>>
>
> I support adoption of this draft by DNSOP.. I am willing to review.
>
> Brian
>
>
>
>> Please also indicate if you are willing to contribute text, review, etc.
>>
>> This call for adoption ends: 18 May 2020
>>
>> Thanks,
>> tim wicinski
>> DNSOP co-chair
>>
>> ___
>> 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
>


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

Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements

[Daniel Migault]

Hi Tim,

Just to clarify, I fully agree there is a lot of similarities and we will
work on it with Joe.

Yours,
Daniel

On Thu, May 7, 2020 at 8:16 PM Tim Wicinski  wrote:

>
> Daniel
>
> Thanks for taking Joe's draft under advice and I agree there is work to be
> collaborated on.
>
> Tim
> (speaking as a chair)
>
> On Thu, May 7, 2020 at 3:42 PM Joe Abley  wrote:
>
>> Hi Daniel,
>>
>> On 7 May 2020, at 15:39, Daniel Migault  wrote:
>>
>> > Thanks for putting the reference of that draft. I have always thought
>> that the draft you were mentioning was the one that became RFC7958.
>>
>> 7958 came from draft-jabley-dnssec-trust-anchor, but the confusion is
>> entirely reasonable!
>>
>> > The current draft mentions that TA should be associated with
>> bootstrapping mechanism and that boostrapping for the root zone should be
>> extended to other TA.
>>
>> Yep.
>>
>> > There are clearly some overlap between the two drafts and I also have
>> the impression the drafts can be merged.
>> > the following issue has been opened:
>> >
>> https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/7
>>
>> Happy to help with that if it's something that the authors/working group
>> decide is useful.
>>
>> I support adoption of this draft, now that I've read it properly.
>>
>>
>> Joe
>>
>

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

[DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones

[Tim Wicinski]

All,

As we stated in the meeting and in our chairs actions, we're going to run
regular call for adoptions over next few months.
We are looking for *explicit* support for adoption.


This starts a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones

The draft is available here:
https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/

Please review this draft to see if you think it is suitable for adoption
by DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 25 May 2020

Thanks,
tim wicinski
DNSOP co-chair
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc2845bis-08.txt

[Tim Wicinski]

Donald

So you're suggest hmac-sha224 is "MAY" for both Implementation and Use ?

On Mon, May 11, 2020 at 12:29 AM Donald Eastlake  wrote:

> The incremental effort to implement SHA-224 if you are implementing
> SHA-256 is miniscule. It makes no sense to me for SHA-224 to be NOT
> RECOMMENDED to use when SHA-256 is MUST implement and RECOMMENDED to use
> and you can use SHA-256 with truncation to 224 or even fewer bits.
>
> Thanks,
> Donald
> ===
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e...@gmail.com
>
>
> On Sat, May 9, 2020 at 9:52 PM Tim Wicinski  wrote:
>
>> To follow up on Stephen's comments, a table was added to 2845bis to
>> list all the algorithms that are currently in the IANA registry,
>> along with suggestions for implementation.  This was the first version:
>>
>>Requirement Name
>>--- 
>>OptionalHMAC-MD5.SIG-ALG.REG.INT
>>Optionalgss-tsig
>>Mandatory   hmac-sha1
>>Optionalhmac-sha224
>>Mandatory   hmac-sha256
>>Optionalhmac-sha384
>>Optionalhmac-sha512
>>
>> During the IESG review (I think it was the SECDIR review), there was
>> a meltdown over implementing SHA-1. But SHA-1 is in use currently.
>> My suggestion was to do a variation describing implementation use.
>> This is what I came up with(so blame me):
>>
>>   Name Implementation Use
>>    -- ---
>>   HMAC-MD5.SIG-ALG.REG.INT MAYMUST NOT
>>   gss-tsig MAYMAY
>>   hmac-sha1MUST   NOT RECOMMENDED
>>   hmac-sha224  MAYNOT RECOMMENDED
>>   hmac-sha256  MUST   RECOMMENDED
>>   hmac-sha256-128  MAYMAY
>>   hmac-sha384  MAYMAY
>>   hmac-sha384-192  MAYMAY
>>   hmac-sha512  MAYMAY
>>   hmac-sha512-256  MAYMAY
>>
>> On the use side, these are mostly guesses.   We would love to hear
>> what the WG has to say about this.
>>
>> thanks
>> tim
>>
>>
>> On Mon, May 4, 2020 at 2:07 PM Stephen Morris 
>> wrote:
>>
>>>
>>> > On 4 May 2020, at 19:00, 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-08.txt
>>> >   Pages   : 29
>>> >   Date: 2020-05-04
>>>
>>>
>>> The update addresses to the draft comments made during the IESG review.
>>> There were a fair number of these which led to a number of changes to the
>>> document.  These are listed below.
>>>
>>> One significant change is that the list of acceptable algorithms has
>>> been extended, and WG approval for this is sought.
>>>
>>> Stephen
>>>
>>>
>>>
>>>
>>> Comments from Roman Danyliw
>>> ---
>>> > ** Section 1.3.  Per “In 2017, two nameservers  strictly following
>>> that document (and the related [RFC4635]) were discovered to have security
>>> problems related to this feature”, consider providing a reference to the
>>> published vulnerabilities (i.e., CVE-2017-3142 and CVE-2017-3143)
>>>
>>> I’ve added these (and one other related CVE) as informative references.
>>> Using just the CVE number as a reference seemed a bit spartan, so I’ve
>>> added a title to each incident. As the description of the CVEs in Mitre’s
>>> database don’t contain a title (only a description, which can be rather
>>> long), I’ve taken the title from ISC’s KnowledgeBase (for the BIND CVEs)
>>> and from the Knot release notes (for the Knot CVE).
>>>
>>>
>>> > ** Section 6.  Per “SHA-1 collisions have been demonstrated so the MD5
>>> security considerations apply to SHA-1 in a similar manner.  Although
>>> support for hmac-sha1 in TSIG is still mandatory for compatibility reasons,
>>> existing uses should be replaced with hmac-sha256 or other SHA-2 digest
>>> algorithms [FIPS180-4], [RFC3874], [RFC6234].
>>> >
>>> > -- It’s worth repeating those MD5 security considerations here
>>>
>>> I’m not really keen on doing this, since the security considerations in
>>> RFC 6151 cover two paragraphs and including them - or 

Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones

[Bob Harold]

On Mon, May 11, 2020 at 1:42 PM Tim Wicinski  wrote:

>
> All,
>
> As we stated in the meeting and in our chairs actions, we're going to run
> regular call for adoptions over next few months.
> We are looking for *explicit* support for adoption.
>
>
> This starts a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> This call for adoption ends: 25 May 2020
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>
>
I support adoption and will review.

"3.  Description
An implementation of catalog zones MAY allow the catalog to contain
   other catalog zones as member zones."

It seems ok to me to allow catalog zones to include other catalog zones as
future feature, although I cannot figure out yet how that would work, but
it might conflict with:

"6.1.  Implementation Notes
   Catalog zones on secondary nameservers would have to be setup
   manually"

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc2845bis-08.txt

[Donald Eastlake]

Hi Tim,

On Mon, May 11, 2020 at 1:51 PM Tim Wicinski  wrote:

> Donald
>
> So you're suggest hmac-sha224 is "MAY" for both Implementation and Use ?
>

Yes, that would be fine.

SHA-224 is just SHA-256 with some different initial vectors and the result
truncated to 224 bits. So if you have implemented SHA-256, it takes like
0.1% more code to add SHA-224. And, while the value of SHA-224 would be
different for a particular input from the value of SHA-256 truncated to 224
bits, I don't see any reason why it would be less secure.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com

On Mon, May 11, 2020 at 12:29 AM Donald Eastlake  wrote:
>
>> The incremental effort to implement SHA-224 if you are implementing
>> SHA-256 is miniscule. It makes no sense to me for SHA-224 to be NOT
>> RECOMMENDED to use when SHA-256 is MUST implement and RECOMMENDED to use
>> and you can use SHA-256 with truncation to 224 or even fewer bits.
>>
>> Thanks,
>> Donald
>> ===
>>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>  2386 Panoramic Circle, Apopka, FL 32703 USA
>>  d3e...@gmail.com
>>
>>
>> On Sat, May 9, 2020 at 9:52 PM Tim Wicinski  wrote:
>>
>>> To follow up on Stephen's comments, a table was added to 2845bis to
>>> list all the algorithms that are currently in the IANA registry,
>>> along with suggestions for implementation.  This was the first version:
>>>
>>>Requirement Name
>>>--- 
>>>OptionalHMAC-MD5.SIG-ALG.REG.INT
>>>Optionalgss-tsig
>>>Mandatory   hmac-sha1
>>>Optionalhmac-sha224
>>>Mandatory   hmac-sha256
>>>Optionalhmac-sha384
>>>Optionalhmac-sha512
>>>
>>> During the IESG review (I think it was the SECDIR review), there was
>>> a meltdown over implementing SHA-1. But SHA-1 is in use currently.
>>> My suggestion was to do a variation describing implementation use.
>>> This is what I came up with(so blame me):
>>>
>>>   Name Implementation Use
>>>    -- ---
>>>   HMAC-MD5.SIG-ALG.REG.INT MAYMUST NOT
>>>   gss-tsig MAYMAY
>>>   hmac-sha1MUST   NOT RECOMMENDED
>>>   hmac-sha224  MAYNOT RECOMMENDED
>>>   hmac-sha256  MUST   RECOMMENDED
>>>   hmac-sha256-128  MAYMAY
>>>   hmac-sha384  MAYMAY
>>>   hmac-sha384-192  MAYMAY
>>>   hmac-sha512  MAYMAY
>>>   hmac-sha512-256  MAYMAY
>>>
>>> On the use side, these are mostly guesses.   We would love to hear
>>> what the WG has to say about this.
>>>
>>> thanks
>>> tim
>>>
>>>
>>> On Mon, May 4, 2020 at 2:07 PM Stephen Morris 
>>> wrote:
>>>

 > On 4 May 2020, at 19:00, 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-08.txt
 >   Pages   : 29
 >   Date: 2020-05-04


 The update addresses to the draft comments made during the IESG
 review.  There were a fair number of these which led to a number of changes
 to the document.  These are listed below.

 One significant change is that the list of acceptable algorithms has
 been extended, and WG approval for this is sought.

 Stephen




 Comments from Roman Danyliw
 ---
 > ** Section 1.3.  Per “In 2017, two nameservers  strictly following
 that document (and the related [RFC4635]) were discovered to have security
 problems related to this feature”, consider providing a reference to the
 published vulnerabilities (i.e., CVE-2017-3142 and CVE-2017-3143)

 I’ve added these (and one other related CVE) as informative
 references.  Using just the CVE number as a reference seemed a bit spartan,
 so I’ve added a title to each incident. As the description of the CVEs in
 Mitre’s database don’t contain a title (only a description, which can be
>>

Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones

[George Michaelson]

I support adoption.

I wondered a little about "it is absolutely essential for these
transfers to be protected from unexpected modifications on the route.
So, catalog zone transfers SHOULD be authenticated using TSIG
[RFC2845]."

The use of a categorical *absolutely* and SHOULD is jarring. If this
is really categorical, the normative enforcement needs to be stronger
maybe?

I also wondered why the TTL of the RR is not held to be meaningful. It
felt like there is an opportunity to use this field but thats quibble,
the document as-is defines it as 0 and thats ok, if perhaps missing an
opportunity to use a field close to the zone being catalogued for some
purpose.

On Tue, May 12, 2020 at 3:42 AM Tim Wicinski  wrote:
>
>
> All,
>
> As we stated in the meeting and in our chairs actions, we're going to run
> regular call for adoptions over next few months.
> We are looking for *explicit* support for adoption.
>
>
> This starts a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones
>
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> This call for adoption ends: 25 May 2020
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>
>
>
> ___
> 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-toorop-dnsop-dns-catalog-zones

[John Levine]

In article  
you write:
>Please review this draft to see if you think it is suitable for adoption
>by DNSOP, and comments to the list, clearly stating your view.

It doesn't seem like a bad idea but I'm wondering who's likely to
implement it, since that makes it much more interesting.



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

Re: [DNSOP] Call for Adoption: draft-mglt-dnsop-dnssec-validator-requirements

[Loganaden Velvindron]

On Mon, May 4, 2020 at 11:10 PM Tim Wicinski  wrote:
>
>
>
> All,
>
> As we stated in the meeting and in our chairs actions, we're going to run
> regular call for adoptions over next few months.
> We are looking for *explicit* support for adoption.
>
>
> This starts a Call for Adoption for 
> draft-mglt-dnsop-dnssec-validator-requirements
>
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/
>
I support adoption of the draft and i'm willing to review it.
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>
> Please also indicate if you are willing to contribute text, review, etc.
>
> This call for adoption ends: 18 May 2020
>
> Thanks,
> tim wicinski
> DNSOP co-chair
>
> ___
> 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