[DNSOP] CDS/CDNSKEY Deployment

[Eric Rescorla]

Hi folks

Does anyone have stats on the deployment of CDS and/or CDNSKEY? I see that
Chung et al. report very low deployment in 2017, but maybe things have
changed?

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

Re: [DNSOP] Question on interpretation of DO and CD

[Eric Rescorla]

Thanks for the explanation. That's super helpful.

-Ekr


On Fri, Oct 8, 2021 at 1:19 PM Mark Andrews  wrote:

> 
> 
> Yes it will be unfiltered but the point of DNSSEC is to filter out bad
> answers (that is what the ignore bogus responses achieves) and if you are
> behind a recursive server you need it to do the filtering of the answers it
> gets as you aren’t in a position to wait for the good answer as they won’t
> come to you nor are you in the position to ask the authoritatives
> directly.  It can wait for good answers by just rejecting the spoofed
> answers and continuing to listen for the real answer.
>
> --
> Mark Andrews
>
> On 9 Oct 2021, at 06:12, Eric Rescorla  wrote:
>
> 
> Hi Mark,
>
> Thanks for your response.
>
> On Wed, Oct 6, 2021 at 7:41 PM Mark Andrews  wrote:
>
>> You should also note that a validating stub resolver (or anything talking
>> through a validating resolver) should be prepared to send *both* DO and
>> DO+CD queries. There are different error conditions / threats that are
>> mitigated by each of these settings and only by trying the other on error
>> can you ensure that you have mitigated both.
>>
>> If the validating resolver is being sent spoofed/erroneous traffic DO
>> will filter that traffic out of the response stream.  DO+CD works around
>> bad time/trust-anchors in the validating resolver.
>>
>
> Can you elaborate on this a bit? I.e., if I sent DO + CD, then won't I just
> get an unfiltered view and be able to sort it out locally? What am I
> missing?
>
> -Ekr
>
> Mark
>>
>> > On 7 Oct 2021, at 10:47, Eric Rescorla  wrote:
>> >
>> > Hi folks,
>> >
>> > We've been trying to take some measurements of the success of endpoint
>> > DNSSEC validation and run into some confusion about the implications
>> > of the DO and CD bits. Sorry if these are dumb questions.
>> >
>> > In the section on stub resolvers RFC 4035 says:
>> >
>> >A validating security-aware stub resolver MUST set the DO bit,
>> >because otherwise it will not receive the DNSSEC RRs it needs to
>> >perform signature validation. (S 4.9.1)
>> >
>> > and:
>> >A validating security-aware stub resolver SHOULD set the CD bit,
>> >because otherwise the security-aware recursive name server will
>> >answer the query using the name server's local policy, which may
>> >prevent the stub resolver from receiving data that would be
>> >acceptable to the stub resolver's local policy. (S 4.9.2)
>> >
>> >
>> > And then in S 5, says:
>> >When a resolver indicates support for DNSSEC (by setting the DO bit),
>> >a security-aware name server should attempt to provide the necessary
>> >DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).
>> >
>> >
>> > Looking at things from the stub resolver's perspective, if the zone is
>> > signed, then the stub resolver must receive the necessary RRsets or
>> > fail the resolution. So, there needs to be an unambiguous way for the
>> > stub to tell the recursive to deliver them. Am I right so far?
>> >
>> > Reading the above text, I infer that this signal is the DO bit. This
>> > should cause the recursive to deliver the right RRsets (if available)
>> > (I note that this text just says "name server" from which I'm
>> > inferring that it applies to both authoritative and recursive).  Is
>> > this correct? If so, is the fact that this is "should" and not
>> > "SHOULD" telling me something"?
>> >
>> > Finally, as I understand it, the function of the CD bit is to tell the
>> > recursive resolver to return records even it if cannot validate them
>> > itself. However, it does *not* tell the recursive resolver to send the
>> > RRsets in the first place, as that's the function of CD.
>> >
>> >
>> > Summarizing all this, I have the following table of what the stub
>> > should expect to receive if the recursive is a validating resolver and
>> > it asks for an A record (just as an example)
>> >
>> >
>> > Bits set Records validRecords invalid
>> > -
>> > None A + ???Error
>> > DO   A + DNSSEC Error
>> > CD   A + ???  A + ???
>> > DO + CD  A + DNSSECA + DNSSEC
>> >
>> > Where "A + DNSSEC" means "A + plus the DNSSEC records" and "A + ???"
>> > means "A + maybe some DSNSSEC records depending on what the recursive
>> > wants".
>> >
>> > Thanks in advance,
>> > -Ekr
>> > ___
>> > DNSOP mailing list
>> > DNSOP@ietf.org
>> > https://www.ietf.org/mailman/listinfo/dnsop
>>
>> --
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>>
>>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Question on interpretation of DO and CD

[Eric Rescorla]

Hi Mark,

Thanks for your response.

On Wed, Oct 6, 2021 at 7:41 PM Mark Andrews  wrote:

> You should also note that a validating stub resolver (or anything talking
> through a validating resolver) should be prepared to send *both* DO and
> DO+CD queries. There are different error conditions / threats that are
> mitigated by each of these settings and only by trying the other on error
> can you ensure that you have mitigated both.
>
> If the validating resolver is being sent spoofed/erroneous traffic DO
> will filter that traffic out of the response stream.  DO+CD works around
> bad time/trust-anchors in the validating resolver.
>

Can you elaborate on this a bit? I.e., if I sent DO + CD, then won't I just
get an unfiltered view and be able to sort it out locally? What am I
missing?

-Ekr

Mark
>
> > On 7 Oct 2021, at 10:47, Eric Rescorla  wrote:
> >
> > Hi folks,
> >
> > We've been trying to take some measurements of the success of endpoint
> > DNSSEC validation and run into some confusion about the implications
> > of the DO and CD bits. Sorry if these are dumb questions.
> >
> > In the section on stub resolvers RFC 4035 says:
> >
> >A validating security-aware stub resolver MUST set the DO bit,
> >because otherwise it will not receive the DNSSEC RRs it needs to
> >perform signature validation. (S 4.9.1)
> >
> > and:
> >A validating security-aware stub resolver SHOULD set the CD bit,
> >because otherwise the security-aware recursive name server will
> >answer the query using the name server's local policy, which may
> >prevent the stub resolver from receiving data that would be
> >acceptable to the stub resolver's local policy. (S 4.9.2)
> >
> >
> > And then in S 5, says:
> >When a resolver indicates support for DNSSEC (by setting the DO bit),
> >a security-aware name server should attempt to provide the necessary
> >DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).
> >
> >
> > Looking at things from the stub resolver's perspective, if the zone is
> > signed, then the stub resolver must receive the necessary RRsets or
> > fail the resolution. So, there needs to be an unambiguous way for the
> > stub to tell the recursive to deliver them. Am I right so far?
> >
> > Reading the above text, I infer that this signal is the DO bit. This
> > should cause the recursive to deliver the right RRsets (if available)
> > (I note that this text just says "name server" from which I'm
> > inferring that it applies to both authoritative and recursive).  Is
> > this correct? If so, is the fact that this is "should" and not
> > "SHOULD" telling me something"?
> >
> > Finally, as I understand it, the function of the CD bit is to tell the
> > recursive resolver to return records even it if cannot validate them
> > itself. However, it does *not* tell the recursive resolver to send the
> > RRsets in the first place, as that's the function of CD.
> >
> >
> > Summarizing all this, I have the following table of what the stub
> > should expect to receive if the recursive is a validating resolver and
> > it asks for an A record (just as an example)
> >
> >
> > Bits set Records validRecords invalid
> > -
> > None A + ???Error
> > DO   A + DNSSEC Error
> > CD   A + ???  A + ???
> > DO + CD  A + DNSSECA + DNSSEC
> >
> > Where "A + DNSSEC" means "A + plus the DNSSEC records" and "A + ???"
> > means "A + maybe some DSNSSEC records depending on what the recursive
> > wants".
> >
> > Thanks in advance,
> > -Ekr
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Question on interpretation of DO and CD

[Eric Rescorla]

Hi folks,

We've been trying to take some measurements of the success of endpoint
DNSSEC validation and run into some confusion about the implications
of the DO and CD bits. Sorry if these are dumb questions.

In the section on stub resolvers RFC 4035 says:

   A validating security-aware stub resolver MUST set the DO bit,
   because otherwise it will not receive the DNSSEC RRs it needs to
   perform signature validation. (S 4.9.1)

and:
   A validating security-aware stub resolver SHOULD set the CD bit,
   because otherwise the security-aware recursive name server will
   answer the query using the name server's local policy, which may
   prevent the stub resolver from receiving data that would be
   acceptable to the stub resolver's local policy. (S 4.9.2)


And then in S 5, says:
   When a resolver indicates support for DNSSEC (by setting the DO bit),
   a security-aware name server should attempt to provide the necessary
   DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).


Looking at things from the stub resolver's perspective, if the zone is
signed, then the stub resolver must receive the necessary RRsets or
fail the resolution. So, there needs to be an unambiguous way for the
stub to tell the recursive to deliver them. Am I right so far?

Reading the above text, I infer that this signal is the DO bit. This
should cause the recursive to deliver the right RRsets (if available)
(I note that this text just says "name server" from which I'm
inferring that it applies to both authoritative and recursive).  Is
this correct? If so, is the fact that this is "should" and not
"SHOULD" telling me something"?

Finally, as I understand it, the function of the CD bit is to tell the
recursive resolver to return records even it if cannot validate them
itself. However, it does *not* tell the recursive resolver to send the
RRsets in the first place, as that's the function of CD.


Summarizing all this, I have the following table of what the stub
should expect to receive if the recursive is a validating resolver and
it asks for an A record (just as an example)


Bits set Records validRecords invalid
-
None A + ???Error
DO   A + DNSSEC Error
CD   A + ???  A + ???
DO + CD  A + DNSSECA + DNSSEC

Where "A + DNSSEC" means "A + plus the DNSSEC records" and "A + ???"
means "A + maybe some DSNSSEC records depending on what the recursive
wants".

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

Re: [DNSOP] Structured Data for DNS Access Denied Error Page

[Eric Rescorla]

On Fri, Jul 9, 2021 at 7:43 AM Dan Wing  wrote:

> We just published Structured Data for DNS Access Denied Error Page which
> defines computer-parsable error information for DNS filtering:
>
>DNS clients using services which perform filtering may wish to
>receive more information about such filtering and the reason for that
>filtering.  To this end, Extended DNS Error Codes [RFC8914] provide
>information about when different types of filtering have occurred,
>and DNS Access Denied Error Page [I-D.reddy-dnsop-error-page]
>provides a URI to give further information to the end-user about the
>reasons for the filtering.  However, the latter draft assumes a
>client with a user-interface that can display a web page to the end-
>user, whereas many clients may in fact be "headless", i.e., acting on
>behalf of other network elements; such clients can include DNS
>forwarders and proxies.  Such clients cannot make use of a web-page
>designed for presentation to an end-user, but may instead be able to
>make use of structured data.  This draft provides a mechanism for
>such clients to request and receive structured data from the URI
>returned by the DNS Access Denied Error Page mechanism.
>

Thanks for posting this, Dan. Just as a matter of UX, this seems more
likely to
be usable than a web page because the client will want to ensure that the
user
is not confused into thinking that the error page contents are where they
wanted
to go. Structured data like this allows the client to provide the error in
its own
UI.

-Ekr


>When a third party provides DNS filtering, there are deployments
>where disclosing that third party to the host (which originated the
>DNS query) is desirable but other deployments where such disclosure
>is not desired.  For example, the IT organization might contract
>filtering to a third party but want trouble-tickets from employees to
>be handled by IT, rather than having employees interact directly with
>the third party.  As another example, all the employees at a small
>business or all the members of a household might be informed of the
>third party so they can troubleshoot filtering with that third party
>directly.
>
>
> Full document is at:
>
> https://datatracker.ietf.org/doc/html/draft-wing-dnsop-structured-dns-error-page-00.html
>
> -d
>
> ___
> 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] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

[Eric Rescorla]

On Wed, Jan 6, 2021 at 2:15 PM Paul Wouters  wrote:

> On Jan 6, 2021, at 17:01, Eric Rescorla  wrote:
> >
> >
> > This is not strictly correct: TLS allows both the client and the server
> to advertise their supported signature algorithms, which can be used by the
> peer to guide certificate selection.
>
> How common is it for TLS servers to have multiple signature algorithm /
> certificates configured to support this?
>

I don't have measurements for this offhand. It typically happens during
periods of transition, for instance between SHA-1 and SHA-256. I believe we
also saw it when servers had certificates with both RSA and EC keys.

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

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

[Eric Rescorla]

On Wed, Jan 6, 2021 at 1:30 PM Paul Hoffman  wrote:

> On Jan 6, 2021, at 1:19 PM, Paul Wouters  wrote:
> > Remember also that TLS ciphers are negotiated.
>
> A better analogy might be "although TLS key exchange and encryption
> ciphers are negotiated, the signing algorithm on the server's certificate
> is not negotiated". DNSSEC signing is much more akin to the latter, I think.
>
> > There is no negotiation
> > in DNSSEC.
>
> Quite right, just as there is no negotiation for the authentication in TLS.
>

This is not strictly correct: TLS allows both the client and the server to
advertise their supported signature algorithms, which can be used by the
peer to guide certificate selection.

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

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

[Eric Rescorla]

On Mon, Jan 4, 2021 at 3:31 AM Vittorio Bertola  wrote:

>
>
> > Il 01/01/2021 19:42 Stephen Farrell  ha
> scritto:
> >
> >
> > Hiya,
> >
> > On 01/01/2021 17:58, Paul Hoffman wrote:
> > > The WG has already adopted the revised GOST document as a WG item;
> > > what you are proposing (if the current use is negligible) would be in
> > > the opposite direction.
> > I wasn't "proposing" that, just posing it as a possible
> > option that might or might not be sensible to consider
> > depending on the facts relating to usage if/when we can
> > get 'em. Absent usage information, I'm not at all sure
> > whether or not any change from the status quo is warranted.
>
> We could ask the proponents of new algorithms for information on current
> or expected usage. However, if adoption is relevant to any kind of decision
> on what to do with an algorithm proposal, this should better be formalized
> somewhere and applied evenly to all algorithms that may appear in the
> future. Personally, I think that some expectation of adoption would be
> useful not to clutter the list of algorithms, but the threshold should be
> quite low.
>
> Also, as the IETF is the global SDO for DNS, it should make sure to
> encompass the needs of all Internet communities around the world. If a
> local community wants or needs for any reason to use a "globally
> non-standard" algorithm, there should be ways for this to happen without
> asking them to prove adoption of that algorithm on a global scale. Eric's
> points on fragmentation, implementation burden, potential incompatibilities
> are valid, but they should play out at usage level, not at the
> standardization one.


This seems to conflate standardization with code point assignment.
Standards are recommendations and our recommendation is that people use
particular algorithms. As the example of TLS shows, we can allow that
without standardizing those algorithms.

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

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

[Eric Rescorla]

On Wed, Dec 30, 2020 at 7:23 PM Paul Wouters  wrote:

> On Dec 30, 2020, at 22:11, Daniel Migault  wrote:
> >
> > 
> > 
> > If I understand clearly the comment, it seems to say that TLS ( for
> example ) is using RFC Required and that DNSSEC should do the same. Quickly
> going through RFC 8447, I cannot find "RFC Required", so I am wondering if
> you have a specific registry in mind. As far as I can see, the TLS cipher
> suite registry requires Standard Action to set Recommended to "Y" and
> Specification Required otherwise. As a result, leaving it to Standard
> Action seems better aligned with what TLS does for "Recommended".
>
> As previously explained in this thread, you cannot compare TLS with
> DNSSEC. With TLS you can offer IETF algorithms along with a nation state
> algo, and the client can pick what it prefers.
>
> For DNSSEC, the signed zone has already made all the decisions. A DNS
> client cannot decide to use or not use its local national algo.
>
> Paul
>
> > My motivation for not lowering the requirement is based on the
> specificities of DNS, that is the DNS is a system handles a global shared
> resource
>
> For those regimes who for instance are not allowed to trust RSA or
> NIST/NSA based ECC curves, you prefer those zones use no DNSSEC at all
> versus say GOST ?
>
> Because that’s what you are offering as the only choice now.
>

Thanks for making the point so sharply, Paul.

To be transparent about my priors, I think it would be better if
people used one of the more typical IETF algorithms, which is to say
ECDSA or EdDSA [0]. With that said, for whatever reason there are
people who want to use some other set of algorithms and the IETF's
ability to discourage them is limited. The IETF really has three main
options:

1. Don't allocate a code point at all
2. Allocate the code point but in some manner that makes clear
   we don't endorse it (effectively what TLS does for algorithms
   like this)
3. Allocate the code point without comment

My general sense is that (1) and (2) do to some extent discourage the
use of these algorithms (with (1) being more effective than (1)) but
(1) may discourage them *entirely*, so the likely result is that
people who want to use them just squat on a code point (or worse,
multiple code points!) and we lose those code points anyway, but
potentially after some interop problems. It's for this reason that
I think (2) is the best approach here.


As a number of people have noted, DNSSEC is different from TLS, IPsec,
etc. in that there's no real opportunity to negotiate. I don't think
that this changes the basic calculation but it might make it worth
investing more effort in discouraging people, both to prevent
algorithms that we think people should avoid and to reduce sharding of
the ecosystem if, for instance, some implementations opt not to do
algorithm X. It might also make it worth spending more effort in
helping people get good definitions of algorithm X even if we don't
think they should use it (as opposed to with TLS where the response is
mostly "go ahead and register, but don't bother us"). I'm skeptical
that "RFC Required" would foster either one of these goals, but
perhaps that's what Daniel is arguing?

-Ekr


[0] I think we should discourage RSA.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Last-Call] [secdir] Secdir last call review of draft-ietf-dnsop-server-cookies-04

[Eric Rescorla]

On Sat, Dec 5, 2020 at 6:58 AM Salz, Rich 
wrote:

> There is a fair amount of academic study around SipHash, and while
> everyone can make mistakes, its creators have a pretty good reputation. I
> don't think we can say SipHash is unknown in the industry.
>
> The TLSWG made it a practice to ask CFRG to "approve" all crypto it used
> (except perhapd HKDF, but that's a side note). The DNSOP has no such
> practice.
>

I recognize that this is a bigger issue, but I believe this should be the
practice for the IETF as a whole and I would encourage the SEC ADs to work
to make it so.

-Ekr



> If SECDIR or the Ads thinks SipHash isn't good, it would be great to hear
> reasons.  I haven't heard any yet.
>
>
> ___
> 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] [Last-Call] Secdir last call review of draft-ietf-dnsop-server-cookies-04

[Eric Rescorla]

On Thu, Dec 3, 2020 at 9:52 AM Salz, Rich 
wrote:

>
> https://www.aumasson.jp/siphash/
> 
>
>
>
>- It seems like kind of a problem to have a normative algorithm
>reference to a random personal Website.
>
>
>
> That web page has pointers to papers, perhaps they should be used instead.
>
>
That might be better. Basically, something that we can have some confidence
will be stable.

>
>
> Or maybe someone can convince Simon Joseffson to write it up (as he has
> for many others :)
>

That seems great.

-Ekr

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

Re: [DNSOP] [Last-Call] Secdir last call review of draft-ietf-dnsop-server-cookies-04

[Eric Rescorla]

On Thu, Dec 3, 2020 at 6:29 AM Willem Toorop  wrote:

> Op 02-12-2020 om 23:31 schreef Stephen Farrell:
>
> 
>
> > FWIW, I'd say it's worth a few more words to try reduce
> > the probability of such failures happening, e.g. maybe
> > just highlighting the "unsigned/2106" point you made
> > above would be enough. But, if the WG don't want to do
> > that, that's also fine by me.
>
> Sure, NP. I'll include Brian Dicksen's provided clarification in the
> text. Also, I approached Jean-Philippe Aumasson and he fixed the url we
> used in the draft for SipHash, but recommends to use this one in the
> future:
>
> https://www.aumasson.jp/siphash/


It seems like kind of a problem to have a normative algorithm reference to
a random personal Website.

-Ekr


>
> So I'll change that too.
>
> Cheers,
> -- Willem
>
> ___
> 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] [secdir] Secdir last call review of draft-ietf-dnsop-server-cookies-04

[Eric Rescorla]

On Wed, Dec 2, 2020 at 10:32 AM Ondřej Surý  wrote:

> Stephen,
>
> ad 1) the performance is crucial for DNS over UDP and PRF such as SipHash
> is more efficient than HMACs. No, it wasn’t consulted with CFRG, and I
> can’t speak for Willem, but I am confident enough to make the decision.
> SipHash is widely used for hash tables virtually anywhere now.
>

Well hash tables are an application with somewhat different security
properties than MACs, so I don't think this is dispositive.

I concur with Stephen that CFRG should sign off on the use of SipHash here.
With that said, how does SipHash compare to GMAC in terms of performance?

-Ekr


> ad 2) we need a value that’s synchronized well enough and monotonic. I
> honestly don’t see any value in using 64-bit value here. Using unixtime has
> a value in itself, it’s a well-known and there’s a little room for any
> implementor to make a mistake in an implementation. The interoperability is
> more important than the actual value of the counter. It’s write only
> counter, nobody is going to interpret it after it has been generated, and
> it’s wide enough to prevent brute forcing.
>
> Cheers,
> Ondřej
> --
> Ondřej Surý — ISC (He/Him)
>
> > On 2. 12. 2020, at 18:47, Stephen Farrell via Datatracker <
> nore...@ietf.org> wrote:
> >
> > Reviewer: Stephen Farrell
> > Review result: Has Issues
> >
> > I see two issues here worth checking:
> >
> > 1. I don't recall SipHash being used as a MAC in
> > any IETF standard before. We normally use HMAC,
> > even if truncated. Why make this change and was
> > that checked with e.g. CFRG? (And the URL given
> > in the reference gets me a 404.)
> >
> > 2. Is it really a good idea to use a 32 bit seconds
> > since 1970-01-01 in 2020? I'd have thought that e.g.
> > a timestamp in hours since then or seconds since
> > some date in 2020 would be better.
> >
> > Here's a couple of nits too:
> > - section 1: what's a "strong cookie"?
> > - "gallimaufry" - cute! but not sure it'll help readers to learn that
> word.
> >
> >
> >
> >
>
> ___
> secdir mailing list
> sec...@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Eric Rescorla]

On Fri, Jun 19, 2020 at 11:39 AM John Levine  wrote:

> In article  01gd...@mail.gmail.com> you write:
> >> Yes. Leveraging the fact that the IETF community is in fact a community
> >> seems worth the effort to have the references in registries be useful
> to a
> >> new developer a decade in the future.
> >
> >OK. In that case you and I disagree.
> >
> >My reasoning is that (as above) these algorithms are generally of low
> >interest and that requiring community review for code point registration
> >has the result of consuming quite scarce resources in the service of
> making
> >the algorithms which are being registered marginally clearer. ...
>
> Sounds like expert review would be more appropriate, so only one
> person has to spend cycles deciding whether the spec looks plausible.
>

As I said, even that turns out to be quite a bit of work, depending on what
you think "plausible" means. If you review for "there appears to be
something vaguely formatted like a spec at this location", then sure. If
you mean "is this implementable", let alone secure, then it's pretty far
from easy.

-Ekr

>
> R's,
> John
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Eric Rescorla]

On Fri, Jun 19, 2020 at 10:11 AM Paul Hoffman 
wrote:

> On Jun 19, 2020, at 9:26 AM, Eric Rescorla  wrote:
> > What's your reasoning for why there needs to be community review before
> there is a code point assigned?
>
> Historically, the quality of algorithm descriptions in early drafts has
> been variable. What the author considers sufficient and obvious, another
> might not. Also, review gives folks a chance to say things like "your test
> vectors appear wrong", "having test vectors would be really useful", and so
> on.
>
> > Would that still apply if the space were larger?
>
> Yes. Leveraging the fact that the IETF community is in fact a community
> seems worth the effort to have the references in registries be useful to a
> new developer a decade in the future.
>

OK. In that case you and I disagree.

My reasoning is that (as above) these algorithms are generally of low
interest and that requiring community review for code point registration
has the result of consuming quite scarce resources in the service of making
the algorithms which are being registered marginally clearer. This opinion
is based on my extensive experience in reviewing code point assignments for
TLS (largely for things like exporters) where one was presented with a long
specification which was embedded in the context of some other protocol and
then one had to make sense of it and determine whether it was
implementable. And because you were actually holding up other people's work
based on that review, there was pressure to complete it. This kind of
experience is why we changed to the current system.

More generally, it seems like there are two primary purposes for code point
registration here:

1. To promote interoperability of the code points
2. To avoid code point collisions

My perspective here is that while interoperability is good, the primary
value here is to avoid collisions. People who wish to have interoperability
will still have the IETF process available to them, but given the large
number of uses of our protocols, I do not believe that it is productive to
make it harder for people to extend them in order to require
interoperability for those who do not believe they need it (or at least do
not believe they need the IETF enforcing it).

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

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

[Eric Rescorla]

On Fri, Jun 19, 2020 at 8:38 AM Paul Hoffman  wrote:

> On Jun 18, 2020, at 9:20 PM, Martin Thomson  wrote:
> >
> > On Fri, Jun 19, 2020, at 01: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.
> >
> > I think you mean "Specification Required".
>
> I do not.
>
> >  RFC required has the same net effect, but the side effect being that
> you burden the ISE with these requests.
>
> "RFC required" forces the specification to be stable enough for the ISE
> (or the IESG, for individual submissions) to approve publication. Using
> "specification required" means that someone can write an Internet Draft,
> get the code point, then realize that their draft was wrong due to lack of
> community review. The result is either:
> - Two code points for similarly-named algorithms
>

Sure. This seems not that desirable, but given that these algorithms are
more or less by definition ones in which there is not that wide interest,
not that big a deal.


- A code point whose definition is a moving target
>

I agree that this is undesirable. The registrations should be tied to a
single fixed draft version.



> Using "RFC required" is not perfect (due to errata and RFC updates), but
> it does mean that there is at least some community review before the code
> point is allocated.
>

What's your reasoning for why there needs to be community review before
there is a code point assigned? Would that still apply if the space were
larger?


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

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

[Eric Rescorla]

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

[Eric Rescorla]

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-belyavskiy-rfc5933-bis

[Eric Rescorla]

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] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Eric Rescorla]

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

Re: [DNSOP] port number in HTTPSSVC

[Eric Rescorla]

I agree. I do not think we should make this change.

-Ekr


On Fri, Jan 3, 2020 at 12:02 PM Erik Kline  wrote:

> I think removing port number flexibility might unduly constrain some data
> center use cases where service reachability might not have the more common
> 443-only limitations.
>
> On Fri, Jan 3, 2020 at 11:33 AM Ben Schwartz  40google.@dmarc.ietf.org <40google@dmarc.ietf.org>> wrote:
>
>> HTTPSSVC co-editor here.
>>
>> The effect of this change seems similar to deprecating support for
>> non-default ports in HTTP/3.  While I have some misgivings about the
>> handling of non-default ports in HTTPS, I would want to see consensus in
>> the HTTP and QUIC working groups before making this change.
>>
>> I would suggest sending your proposal to those lists, and we can adjust
>> the HTTPSSVC draft based on their conclusions.
>>
>> On Fri, Jan 3, 2020 at 1:24 PM Paul Vixie  wrote:
>>
>>> in SRV we added a port number to the rdata because the /etc/services
>>> file was
>>> painful to keep globally updated. SRV was protocol independent.
>>>
>>> HTTPSSVC is protocol specific, and when it copied SRV, it included the
>>> port
>>> number in the rdata, which i think is both unnecessary and error-prone.
>>>
>>> managed private networks who want to permit outbound HTTP/3 are going to
>>> add a
>>> rule like "if the far end port number is 443, add a stateful rule".
>>> anyone who
>>> uses the port number field (if it exists) in HTTPSSVC to specify a
>>> different
>>> port number is going to suffer, as will many of the clients trying to
>>> access
>>> that service.
>>>
>>> i suggest that the port 443 assumption for HTTP/3 be baked in, and that
>>> this
>>> field be removed from the HTTPSSVC rdata.
>>>
>>> --
>>> Paul
>>>
>>>
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: [Add] new draft: draft-grover-add-policy-detection-00

[Eric Rescorla]

On Tue, Jul 16, 2019 at 4:04 PM Alejandro Acosta <
alejandroacostaal...@gmail.com> wrote:

> 
>
>
> On 7/8/19 2:36 PM, Andy Grover wrote:
> > Hi all,
> >
> > FYI from the ADD list, please post there or to the authors with feedback.
> >
> >
> >  Forwarded Message 
> > Subject: [Add] new draft: draft-grover-add-policy-detection-00
> > Date: Mon, 8 Jul 2019 11:29:02 -0700
> > From: Andy Grover 
> > To: a...@ietf.org
> >
> > Hello all,
> >
> > We've posted an initial draft of draft-grover-add-policy-detection,
> > which proposes a method of identifying if content filtering or other
> > policy is implemented on the local resolver, so applications doing DNS
> > resolution can adjust their behavior.
>
>
> I wonder if this technique will also expand to http(s) blocks / policies
> / filtering
>

That is not an idea I would be in favor of.

-Ekr


>
> >
> > Thanks -- Regards -- Andy
> >
> >  Forwarded Message 
> > Subject: New Version Notification for
> > draft-grover-add-policy-detection-00.txt
> > Date: Mon, 08 Jul 2019 10:46:45 -0700
> > From: internet-dra...@ietf.org
> > To: Andy Grover , Peter Saint-Andre
> > 
> >
> >
> > A new version of I-D, draft-grover-add-policy-detection-00.txt
> > has been successfully submitted by Peter Saint-Andre and posted to the
> > IETF repository.
> >
> > Name: draft-grover-add-policy-detection
> > Revision: 00
> > Title:DNS Resolver-Based Policy Detection Domain
> > Document date:2019-07-08
> > Group:Individual Submission
> > Pages:6
> > URL:
> >
> https://www.ietf.org/internet-drafts/draft-grover-add-policy-detection-00.txt
> > Status:
> > https://datatracker.ietf.org/doc/draft-grover-add-policy-detection/
> > Htmlized:
> > https://tools.ietf.org/html/draft-grover-add-policy-detection-00
> > Htmlized:
> > https://datatracker.ietf.org/doc/html/draft-grover-add-policy-detection
> >
> >
> > Abstract:
> >This document specifies the behavior that is expected from the Domain
> >Name System with regard to DNS queries for the special-use domain
> >name 'TBD.arpa' and designates this domain as a special-use domain
> >name.
> >
> ___
> 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] Fwd: [Add] new draft: draft-grover-add-policy-detection-00

[Eric Rescorla]

On Mon, Jul 15, 2019 at 8:53 PM Rob Sayre  wrote:

>
>
> On Mon, Jul 15, 2019 at 8:14 AM Paul Vixie  wrote:
>
>> On Monday, 15 July 2019 02:17:04 UTC Rob Sayre wrote:
>> > On Sun, Jul 14, 2019 at 6:59 PM Paul Vixie  wrote:
>> > > ...
>> >
>> > I'm surprised that you seem to view DoH as a problem. I mean, everyone
>> knows
>> > that TLS and IPSEC are compromised by determined attackers, ...
>>
>> if you know a way that modern TLS 1.3 can be compromised by MiTM
>
>
> I think some parties just ask for the certs, if they can't acquire them
> due to negligence.
>

The certs are public information, so having the certs isn't useful. Can you
please be clearer about the attack you are describing?

-Ekr




>
>
>> , i'd like to
>> know more. a lot of us are moving from MiTM to explicit outbound proxy
>> with an
>> internally trusted key in order to fulfill our corporate or regulatory
>> obligations.
>>
>> > but I didn't know
>> > it was a continued sore spot. If you have more to say, I would like to
>> hear
>> > it.
>>
>> the introduction of the DoH RFC explains that this protocol is designed
>> to
>> prevent interference by on-path actors in dns operations. i am a
>> committed,
>> determined on-path interferer, both for parental controls at home and
>> corporate controls at $dayjob.
>>
>
> This response is disappointing to me, but I have to congratulate its
> directness.
>
> thanks,
> Rob
> ___
> 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] [Doh] New I-D: draft-reid-doh-operator

[Eric Rescorla]

On Fri, Mar 22, 2019 at 12:53 AM Vittorio Bertola  wrote:

>
>
> > Il 22 marzo 2019 alle 4.40 Christian Huitema  ha
> scritto:
> >
> > Much of the debate is on the second point. One position is that users
> should be forced to trust the DNS resolver provided by the local
> infrastructure. Another position is that users have the right to apply
> their own policy and decide which server they will trust, based on some
> configuration.
>
> I think this is a mischaracterization of the debate, which actually
> started because of a third position that you don't mention: Mozilla's
> public statement that in the future they will force (or, at least, make as
> a default - clarification requests haven't solved the doubt yet) Firefox
> users to use a remote resolver chosen within a shortlist that they will
> manage.
>

I'm not sure where you have attempted to clarify this point (I think we've
been clear on this point at
https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/)

Regardless of what the default is, users will be able to disable DoH.

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

Re: [DNSOP] [Doh] [dns-privacy] New: draft-bertola-bcp-doh-clients

[Eric Rescorla]

On Tue, Mar 12, 2019 at 8:51 AM Konda, Tirumaleswar Reddy <
tirumaleswarreddy_ko...@mcafee.com> wrote:

> Hi Eric,
>
>
>
> In TLS 1.2, it is possible for firewalls to inspect the TLS handshake, and
> white-list, black-list and grey-list TLS session based on the server
> identity. In other words, middleboxes are conditionally acting as TLS
> proxies to specific servers (categorized in the grey-list).
>
With TLS 1.3 and encrypted SNI, the middle box now has to act as a TLS
> proxy for all the flows.
>

It would be most useful not to conflate TLS 1.3 and ESNI.

In ordinary TLS 1.3, the SNI is in the clear but the server cert is not.
However, importantly, even in TLS 1.2, the server certificate is not
verifiable, and therefore is not significantly more trustworthy than SNI.

With ESNI, the SNI is encrypted (hence the name). However, the xpectation
is that enterprises which want to do conditional inspection will disable
ESNI on the client. This should not be problematic as they already need
access to the client to install their own trust anchor.

-Ekr



>
> -Tiru
>
>
>
> *From:* Eric Rescorla 
> *Sent:* Tuesday, March 12, 2019 3:14 AM
> *To:* Paul Vixie 
> *Cc:* nalini elkins ; Konda, Tirumaleswar Reddy
> ; d...@ietf.org; dnsop@ietf.org;
> Ackermann, Michael ; Christian Huitema <
> huit...@huitema.net>; dns-priv...@ietf.org; Vittorio Bertola
> ; Stephen Farrell <
> stephen.farr...@cs.tcd.ie>
> *Subject:* Re: [Doh] [dns-privacy] [DNSOP] New:
> draft-bertola-bcp-doh-clients
>
>
>
> *CAUTION*: External email. Do not click links or open attachments unless
> you recognize the sender and know the content is safe.
> --
>
>
>
>
>
> On Mon, Mar 11, 2019 at 11:13 AM Paul Vixie  wrote:
>
>
>
> nalini elkins wrote on 2019-03-11 10:26:
> > Tiru,
> >
> > Thanks for your comments.
> >
> >  > Enterprise networks are already able to block DoH services,
> i wonder if everyone here knows that TLS 1.3 and encrypted headers is
> going to push a SOCKS agenda onto enterprises that had not previously
> needed one,
>
>
>
> I'm pretty familiar with TLS 1.3, but I don't know what this means. TLS 1.3
>
> doesn't generally encrypt headers any more than TLS 1.2 did, except for
>
> the content type byte, which isn't that useful for inspection anyway.
>
> Are you perchance referring to encrypted SNI? Something else?
>
>
>
> -Ekr
>
>
>
> and that simply blocking every external endpoint known or
> tested to support DoH will be the cheaper alternative, even if that
> makes millions of other endpoints at google, cloudflare, cisco, and ibm
> unreachable as a side effect?
>
> CF has so far only supported DoH on 1.1.1.0/24 and 1.0.1.0/24, which i
> blocked already (before DoH) so that's not a problem. but if google
> decides to support DoH on the same IP addresses and port numbers that
> are used for some API or web service i depend on, that web service is
> going to be either blocked, or forced to go through SOCKS. this will add
> considerable cost to my network policy. (by design.)
>
> --
> P Vixie
>
> ___
> Doh mailing list
> d...@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Doh] [dns-privacy] New: draft-bertola-bcp-doh-clients

[Eric Rescorla]

On Mon, Mar 11, 2019 at 11:13 AM Paul Vixie  wrote:

>
>
> nalini elkins wrote on 2019-03-11 10:26:
> > Tiru,
> >
> > Thanks for your comments.
> >
> >  > Enterprise networks are already able to block DoH services,
> i wonder if everyone here knows that TLS 1.3 and encrypted headers is
> going to push a SOCKS agenda onto enterprises that had not previously
> needed one,


I'm pretty familiar with TLS 1.3, but I don't know what this means. TLS 1.3
doesn't generally encrypt headers any more than TLS 1.2 did, except for
the content type byte, which isn't that useful for inspection anyway.
Are you perchance referring to encrypted SNI? Something else?

-Ekr

and that simply blocking every external endpoint known or
> tested to support DoH will be the cheaper alternative, even if that
> makes millions of other endpoints at google, cloudflare, cisco, and ibm
> unreachable as a side effect?
>
> CF has so far only supported DoH on 1.1.1.0/24 and 1.0.1.0/24, which i
> blocked already (before DoH) so that's not a problem. but if google
> decides to support DoH on the same IP addresses and port numbers that
> are used for some API or web service i depend on, that web service is
> going to be either blocked, or forced to go through SOCKS. this will add
> considerable cost to my network policy. (by design.)
>
> --
> P Vixie
>
> ___
> Doh mailing list
> d...@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>
___
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)

[Eric Rescorla]

On Tue, Nov 27, 2018 at 7:00 AM Paul Hoffman  wrote:

> 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?
>

Hmm... I don't really think so. It seems to me that the semantics here are
"this is the filter string that was applied" and because that's effectively
a program, in order to interpret it you need to know what language it was
in.

-Ekr


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

Re: [DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-dns-capture-format-08: (with COMMENT)

[Eric Rescorla]

On Wed, Nov 21, 2018 at 9:25 AM Sara Dickinson  wrote:

>
>
> Begin forwarded message:
>
> *From: *Eric Rescorla 
> *Subject: **Eric Rescorla's No Objection on
> draft-ietf-dnsop-dns-capture-format-08: (with COMMENT)*
> *Date: *21 November 2018 at 02:07:20 GMT
> *To: *"The IESG" 
> *Cc: *Tim Wicinski , tjw.i...@gmail.com,
> dnsop@ietf.org, dnsop-cha...@ietf.org,
> draft-ietf-dnsop-dns-capture-for...@ietf.org
> *Resent-From: *
> *Resent-To: *j...@sinodun.com, j...@sinodun.com, s...@sinodun.com,
> terry.mander...@icann.org, john.b...@icann.org
>
> Eric Rescorla has entered the following ballot position for
> draft-ietf-dnsop-dns-capture-format-08: No Objection
>
>
> Hi,
>
> Many thanks for the review
>
>
> --
> COMMENT:
> --
>
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D4670
>
>
> I support Ben's DISCUSS.
>
>
> Ack - hopefully our response to him addresses your concerns.
>

I'll leave it with him.



> Am I understanding the design correctly in that you can't have
> literals in the individual per-query values, but instead references to
> the block tables, so you can't stream inside a block?
>
>
> Yes, that is correct - do you think we need to add text to clarify this?
>

Yes, as it seems like an unobvious tradeoff. It's worth noting that if you
put the block tables at the end, you could save memory on the encoder.

>
>
> IMPORTANT
> S 7.5.1.
>
> | earliest-time| O | A | A timestamp (2 unsigned integers,  |
> |  |   |   | "Timestamp") for the earliest record   |
> |  |   |   | in the "Block" item. The first integer |
> |  |   |   | is the number of seconds since the |
> |  |   |   | Posix epoch ("time_t"). The second |
> |  |   |   | integer is the number of ticks since   |
>
>
> I don't know what a "tick" is, so you need some definitionf or this.
>
>
> From 7.4.1.1:
>
> ticks-per-second | M | U | Sub-second timing is recorded in   |
>|  |   |   | ticks. This specifies the number of|
>|  |   |   | ticks in a second.
>
> This was the solution to a request to allow flexibility in how granular
> the sub-second timing increments are.
>

Ah I missed that. A reference to 7.4.1.1 would help.


> S 7.4.1.1.1.
>
>
> +--+---+---++
> | Field| O | T | Description|
> +--+---+---++
> | query-response   | M | U | Hints indicating which "QueryResponse" |
> | -hints   |   |   | fields are omitted, see section|
>
>
> Nit: generally, you would say "indicating which fields are included"
> if 1 means included.
>
>
> The issue is that if the bit is set the field might still be missing
> because although the configuration was set to collect it the data wasn’t
> available to the encoder from some other reason. However when the bit is
> not set it means that the data will definitely not be present because the
> collector is configured not to collect it.
>
> We do discuss this problem in section 6.2.1 - perhaps a reference in the
> table back to that discussion is what is needed?
>

Maybe, I just thought that the text was a bit odd.


>
>
> S 7.5.3.
>
> +-+---+---+-+
>
>  7.5.3.  "BlockTables"
>
> Arrays containing data referenced by individual "QueryResponse" or
> "MalformedMessage" items in this "Block".  Each element is an array
>
>
> This is not a sentence.
>
>
> Suggest: “Map of arrays containing data... "
>

Maybe. I'll let you sort this out with RFC Ed.

S 7.5.3.2.
>
> ++---+---+--+
> | server-address | O | U | The index in the item in the "ip-|
> | -index |   |   | address" array of the server IP  |
> ||   |   | address. See Section 7.5.3.  |
> ||   |   |  |
> | server-port| O | U | The server port. |
>
>
> Isn't the server port generally constant? It seems like you might

[DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-dns-capture-format-08: (with COMMENT)

[Eric Rescorla]

Eric Rescorla has entered the following ballot position for
draft-ietf-dnsop-dns-capture-format-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/



--
COMMENT:
--

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4670


I support Ben's DISCUSS.

Am I understanding the design correctly in that you can't have
literals in the individual per-query values, but instead references to
the block tables, so you can't stream inside a block?

IMPORTANT
S 7.5.1.
>  | earliest-time| O | A | A timestamp (2 unsigned integers,  |
>  |  |   |   | "Timestamp") for the earliest record   |
>  |  |   |   | in the "Block" item. The first integer |
>  |  |   |   | is the number of seconds since the |
>  |  |   |   | Posix epoch ("time_t"). The second |
>  |  |   |   | integer is the number of ticks since   |

I don't know what a "tick" is, so you need some definitionf or this.

COMMENTS
S 7.2.
>   
>  o  The column O marks whether items in a map are optional.
>   
> *  O - Optional.  The item may be omitted.
>   
> *  M - Mandatory.  The item must be present.

FWIW, I think you might be happier with a mandatory "X" and optional
nothing, but that's up to you.


S 7.4.1.1.1.
>   
>  +--+---+---++
>  | Field| O | T | Description|
>  +--+---+---++
>  | query-response   | M | U | Hints indicating which "QueryResponse" |
>  | -hints   |   |   | fields are omitted, see section|

Nit: generally, you would say "indicating which fields are included"
if 1 means included.


S 7.5.3.
>  +-+---+---+-+
>   
>   7.5.3.  "BlockTables"
>   
>  Arrays containing data referenced by individual "QueryResponse" or
>  "MalformedMessage" items in this "Block".  Each element is an array

This is not a sentence.


S 7.5.3.
>  | qrr   | O | A | Array of type "Question". Each entry  |
>  |   |   |   | is the contents of a single question, |
>  |   |   |   | where a question is the second or |
>  |   |   |   | subsequent question in a query. See   |
>  |   |   |   | Section 7.5.3.3.  |
>  |   |   |   |   |

So if I understand this correctly:

QRR is a map of integers to question
QLIST is a map of integers to question lists, with each question list
consisting of a set of indexes int o QRR?



S 7.5.3.2.
>   
>  ++---+---+--+
>  | Field  | O | T | Description  |
>  ++---+---+--+
>  | server-address | O | U | The index in the item in the "ip-|
>  | -index |   |   | address" array of the server IP  |

So am I understanding correctly that you can't put the server address
literally in here. It has to be in the block tables?


S 7.5.3.2.
>  ++---+---+--+
>  | server-address | O | U | The index in the item in the "ip-|
>  | -index |   |   | address" array of the server IP  |
>  ||   |   | address. See Section 7.5.3.  |
>  ||   |   |  |
>  | server-port| O | U | The server port. |

Isn't the server port generally constant? It seems like you might save
some bits by having this attached to the server and then indixed
abvoe.



S 7.5.3.2.
>  ||   |   | used to service the query.   |
>  ||   |   | Bit 0. IP version. 0 if IPv4, 1 if   |
>  ||   |   | IP

Re: [DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-attrleaf-13: (with COMMENT)

[Eric Rescorla]

On Wed, Oct 10, 2018 at 1:18 PM Dave Crocker  wrote:

> Eric,
>
> On 10/9/2018 7:23 PM, Eric Rescorla wrote:
> >>   However some services have defined an operational convention,
> which
> >>   applies to DNS leaf nodes that are under a DNS branch having one
> or
> >>   more reserved node names, each beginning with an _underscore.  The
> >>   underscored naming construct defines a semantic scope for DNS
> record
> >>   types that are associated with the parent domain, above the
> >>   underscored branch.  This specification explores the nature of
> this
> >
> > This text is a bit hard to parse for the layman. Here's my attempted
> > rewrite, which captures what I think this means.
> >
> > Conventionally, this construct associates data with the parent domain,
> > with the underscored label instead denoting the type of the data.
> >
> > I'm not sure if that helps, but perhaps something along these lines?
>
> Yeah, this has been an oddly challenging bit of text to formulate.
> Perhaps:
>
>   However some services use an operational convention for defining
> specific interpretations of an RRset, by locating the records in a DNS
> branch, under the parent domain to which the RRset actually applies.
> The top of this subordinate branch is defined by a naming convention
> that uses a reserved node name, which begins with an _underscore.
>

Sure, this seems fine.


> > S 1.1.
> >>
> >>1.1.  Underscore Scoping
> >>
> >>   As an alternative to defining a new RR type, some DNS service
> >>   enhancements call for using an existing resource record type, but
> >>   specify a restricted scope for its occurrence.  Scope is meant as
> a
> >
> > I think I get why you are saying "scope" here, but it's kind of not
> > that good fit with the programming concepts of scope as I am familiar
> > with.
>
> So I took your concern as an excuse to review the CS definition and
> find that I still think its application here is appropriate...  And it
> has not seemed to cause confusion for others.
>

OK, well I don't think I agree, but this is a non-blocking comment, so I
don't think there's much point in continuing to debate it.

-Ekr


>
> > S 2.
> >>  ++
> >>
> >>   Examples of Underscored Names
> >>
> >>   Only global underscored names are registered in the IANA
> Underscore
> >>   Global table.
> >
> > so just for clarify, in the examples above, only _service[1-4] and
> > _authority would need to be registered?
>
> Yes.  (And I've added a sentence noting that point, for clarity. Thanks.)
>
> d/
>
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-attrleaf-13: (with COMMENT)

[Eric Rescorla]

Eric Rescorla has entered the following ballot position for
draft-ietf-dnsop-attrleaf-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/



--
COMMENT:
--

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D5596



COMMENTS

>  However some services have defined an operational convention, which
>  applies to DNS leaf nodes that are under a DNS branch having one or
>  more reserved node names, each beginning with an _underscore.  The
>  underscored naming construct defines a semantic scope for DNS record
>  types that are associated with the parent domain, above the
>  underscored branch.  This specification explores the nature of this

This text is a bit hard to parse for the layman. Here's my attempted
rewrite, which captures what I think this means.

Conventionally, this construct associates data with the parent domain,
with the underscored label instead denoting the type of the data.

I'm not sure if that helps, but perhaps something along these lines?


S 1.1.
>   
>   1.1.  Underscore Scoping
>   
>  As an alternative to defining a new RR type, some DNS service
>  enhancements call for using an existing resource record type, but
>  specify a restricted scope for its occurrence.  Scope is meant as a

I think I get why you are saying "scope" here, but it's kind of not
that good fit with the programming concepts of scope as I am familiar
with.

It seems like there are two benefits to this convention (1) indicating
the type of the data (2) the ability to do a selective query.

Perhaps it would be clearer to introduce the convention first with the
typing benefit and then explain that this also gives you the ability
to do a selective query.




S 2.
> ++
>   
>  Examples of Underscored Names
>   
>  Only global underscored names are registered in the IANA Underscore
>  Global table.

so just for clarify, in the examples above, only _service[1-4] and
_authority would need to be registered?


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

[DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-refuse-any-07: (with COMMENT)

[Eric Rescorla]

Eric Rescorla has entered the following ballot position for
draft-ietf-dnsop-refuse-any-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/



--
COMMENT:
--

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D5482



COMMENTS
S 3.
>  processing in order to send a conventional ANY response, and avoiding
>  that processing expense might be desirable.
>   
>   3.  General Approach
>   
>  This proposal provides a mechanism for an authority server to signal

Nit: authoritative.


S 4.3.
>  applications may be satisfied by this behaviour, the resulting
>  responses in the general case are larger than the approaches
>  described in Section 4.1 and Section 4.2.
>   
>  As before, if the zone is signed and the DO bit is set on the
>  corresponding query, an RRSIG RRSet MUST be included in the response.

This section seems to be one possible algorithm for implementing 4.1.
What am I missing?


S 7.
>  It is important to note that returning a subset of available RRSets
>  when processing an ANY query is legitimate and consistent with
>  [RFC1035]; it can be argued that ANY does not always mean ALL, as
>  used in section 3.2.3 of [RFC1035].  The main difference here is that
>  the TC bit SHOULD NOT be set on the response indicating that this is
>  not a complete answer.

This is a bit grammatically awkward, perhaps "response, thus
indicating"


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

Re: [DNSOP] [Ext] Eric Rescorla's No Objection on draft-ietf-dnsop-terminology-bis-13: (with COMMENT)

[Eric Rescorla]

That's understandable. I think it would be most helpful to somehow tag
those cases so that the reader can see that they are ambiguous rather than
just rereading and being confused.

-Ekr


On Fri, Aug 31, 2018 at 9:22 AM, Paul Hoffman 
wrote:

> Ekr pinged me in Jabber after I sent this, and I wanted to clarify
> something bigger-picture on this document. We know that there are a number
> of definitions that are not clear. In the WG discussion, we tried hard to
> get them clarified, and often met resistance in the form of "I have always
> thought it meant X" vs. "I have always thought it meant Y" that could not
> be resolved. On some of the terms that Ekr asked for clarity on, we had
> even done separate threads. In the end, there was reasonably strong WG
> consensus that the document was the best we could do, even thought most of
> the folks who said that probably had at least one bit that they didn't like
> in the document.
>
> --Paul Hoffman
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-terminology-bis-13: (with COMMENT)

[Eric Rescorla]

Eric Rescorla has entered the following ballot position for
draft-ietf-dnsop-terminology-bis-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/



--
COMMENT:
--

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3131



IMPORTANT
S 6.
> [RFC5358]
>   
>  Split DNS:  The terms "split DNS" and "split-horizon DNS" have long
> been used in the DNS community without formal definition.  In
> general, they refer to situations in which DNS servers that are
> authoritative for a particular set of domains provide partly or

What about ones that aren't authoritative. Apparently this exists in
VPN settings.

COMMENTS
S 2.
>  learn the DNS by reading this document.
>   
>   2.  Names
>   
>  Naming system:  A naming system associates names with data.  Naming
> systems have many significant facets that help differentiate them.

>From each other? Or from other systems that aren't naming systems?


S 2.
> The need for the term "fully qualified domain name" comes from the
> existence of partially qualified domain names, which are names
> where one or more of the earliest labels in the ordered list are
> omitted (for example, a name of "www" derived from
> "www.example.net").  Such relative names are understood only by
> context.

I think we agree here but I had to read it several times, because
"earliest" in the list is not earliest in the presentation format.
Perhaps you should say "less specific" or "closest to the root" are
omitted  instead.


S 2.
>  Subdomain:  "A domain is a subdomain of another domain if it is
> contained within that domain.  This relationship can be tested by
> seeing if the subdomain's name ends with the containing domain's
> name."  (Quoted from [RFC1034], Section 3.1).  For example, in the
> host name "nnn.mmm.example.com", both "mmm.example.com" and
> "nnn.mmm.example.com" are subdomains of "example.com".

It might be worth noting that whole component matches are required
here.


S 2.
>   
>  Canonical name:  A CNAME resource record "identifies its owner name
> as an alias, and specifies the corresponding canonical name in the
> RDATA section of the RR."  (Quoted from [RFC1034], Section 3.6.2)
> This usage of the word "canonical" is related to the mathematical
> concept of "canonical form".

This paragraph didn't seem very clear. Perhaps an explanatory sentence
or two about what a CNAME is for woudl help.


S 4.
>the name originally queried, or a name received in a CNAME
>chain response.
>   
> *  QNAME (final): The name actually resolved, which is either the
>name actually queried or else the last name in a CNAME chain
>response.

So to be clear, the QNAME (final) is always one of the QNAME
(effective) sets?


S 6.
> name server side (which is what answers the query) and a resolver
> side (which performs the resolution function).  Systems operating
> in this mode are commonly called "recursive servers".  Sometimes
> they are called "recursive resolvers".  While strictly the
> difference between these is that one of them sends queries to
> another recursive server and the other does not, in practice it is

Which one does which?


S 6.
> general, a recursive resolver is expected to cache the answers it
> receives (which would make it a full-service resolver), but some
> recursive resolvers might not cache.
>   
> [RFC4697] tried to differentiate between a recursive resolver and
> an iterative resolver.

Did it fail?


S 6.
> client to another server and lets the client pursue the query
> there.  (See Section 2.3 of [RFC1034].)
>   
> In iterative resolution, the client repeatedly makes non-recursive
> queries and follows referrals and/or aliases.  The iterative
> resolution algorithm is described in Sect

Re: [DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-session-signal-12: (with COMMENT)

[Eric Rescorla]

On Tue, Jul 31, 2018 at 8:21 PM, Ted Lemon  wrote:

>
> Sorry, has this been changed in a new version?
>>
>
> The text you commented on is the new version, with some additional text to
> address a point raised in the gen-art review.   We gamed this out pretty
> thoroughly—I don't think there's an actual problem here, although I
> understand why it looks that way.   The worst case scenario here is that a
> middlebox breaks the session signaling, which just looks like "the server
> doesn't support session signaling," which is fine.
>

I think I'm just confused about the meaning of this text. Is it an analysis
or a recommendation?



>
>>
>>> S 5.4.
 > generate a response, the application-layer software informs
 the
 > TCP implementation that it should go ahead and send the TCP
 ACK
 > and window update immediately, without waiting for the
 Delayed ACK
 > timer.  Unfortunately it is not known at this time which (if
 any)
 > of the widely-available networking APIs currently include this
 > capability.

 Are you going to make a recommendation here?

>>>
>>> Out of scope for DNSOP to update TCP stack APIs.
>>>
>>
>> Sorry, it wasn't clear from context what I was referring to here. You
>> discuss a number
>> of strategies and then say they are all bad. Do you had a recommendation
>> for what
>> people ought to do?
>>
>
> We don't.   This is text that was heavily touched by Mirja's DISCUSS, so I
> suspect that by the time Stuart is done addressing her DISCUSS, this will
> have been fixed.   However, I will try to remember to check just to be
> sure. :)
>

OK.


S 6.6.1.2.
 >  client a Retry Delay message, or by forcibly aborting the
 underlying
 >  transport connection) the client SHOULD try to reconnect, to that
 >  service instance, or to another suitable service instance, if
 more
 >  than one is available.  If reconnecting to the same service
 instance,
 >  the client MUST respect the indicated delay, if available, before
 >  attempting to reconnect.

 Do you want to recommend some sort of randomness around this value to
 avoid avalanche?

>>>
>>> The server is specifying the retry delay, so if the client adds
>>> randomness, that could result in more collisions rather than fewer.
>>>
>>
>> Sure, if the server actually randomizes it itself. Perhaps that's worth
>> recommending?
>>
>
> Yeah, I was dragging my feet on this, but inclined the same way.
>
> diff --git a/draft-ietf-dnsop-session-signal.md
> b/draft-ietf-dnsop-session-signal.md
> index a9037e0..85bc28d 100644
> --- a/draft-ietf-dnsop-session-signal.md
> +++ b/draft-ietf-dnsop-session-signal.md
> @@ -1463,6 +1463,12 @@ are described in {{delay}}.
>  After sending a Retry Delay message,
>  the server MUST NOT send any further messages on that DSO Session.
>
> +The server MAY randomize retry delays in situations where many retry
> delays are sent
> +in quick succession, so as to avoid all the clients attempting to
> reconnect at once.
> +In general, implementations should avoid using the Retry Delay message in
> a way that
> +would result in many clients reconnecting at the same time, if every
> client attempts
> +to reconnect at the exact time specified.
> +
>  Upon receipt of a Retry Delay message from the server,
>  the client MUST make note of the reconnect delay for this server,
>  and then immediately close the connection gracefully.
> @@ -1520,7 +1526,9 @@ or by forcibly aborting the underlying transport
> connection)
>  the client SHOULD try to reconnect,
>  to that service instance, or to another suitable service instance, if
> more than one is available.
>  If reconnecting to the same service instance, the client MUST respect the
> indicated delay,
> -if available, before attempting to reconnect.
> +if available, before attempting to reconnect.   Clients should not
> attempt to randomize the delay;
> +the server will randomly jitter the retry delay values it sends to client
> if this behavior is
> +desired.
>

LGTM.



>  If the service instance will only be out of service for a short
> maintenance period,
>  it should use a value a little longer that the expected maintenance
> window.
>
>
>> Mostly I just missed this. With that said, generally we are discouraging
>> compression in cryptographic protocols.
>> OTOH, I'm not that worried about the covert-channel either, so it's kind
>> of a tossup
>>
>
> OK.   I'm going to call it done then, at least until we hear back from
> Stuart and Mirja.
>

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

Re: [DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-session-signal-12: (with COMMENT)

[Eric Rescorla]

On Tue, Jul 31, 2018 at 7:28 PM, Ted Lemon  wrote:

> On Tue, Jul 31, 2018 at 6:28 PM, Eric Rescorla  wrote:
>
>> IMPORTANT
>> S 5.3.
>> >  field set to zero, and MUST NOT elicit a response.
>> >
>> >  Every DSO request message (QR=0) with a nonzero MESSAGE ID field is
>> >  an acknowledged DSO request, and MUST elicit a corresponding
>> response
>> >  (QR=1), which MUST have the same MESSAGE ID in the DNS message
>> header
>> >  as in the corresponding request.
>>
>> How do I handle duplicate message IDs on the responder? Did I miss
>> where you said this? Is this just an error?
>>
>
> In order for the responder to detect this condition, it has to track
> message IDs.   The existing implementation that I have doesn't track
> message IDs—it just responds with the message ID that it got.   There's no
> hash table of known incoming message IDs, and maintaining such a table
> would add complexity.   I think that this is okay, because it's the
> requester that loses in this case—it's effectively attacking itself.
>  However, if the responder does track message IDs, then it could be an
> issue.   So I've added the following text:
>
>  If a client or server receives a response (QR=1) where the MESSAGE ID is
> zero, or is
>  any other value that does not match the MESSAGE ID of any of its
> outstanding operations,
>  this is a fatal error and the recipient MUST forcibly abort the
> connection immediately.
>
> +If a responder receives a request (QR=0) where the MESSAGE ID is not
> zero, and
> +the responder tracks query MESSAGE IDs, and the MESSAGE ID
> +matches the MESSAGE ID of a query it received for which a response has
> not yet been sent,
> +it MUST forcibly abort the connection immediately.   This behavior is
> required to prevent
> +a hypothetical attack that takes advantage of undefined behavior in this
> case.   However,
> +if the server does not track MESSAGE IDs in this way, no such risk
> exists, so tracking
> +MESSAGE IDs just to implement this sanity check is not required.
>
>  Does this address your concern?
>

Yeah, this seems fine. Didn't mean to make you do a lot of work here, just
noticed as I was reading.

>
>
>> S 9.3.
>> >
>> >  Requests to register additional new DSO Type Codes in the
>> >  "Unassigned" range 0040-F7FF are to be recorded by IANA after
>> Expert
>> >  Review [RFC8126].  At the time of publication of this document, the
>> >  Designated Expert for the newly created DSO Type Code registry is
>> >  [*TBD*].
>>
>> What is the standard for the expert to follow
>>
>
> I added this (the text has changed somewhat as a result of a previous
> comment):
>
>  Requests to register additional new DSO Type Codes
>  in the "Unassigned" range 0040-F7FF
>  are to be recorded by IANA after Expert Review {{!RFC8126}}.
> +The expert review should validate that the requested type code
> +is specified in a way that conforms to this specification, and
> +that the intended use for the code would not be addressed with
> +an experimental/local assignment.
>
>  DSO Type Codes in the "experimental/local" range F800-FBFF
>  may be used as Experimental Use or Private Use values {{!RFC8126}}
>
> OK?
>

LGTM.



>
>> COMMENTS
>> S 1.
>> >  is appended to the end of the DNS message header.  When displayed
>> >  using packet analyzer tools that have not been updated to recognize
>> >  the DSO format, this will result in the DSO data being displayed as
>> >  unknown additional data after the end of the DNS message.  It is
>> >  likely that future updates to these tools will add the ability to
>> >  recognize, decode, and display the DSO data.
>>
>> I'm sure you will get to this soon, but what are the backward
>> compatibility implications for the two endpoints.
>>
>
> Do you mean in terms of requesters and responders that don't implement DSO
> but receive a DSO message?   I think we've specified that adequately—the
> responder is expected to return "Not Implemented" because of the status
> code.   As I mentioned in a different response, this is the behavior of at
> least BIND 9 and Google's 8.8.8.8 server.   1.1.1.1 just didn't reply to
> the message.   So I realized, and maybe this is what you intended me to
> realize, that the text doesn't address several possible outcomes of trying
> to establish a DSO session.   I believe the following changes should do it:
>
>  sending DNS messa

[DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-session-signal-12: (with COMMENT)

[Eric Rescorla]

Eric Rescorla has entered the following ballot position for
draft-ietf-dnsop-session-signal-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/



--
COMMENT:
--

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4358



IMPORTANT
S 5.3.
>  field set to zero, and MUST NOT elicit a response.
>   
>  Every DSO request message (QR=0) with a nonzero MESSAGE ID field is
>  an acknowledged DSO request, and MUST elicit a corresponding response
>  (QR=1), which MUST have the same MESSAGE ID in the DNS message header
>  as in the corresponding request.

How do I handle duplicate message IDs on the responder? Did I miss
where you said this? Is this just an error?


S 9.3.
>   
>  Requests to register additional new DSO Type Codes in the
>  "Unassigned" range 0040-F7FF are to be recorded by IANA after Expert
>  Review [RFC8126].  At the time of publication of this document, the
>  Designated Expert for the newly created DSO Type Code registry is
>  [*TBD*].

What is the standard for the expert to follow

COMMENTS
S 1.
>  is appended to the end of the DNS message header.  When displayed
>  using packet analyzer tools that have not been updated to recognize
>  the DSO format, this will result in the DSO data being displayed as
>  unknown additional data after the end of the DNS message.  It is
>  likely that future updates to these tools will add the ability to
>  recognize, decode, and display the DSO data.

I'm sure you will get to this soon, but what are the backward
compatibility implications for the two endpoints.


S 3.
>  The unqualified term "session" in the context of this document means
>  the exchange of DNS messages over a connection where:
>   
>  o  The connection between client and server is persistent and
> relatively long-lived (i.e., minutes or hours, rather than
> seconds).

This is a surprising taxonomy. I would assume that some of the options
you are proposing would be relevant with a 30s connection (very long
by HTTP standards!)


S 3.
>  Where this specification says, "close gracefully," that means sending
>  a TLS close_notify (if TLS is in use) followed by a TCP FIN, or the
>  equivalents for other protocols.  Where this specification requires a
>  connection to be closed gracefully, the requirement to initiate that
>  graceful close is placed on the client, to place the burden of TCP's
>  TIME-WAIT state on the client rather than the server.

Does this mean that the server will ask the client to close?


S 3.
>  connection to be closed gracefully, the requirement to initiate that
>  graceful close is placed on the client, to place the burden of TCP's
>  TIME-WAIT state on the client rather than the server.
>   
>  Where this specification says, "forcibly abort," that means sending a
>  TCP RST, or the equivalent for other protocols.  In the BSD Sockets

Because you bother to mention TLS above, what about non-close_notify
TLS alerts?


S 3.
>  the server's listening socket.
>   
>  The terms "initiator" and "responder" correspond respectively to the
>  initial sender and subsequent receiver of a DSO request message or
>  unacknowledged message, regardless of which was the "client" and
>  "server" in the usual DNS sense.

Might be helpful to say earlier that this is a request/response
protocol


S 3.
>   
>  DNS Stateful Operations uses three kinds of message: "DSO request
>  messages", "DSO response messages", and "DSO unacknowledged
>  messages".  A DSO request message elicits a DSO response message.
>  DSO unacknowledged messages are unidirectional messages and do not
>  generate any response.

This would be useful further up.


S 5.1.
>   
>  DNS over plain UDP [RFC0768] is not appropriate since it fails on the
>  requirement for in-order message delivery, and, in the presence of
>  NAT gateways and firewalls with short UDP timeouts, it fails to
>  provide a persistent bi-directional communication channel unless an
>  excessive amount of keepa

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

[Eric Rescorla]

On Mon, Oct 4, 2010 at 7:56 AM, Joe Abley  wrote:

> Hi,
>
> On 2010-10-04, at 10:31, Eric Rescorla wrote:
>
> > On Sun, Oct 3, 2010 at 10:54 AM, Joe Abley  wrote:
> >
> >> On 2010-10-03, at 13:31, Eric Rescorla wrote:
> >>
> >> > I'm asking because I'm pretty familiar with cryptography and I know
> that keys don't suddenly become
> >> > worthless just because they get past their intended use lifetime. The
> semantics of signature
> >> > security of old keys is a lot more complicated than that.
> >>
> >> The context here is the publication of DNSSEC trust anchors for the root
> zone.
> >>
> >> At least some of the cases we're talking about involve signatures
> necessarily made by keys after an emergency key roll which has taken place
> because the old key has been compromised. Such signatures are worthless.
> >>
> >
> > I don't think this follows.
>
> In the context of our discussion, it does. We are discussing arrangements
> for publishing a trust anchor for a key whose management has already been
> carefully specified, and does not include (for example) pre-generation of
> the next key in the way you suggest.
>

Carefully specified, perhaps, but what you're saying here also makes me
think it was
also incorrectly specified, since, as I said, the technique I described is
well-known,
and failing to do so leads to precisely the complications that are at issue
here.

So, rather than designing a bunch of kludgy workarounds, it would be better
to ask
what the right thing to do is, even if that requires changing some
preexisting
document.

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

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

[Eric Rescorla]

On Mon, Oct 4, 2010 at 7:56 AM, Joe Abley  wrote:

> Hi,
>
> On 2010-10-04, at 10:31, Eric Rescorla wrote:
>
> > On Sun, Oct 3, 2010 at 10:54 AM, Joe Abley  wrote:
> >
> >> On 2010-10-03, at 13:31, Eric Rescorla wrote:
> >>
> >> > I'm asking because I'm pretty familiar with cryptography and I know
> that keys don't suddenly become
> >> > worthless just because they get past their intended use lifetime. The
> semantics of signature
> >> > security of old keys is a lot more complicated than that.
> >>
> >> The context here is the publication of DNSSEC trust anchors for the root
> zone.
> >>
> >> At least some of the cases we're talking about involve signatures
> necessarily made by keys after an emergency key roll which has taken place
> because the old key has been compromised. Such signatures are worthless.
> >>
> >
> > I don't think this follows.
>
> In the context of our discussion, it does. We are discussing arrangements
> for publishing a trust anchor for a key whose management has already been
> carefully specified, and does not include (for example) pre-generation of
> the next key in the way you suggest.
>

Carefully specified, perhaps, but what you're saying here also makes me
think it was
also incorrectly specified, since, as I said, the technique I described is
well-known,
and failing to do so leads to precisely the complications that are at issue
here.

So, rather than designing a bunch of kludgy workarounds, it would be better
to ask
what the right thing to do is, even if that requires changing some
preexisting
document.

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

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

[Eric Rescorla]

I think it would depend on the HSMs. In at least some of them, it's the card
keys that are important and you could have a disjoint set of card keys for
K_{n+1}

-Ekr


On Mon, Oct 4, 2010 at 7:52 AM, Paul Hoffman  wrote:

> At 7:31 AM -0700 10/4/10, Eric Rescorla wrote:
> >On Sun, Oct 3, 2010 at 10:54 AM, Joe Abley <<mailto:jab...@hopcount.ca>
> jab...@hopcount.ca> wrote:
> >
> >
> >On 2010-10-03, at 13:31, Eric Rescorla wrote:
> >
> >> I'm asking because I'm pretty familiar with cryptography and I know that
> keys don't suddenly become
> >> worthless just because they get past their intended use lifetime. The
> semantics of signature
> >> security of old keys is a lot more complicated than that.
> >
> >The context here is the publication of DNSSEC trust anchors for the root
> zone.
> >
> >At least some of the cases we're talking about involve signatures
> necessarily made by keys after an emergency key roll which has taken place
> because the old key has been compromised. Such signatures are worthless.
> >
> >
> >I don't think this follows.
> >
> >It's pretty commonly suggested that at the time you roll out key K_n you
> also *immediately* generate
> >key K_{n+1} and produce a certificate signing K_{n+1} with K_n. Since all
> that is required for security
> >is that the signature itself take place prior to the compromise of K_n
> this allows for rollover even
> >if K_n is subsequently compromised, provided that the relying party can
> verify that the signature
> >on K_{n+1} was computed before the compromise date. There are a variety of
> techniques for
> >doing this, e.g., hash commitment, Haber-Stornetta timestamping, etc.
>
> Does the "create your next key immediately" process work with HSMs if you
> don't have 2x the number you would normally have in production? I'm no fan
> of HSMs for a system like DNSSE that often needs operational agility, but it
> seems like I'm in the minority here.
>
> --Paul Hoffman, Director
> --VPN Consortium
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

[Eric Rescorla]

On Sun, Oct 3, 2010 at 10:54 AM, Joe Abley  wrote:

>
> On 2010-10-03, at 13:31, Eric Rescorla wrote:
>
> > I'm asking because I'm pretty familiar with cryptography and I know that
> keys don't suddenly become
> > worthless just because they get past their intended use lifetime. The
> semantics of signature
> > security of old keys is a lot more complicated than that.
>
> The context here is the publication of DNSSEC trust anchors for the root
> zone.
>
> At least some of the cases we're talking about involve signatures
> necessarily made by keys after an emergency key roll which has taken place
> because the old key has been compromised. Such signatures are worthless.


I don't think this follows.

It's pretty commonly suggested that at the time you roll out key K_n you
also *immediately* generate
key K_{n+1} and produce a certificate signing K_{n+1} with K_n. Since all
that is required for security
is that the signature itself take place prior to the compromise of K_n this
allows for rollover even
if K_n is subsequently compromised, provided that the relying party can
verify that the signature
on K_{n+1} was computed before the compromise date. There are a variety of
techniques for
doing this, e.g., hash commitment, Haber-Stornetta timestamping, etc.

-Ekr



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

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

[Eric Rescorla]

On Sun, Oct 3, 2010 at 10:18 AM, Joe Abley  wrote:

>
> On 2010-10-03, at 12:32, Eric Rescorla wrote:
>
> > Why?
>
> Are you asking because you've reviewed those discussions and have issues
> with them, or because you didn't review those discussions?
>


I'm asking because I'm pretty familiar with cryptography and I know that
keys don't suddenly become
worthless just because they get past their intended use lifetime. The
semantics of signature
security of old keys is a lot more complicated than that.

If there's some particular discussion that you'd like me to review that
makes the case that
this is different, please point me at it.



>
> I'm not entirely sure the answer shouldn't be "because we manage the keys,
> and we say so" actually.


If that's the answer, then I most certainly do not agree.

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

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

[Eric Rescorla]

Why?

Ekr

On Oct 3, 2010, at 8:54, Joe Abley  wrote:

> 
> On 2010-10-03, at 07:59, Tony Finch wrote:
> 
>> On 3 Oct 2010, at 08:27, Jakob Schlyter  wrote:
>>> On 1 okt 2010, at 20.59, Tony Finch wrote:
 
 Right, so it's aimed at human consumption rather than automatic tools?
>>> 
>>> Given the historical information (together with old DNSKEY), you could 
>>> build a trust anchor history zone.
>> 
>> Not really, since you need the private key of the old TA to sign the public 
>> key of the new one to get a cryptographic proof of the history. Without that 
>> it is just a third party attestation, which is rather weaker.
> 
> As has been expressed many times, old keys are not trustworthy and hence 
> their signatures have no value.
> 
> 
> Joe
> 
> ___
> 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] RFC4641-bis: The case for single active key

[Eric Rescorla]

On Thu, Jun 17, 2010 at 2:15 PM, Olafur Gudmundsson  wrote:
> Background #3: Key strengths and life time
> RSA and DSA algorithms have the interesting property that the number of bits
> in the key can be selected, by adding bits to the key the key gets stronger.
> Stronger keys can be used longer.

I know I'm repeating myself, but this is simply not correct for any plausible
lifetimes or key sizes I've provided my analysis several times:

http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html

If you have some analysis that supports this argument please post it.

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

Re: [DNSOP] RFC4641bis version 02.

[Eric Rescorla]

On Mon, Mar 1, 2010 at 8:45 AM, Chris Thompson  wrote:
> On Mar 1 2010, Eric Rescorla wrote:
>
>> [...] If a key is breakable at cost C in M months, then it's breakable
>> at cost Cx in M/x months.
>
> This isn't true in general (although it may be sufficiently so in the
> cases under discussion). In particular, not all stages of NFS factorisation
> attempts are easily distributable to many small processors. The sieving
> stage is, but distributing the matrix reduction stage is much harder (and
> a hot research topic).
>
> Recommended background reading: http://eprint.iacr.org/2010/006.pdf

Yes, this is correct, but I believe it is true for the values of x under
discussion.

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

Re: [DNSOP] RFC4641bis version 02.

[Eric Rescorla]

On Mon, Mar 1, 2010 at 5:26 AM, Rose, Scott W.  wrote:
> The 1024 bit key guideline is for response sizes (biggest stumbling block
> we've encountered so far in .gov deployment).
>
> The rollover frequency is largely based on an extended time frame.  The
> extended roadmap is to try and migrate to ECC by 2015, and there is some
> belief that 1024 bit RSA might become "breakable" in months (with reasonable
> cost - for some definition of "reasonable") by 2015.  I remember some paper
> being reference, but I don't recall which one.  And no, I don't fully
> understand all of it either, but the near goal (response size) was met,
> which was the primary concern for now given the deployment deadlines within
> Federal IT security.

I don't really see how this addresses the question without some definition of
"reasonable". If a key is breakable at cost C in M months, then it's breakable
at cost Cx in M/x months. Since the x values we're talking about here are
on the order of 10, then you're basically claiming that you can estimate
the attacker's capabilities to within a factor of 5-10, which seems fairly
implausible.

Even if you do think this is true, it would be far more effective to simply use
fractionally larger RSA keys. My understanding is that the major obstacle to
using (for instance) 1100-bit RSA keys is that NIST only accepts a small
number of concrete key sizes for FIPS 140. If so, rather than specifying
a short rollover time, perhaps NIST could address that.


> Overall, US Federal gov't security policy errs on the side of caution.
> Frequent rolling of keys is seen as good practice, even if the evidence on
> its effectiveness isn't fully proven.

It's not at all clear to me that this errs on the side of caution. After all,
there are potential risks of exposure with rolling keys all the time,
since it comes with higher management overhead.
-Ekr
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] RFC4641bis version 02.

[Eric Rescorla]

On Mon, Mar 1, 2010 at 4:57 AM, Rose, Scott W.  wrote:
> On 2/26/10 4:51 PM, "Paul Wouters"  wrote:
>
>> On Fri, 26 Feb 2010, Thierry Moreau wrote:
>
>>
>>> Basically, you adhere to (B) and suggest 1024-bits/1-month-cryptoperiod,
>>> hence you inflate the requirements over NIST's.
>>
>> I am not inflating NIST's requirements. I believe 1024 bit RSA with monthly
>> rollover is fine, whereas NIST recommends to migrate to 2048 bit for that.
>>
>
> NIST's recommendations are for 2048 bit RSA, rolled every 1-3 years.  These
> recommendations are based on PKI and/or SSL certs mostly, not DNSSEC.  For
> DNSSEC, we made a compromise to allow 1024 bit RSA keys around for a while
> if we also recommended rolling more frequently.

OK, but I don't understand the technical basis for this recommendation. It just
seems like it makes running 1024-bit keys inconvenient without adding any
significant increase in security. Did NIST provide a rationale?

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

Re: [DNSOP] RFC4641bis version 02.

[Eric Rescorla]

On Fri, Feb 26, 2010 at 11:41 AM, Paul Wouters  wrote:
> On Fri, 26 Feb 2010, Eric Rescorla wrote:
>
>>  For
>>  reasons of signing speed and DNS packet length one may want to keep
>>  keylenght at a minimal responsible length and change the key
>>  relatively frequently while not interacting with the parent.
>>
>> This statement is a non-sequiter. Sure, one may want to keep the keylength
>> short to improve signing speed, but since changing the key frequently
>> doesn't
>> significantly improve security against analysis (as has been covered
>> on-list
>> ad nauseum), the last half of the sentence doesn't make any sense.
>
> cycling a 1024 bit RSA key every month does improve the security of a zone,
> compared to not cycling the key.
>
> Cryptanalyses is a function of time (and money). If you reduce the usable
> time for attackers, their spending goes up or they will not have enough time
> to break the key before it is retired.

Yes, it increases their spending by the ratio of the frequency of the
key cycling to the original cycle time. For instance cycling at the rate
of monthly instead of a year adds approximately 3.6 bits of security,
equivalent to about an 1100 bit of RSA key
(calculations here:
http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html)

As I said, this is a trivial improvement.


> The recommended key size and time
> in the document reflects current cryptographers extremely conservative
> estimate of what is deemed safe by a few orders of magnitudes.

Really? Which cryptographers recommend rolling over keys monthly?

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

Re: [DNSOP] RFC4641bis version 02.

[Eric Rescorla]

S 3.1.1:

   Finally there is a risk of cryptanalysis of the key material.  The
   cost of such analysis are correlated to the length of the key and the
   amount of signed material that is available to the analyst.

This statement is false for RSA and as far as a I know, for
any major signature algorithm: RSA is not weakened by the attacker
having a large number of plaintext/ciphertext pairs. [Historical
note: this used to be a problem with symmetric ciphers but is
now mostly just habit. Modern cryptographic algorithms shouldnt
exhibit analytic weaknesses with any practical amount of known
plaintext.]


   For
   reasons of signing speed and DNS packet length one may want to keep
   keylenght at a minimal responsible length and change the key
   relatively frequently while not interacting with the parent.

This statement is a non-sequiter. Sure, one may want to keep the keylength
short to improve signing speed, but since changing the key frequently doesn't
significantly improve security against analysis (as has been covered on-list
ad nauseum), the last half of the sentence doesn't make any sense.

-Ekr



On Fri, Feb 26, 2010 at 12:06 AM, Olaf Kolkman  wrote:
>
>
>
> Colleagues,
>
> I have just posted RFC4641bis version 2.
>
> The document contains a number of significant changes which address a number 
> of the open-issues (see 
> http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/). In some cases 
> text has been rewritten in such a way that it is not immediately obvious if 
> some of the open issues are still relevant. Since today was the last 
> opportunity for me to submit the document before the cut-off and I believe 
> the text is close enough for review on substance and gathering feedback.
>
> Although a review on (english) style, nits and spelling would be appreciated 
> I believe that can wait until the review on substance has taken place.
>
>
> http://www.ietf.org/id/draft-ietf-dnsop-rfc4641bis-02.txt
>
> Once the document is available through the tools interface you should be able 
> to study the diffs.
> http://tools.ietf.org/html/draft-ietf-dnsop-rfc4641bis
>
>
> --Olaf
>
> 
>
> Olaf M. Kolkman                        NLnet Labs
>                                       Science Park 140,
> http://www.nlnetlabs.nl/               1098 XG Amsterdam
>
> ___
> 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] rfc4641bis: NSEC vs NSEC3.

[Eric Rescorla]

On Mon, Feb 22, 2010 at 4:24 PM, Mark Andrews  wrote:
>
> In message , Eric 
> R
> escorla writes:
>> Well, IMO we shouldn't have addressed this in RFC 5155 either. It falls
>> into the category of "basic assumptions"
>
> Basic assumptions should be noted.

Should we also note the Heisenberg uncertainty principle? general relativity?
The law of the excluded middle?

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

Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

[Eric Rescorla]

On Mon, Feb 22, 2010 at 11:59 AM, Evan Hunt  wrote:
>> I have not seen anyone make a statement "NSEC3 is exactly as good as NSEC".
>>
>> I've seen the opposite by Mark Andrews:
>>
>>   "Actually NSEC is technically better at proving non-existance."
>
> Mark was responding to an assertion to the contrary ("one is NOT better
> than the other") by making a boundary-condition quibble.  I'm not sure
> whether he was arguing that the quibble should be noted in the draft
> or merely being pedantic, so I won't speak for him, but I personally
> think precision is a worthwhile goal here.
>
> Note that RFC 5155 takes the time to put the issue to rest not once but
> twice:
>
>    Note that with the hash algorithm specified in this document,
>    SHA-1, such collisions are highly unlikely.
>
>    Hash collisions between QNAME and the owner name of an NSEC3 RR
>    may occur.  When they do, it will be impossible to prove the
>    non- existence of the colliding QNAME.  However, with SHA-1,
>    this is highly unlikely (on the order of 1 in 2^160).  Note that
>    DNSSEC already relies on the presumption that a cryptographic
>    hash function is second pre-image resistant, since these hash
>    functions are used for generating and validating signatures and
>    DS RRs.
>
> ... so I don't understand why 4641bis should not do so even once.  (But
> this conversation has already taken more time than the probability of a
> random collision really merits, so whatever.)

Well, IMO we shouldn't have addressed this in RFC 5155 either. It falls
into the category of "basic assumptions"

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

Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

[Eric Rescorla]

On Mon, Feb 22, 2010 at 9:23 AM, Evan Hunt  wrote:
>> This is absurd. If we're going to do this, I'd like the security
>> considerations to reflect all of the non-zero probabilities of errors
>> occuring (those that have a higher probability).
>
> I just answered this point in private mail to someone else, failing to
> realize until after I'd sent it that it was off-list, so I'll repeat
> myself...
>
> My point is not to say that hash collisions are a problem or that NSEC3 is
> a poor choice.  My point is that it's bad form to make mathematically false
> statements--even if they're *almost completely* true--and especially so
> when you get anywhere near cryptographers.
>
> "NSEC3 is exactly as good as NSEC" is a mathematical statement.  It's very,
> very close to true, but in math that still makes it false.  "NSEC3 is as
> good as NSEC except under conditions so fantastically improbable that it's
> safe to ignore them" is a few more words, but has the benefit of actually
> being *true*, and I think that's what the draft should say.

Well, I wouldn't want to say "NSEC3 is exactly as good as NSEC" in any
case, since
it's not true. It's more inconvenient to implement, and somewhat more secure.

So, I agree that we shouldn't say things that are factually false, but I'm not
overly concerned about this.

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

Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

[Eric Rescorla]

On Mon, Feb 22, 2010 at 8:52 AM, Roy Arends  wrote:
> On Feb 22, 2010, at 11:12 AM, Evan Hunt wrote:
>
>>> Using NSEC instead of NSEC3 because you fear SHA1 collisions does not
>>> seem sensible, as if you fear SHA1 collisions, you have other more
>>> significant problems with DNSSEC to worry about, and thus this is
>>> not, in my opinion, reasonable. And it isn't sensible to suggest
>>> users worry about it. If we are going to mention it, it should be
>>> in security considerations, saying NSEC3 is dependent upon certain
>>> properties of its hash algorithm (I forget now whether it is
>>> collision resistance, pre-image resistance or or what), but this
>>> should also point out the whole of DNSSEC is predicated on similar
>>> qualities.
>>
>> +1 except for the "if".  It is mathematically possible for collisions to
>> occur with one approach and not the other, and it would be irresponsible
>> not to make note of the fact, even if we agree that the chances of this
>> occurring in nature are negligible.
>
> This is absurd. If we're going to do this, I'd like the security 
> considerations to reflect all of the non-zero probabilities of errors 
> occuring (those that have a higher probability). This includes software-bugs, 
> hardware-bugs, probability of advances in factorization, randomness of PRNG 
> for DNSKEYs, faulty calibration/low granularity of equipment measuring the 
> transition between the two hyperfine levels of the ground state of the 
> caesium 133 atom. Gravitational Sphere of Influence of the 99942 Apophis on 
> the Gravitational orbit of GPS satelites (Still having a higher probability 
> than hash-collisions ;-)), Drunk Sysadmins, Rouge Registrar, etc, etc.
>
> I'm sure that it will be a very large section.

Precisely.

I realize it's hard to grasp precisely how small the statistical
chances of a collision
are, but they are just unbelievably small. Acting as if it is
something that might
actually happen just makes you look silly.

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

Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

[Eric Rescorla]

On Sun, Feb 21, 2010 at 4:22 PM, Mark Andrews  wrote:
>
> In message <315ad36e-879a-4512-a6a8-b64372e3d...@sinodun.com>, John Dickinson 
> w
> rites:
>> Hi,
>>
>> It might also be worth adding a line at the start reminding of the need for N
>> SEC and NSEC3 - namely that the signing and serving of the zone are separate
>> operations and that it is therefore necessry to create records that cover the
>>  very large number of non-existent names that lie between the names that do e
>> xist.
>>
>> NSEC and NSEC3 are just different ways to achieve this goal and some people m
>> ight prefer one above the other. One is NOT better than the other and it is a
>>  matter of operational needs that determine which one you select.
>>
>> It may also be worth removing the mention of cryptographic operations. The ha
>> shing in NSEC3 is just a way to create new names that cover the same spaces.
>> I imagine that many other schemes could have been dreamt up to do this. Hashi
>> ng is just a convenient method.
>>
>> John
>
> Actually NSEC is technically better at proving non-existance.  NSEC3
> has a non zero false positive rate due to the fact that the names
> are hashed.  NSEC has a zero false positive rate.
>
> This is not to say the false positive rate is high enough to stop
> using NSEC3, but that it needs to be acknowledged.

Unless I'm misreading the specifications, unless you're using an extremely
poor or short hash function, the probability of false positive is vanishingly
small (order 2^{-100}). This shouldn't be acknowledged, but rather
should be ignored. Moreover, it appears that NSEC3 has a mechanism
for dealing with it in S C.2.1 (pointless, IMO...)

So, I don't see what the issue is.

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

Re: [DNSOP] rfc4641bis: ZSK-roll-frequency

[Eric Rescorla]

On Fri, Jan 22, 2010 at 12:35 PM, Paul Hoffman  wrote:
> At 8:18 PM + 1/22/10, bmann...@vacation.karoshi.com wrote:
>>On Fri, Jan 22, 2010 at 09:13:22AM -0800, Paul Hoffman wrote:
>>> At 4:56 PM + 1/22/10, Tony Finch wrote:
>>> >On Thu, 21 Jan 2010, Paul Hoffman wrote:
>>> >>
>>> >> - Regular rolling can give you a false sense of security about your 
>>> >> rolling process
>>> >
>>> >How can you have any sense of security about your rolling process if you
>>> >don't exercise it?
>>>
>>> Why do people think the opposite of "regular" is "never"?
>>>
>>> --Paul Hoffman, Director
>>
>>
>>       to borrow from Andrew - let me posit an analogy...
>>
>>       would you rather have your LASIX or LIOP  surgery done
>>       by someone who has done 12,000 such procedures and
>>       does a couple a week or someone who has done a dozen
>>       and does them about every couple years or so?
>>
>>       sure, the doctor who does them all the time -might- get
>>       sloppy and cut corners  --  but is that worse than someone
>>       who has only passing understanding of what they are actually
>>       doing?
>>
>>       the risk isn't -never-, the risk is lack of experience.
>
> Why do people think this is about "the risk" instead of "the risks"?

I haven't formed a useful opinion one way or the other about the operational
value of frequent key rollovers. However, it seems to me that the value
of those practices is more or less independent of key size, so we've
travelled fairly far afield from the original claim that we need rollovers
to compensate for being forced to use overly-short RSA keys.

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

Re: [DNSOP] rfc4641bis: ZSK-roll-frequency

[Eric Rescorla]

On Thu, Jan 21, 2010 at 9:09 PM, Paul Wouters  wrote:
> On Thu, 21 Jan 2010, Eric Rescorla wrote:
>
>>>> The point is that the numbers depend on your model of the attacker
>>>> more than on the cryptography.
>
>> Yes, but my point is that the safety period depends on your assumptions
>> about the attacker's resources, which is why this is not really a
>> technical
>> issue.
>
> It is also based on the presumed technological advances of attackers. If
> you talk to a cryptographer about a 1024 bit RSA key, they will tell you
> "don't use that anymore". When you tell them "well, it is very useful
> to us to reduce packet size in DNS" they tell you "go use ECC".
>
> We made a technological trade of. Though extremely conservative, all the
> cryptographers (or really cryptanalysts) I talked to are more conservative
> then we have been. Whether you call this technical or philosophical, does
> not really change the issue. The model of the attacker is a fundamental
> part of the cryptography.

I really have no idea what you're talking about here. There is widespread
agreement about the technical difficulty of attacking RSA. The question
of how that impacts your behaviors has primarily an economic question,
not a cryptographic one.

With that said, cryptographers actually don't tend to think particularly deeply
about the attack model; rather they assume a certain fairly idealized model
of attacker capabilities and try to demonstrate that their systems have
certain properties under those models. This is fundamentally different
from the kind of thinking required here.

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

Re: [DNSOP] rfc4641bis: ZSK-roll-frequency

[Eric Rescorla]

On Thu, Jan 21, 2010 at 3:08 PM, Paul Wouters  wrote:
> On Thu, 21 Jan 2010, Eric Rescorla wrote:
>
>>> Also, consider this paper from July 2009:
>>>
>>> https://documents.epfl.ch/users/l/le/lenstra/public/papers/ecdl.pdf
>>>
>>>    Next considering special purpose hardware, the most optimistic
>>>    approach suggests that sieving for a 1024-bit RSA modulus can be
>>>    done in a year for about US $10,000,000, plus a one-time development
>>>    cost of about US $20,000,000,
>>
>>
>> And if your attacker has a budget of $1,000,000? Or $100,000,000?
>>
>> The point is that the numbers depend on your model of the attacker
>> more than on the cryptography.
>
> The full paper has a cost matrix. Though I just noticed they changed the
> URL of the paper :(

Yes, but my point is that the safety period depends on your assumptions
about the attacker's resources, which is why this is not really a technical
issue.

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

Re: [DNSOP] rfc4641bis: ZSK-roll-frequency

[Eric Rescorla]

On Thu, Jan 21, 2010 at 2:24 PM, Paul Wouters  wrote:
> On Thu, 21 Jan 2010, Edward Lewis wrote:
>
>> What I'd like to hear is:
>>
>> "Crypto-expert __ says an RSA-SHA256 key of 1024 bits is good for
>> ___ signatures/days."
>
> I did ask my local Waterloo based cryptographer (Ian Goldberg) this
> question about a year ago for RSA-SHA1. And apart from his advise to use
> RSASSA-PSS and not PKCS1-v1_5, he thought a year would be extremely safe.
> I just asked another Toronto based cryptographer, Kelly Rose, the same
> question, and he said he would not trust it for more then two years.
>
> Also, consider this paper from July 2009:
>
> https://documents.epfl.ch/users/l/le/lenstra/public/papers/ecdl.pdf
>
>    Next considering special purpose hardware, the most optimistic
>    approach suggests that sieving for a 1024-bit RSA modulus can be
>    done in a year for about US $10,000,000, plus a one-time development
>    cost of about US $20,000,000,


And if your attacker has a budget of $1,000,000? Or $100,000,000?

The point is that the numbers depend on your model of the attacker
more than on the cryptography.

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

Re: [DNSOP] rfc4641bis: ZSK-roll-frequency

[Eric Rescorla]

Again, I don't feel strongly about this, but I don't really find this
very convincing.

Presumably there are all sorts of other credentials that control access to the
ZSK (e.g., administrator SSH private keys, root passwords, etc.) Do you also
propose to roll all of these every month? If not, why not?

-Ekr


On Thu, Jan 21, 2010 at 1:19 PM, David Conrad  wrote:
> On Jan 21, 2010, at 1:14 PM, Edward Lewis wrote:
>> Perhaps monthly rolls aren't needed for crypto-sake, but the more apparent 
>> this is the more apparent we need regular rolls for operations-sake.
>
> Thanks.
>
> While I might agree that _theoretically_ longer keys and/or better algorithms 
> removes or at least reduces the need to do frequent roles, the operational 
> reality empirically proven in a variety of fields is that if you don't 
> exercise stuff, it is going to break when you need it.
>
> Regards,
> -drc
>
> ___
> 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] rfc4641bis: ZSK-roll-frequency

[Eric Rescorla]

On Thu, Jan 21, 2010 at 11:38 AM, Paul Hoffman  wrote:
> At 2:17 PM -0500 1/21/10, Edward Lewis wrote:
>>At 11:05 -0800 1/21/10, Eric Rescorla wrote:
>>>I still don't understand why this implies the need for regular changes
>>>as opposed to changes triggered by personnel changes.
>>
>>I'm a bit lost following this thread now.
>>
>>For the time being, let's ignore personnel changes and whether a key is in an 
>>HSM (environment), i.e., assume there's no organizational threat to a key.
>>
>>The question is, how long does a key last?
>>
>>Meaning - if I am using an RSA-SHA256 key of 1024 bits, at what point does 
>>it's security value reach essentially 0?
>>
>>Is the point X number of signatures?
>
> No. There is no suspicion on the part of any cryptographer that I know of 
> that the number of visible signatures is significant for a 1024-bit or above 
> key.

Agreed. Recall that with PKC an attacker can generate as many
plaintext/ciphertext pairs as
he wants.


>>Is the point Y number of days?
>
> Yes, if the number of days is in the thousands (currently) and the value of 
> this key is high. Otherwise, no.

I actually sort of disagree with this. I don't see how to evaluate
this question in a meaningful
way, and it's not a cryptographic question. Let's say for the sake of
argument that we know
if requires C CPU-hours to break a key and that each CPU costs $H but
is free to run once
you own it (not true). In that case, an attacker with $D to spend can
break a single key in
C/(D/H) hours.  How long is that key secure for? Who knows. Most of
the variance is in attacker
motivation and funding, not time.



> For most keys, no, at least for the next five years or so. That is, the 
> *cost* of breaking a 1024-bit key, when that is feasible, is still much 
> higher than the value of the broken key. Remember that a broken signing key 
> is only valuable until the fact that it is broken is discovered and fixed. 
> So, even if an attacker breaks your signing key, when he/she starts to use it 
> for nefarious purposes and you discover that, you roll your key and the 
> entire time of breaking the new key must be used again before they can mount 
> another attack.

Exactly. So rolling it preemptively doesn't help much.

-Ekr


>>The "need for regular changes" stems from assumptions made in the early days 
>>of DNSSEC development that have gone pretty much unchallenged until recently. 
>> The door is open to (re)visit this topic, if anyone wants to venture 
>>opinions.
>
> See above. :-)

So, the referenced post summarizes my opinion. I don't care enough about it to
fight it to the death here, however.


>>What I'd like to hear is:
>>
>>"Crypto-expert __ says an RSA-SHA256 key of 1024 bits is good for 
>>___ signatures/days."
>
> If you hear that, the the value for the first variable will be worthless. You 
> have to factor in the value of the key to the attacker for the short period 
> in which they can use it before their actions are discovered and the broken 
> key is replaced.


I more or less agree with this. You may want to hear that, but there's
no meaningful answer.

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

Re: [DNSOP] rfc4641bis: ZSK-roll-frequency

[Eric Rescorla]

I still don't understand why this implies the need for regular changes
as opposed
to changes triggered by personnel changes.

-Ekr


On Thu, Jan 21, 2010 at 10:03 AM, Paul Wouters  wrote:
> On Thu, 21 Jan 2010, Edward Lewis wrote:
>
>> If I were to fit this into the text below...
>>
>> #
>> #        The motivation for having the KSK's effectivity period
>> #        longer than the ZSK's effectivity period is rooted in the
>> #        operational consideration that a change in the KSK involves
>> #        interaction with an external entity, usually the parent zone
>> #        or possibly a trust anchor repository, and this interaction
>> #        is anticipated to have significant latency (including the
>> #        need to verify the other party has made the necessary change.
>> #
>
> Maybe make it more explicit that an intra-organisation key change can
> and probably should happen frequently, where-as an inter-organisational
> key change, because it involves other organisations, is more difficult
> and should be kept to a minimum?
>
> Again, think of a zone administrator who had access to a private ZSK
> leaving your organisation. It would be a good security policy to rollover
> the ZSK as part of the procedure of revoking this person's access to
> the organisation. And a good reason to have an HSM so you do not need
> to do the same with the KSK.
>
> Paul
> ___
> 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] rfc4641bis: ZSK-roll-frequency

[Eric Rescorla]

I'm not really an active member of the WG, so I certainly wouldn't say that
my position has much of an affect on consensus, but I'm unconvinced
by the argument offered below.

Sure, the ZSK is at greater risk because operators have access to it, but
so what? If an operator actually steals the key (or, say, is fired), you
change the key then. However, given that you allow the operator to sign
stuff with the key as long as he's employed, I don't see how repeatedly
changing it during that period offers much value at all.

-Ekr


On Thu, Jan 21, 2010 at 5:28 AM, Olaf Kolkman  wrote:
>
>
> As a reminder: http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ has 
> the open issues listed and a per issue highlight of their history.
>
> This issue is captured in
> http://www.nlnetlabs.nl/svn/rfc4641bis/trunk/open-issues/ZSK-roll-frequency
> current content of that page is replicated below.
>
> I welcome substantive discussion on-list while I'd be happy to receive 
> editorial comments off-list
>
> If the chair believes the current text captures consensus I will move this 
> issue to the closed issues list.
>
> --Olaf
>
>
> $Id: ZSK-roll-frequency 31 2009-10-07 08:19:53Z olaf $
> 2008090101
>   ZSK-roll-frequency
>   EKR/ Paul Hoffman
>   Added: 7 Oct 2009
>
> See:
> http://www.educatedguesswork.org/2009/10/on_the_security_of_zsk_rollove.html
>
>
> Rfc4641 argues for frequent ZSK rollovers, the argument therein is
> based on operational arguments that are (implicitly) based on operator
> acces to private keys and/or the timeline in which changes in which
> the (zone) operator may need to be replaced.
>
> EKRs argument is based on cryptographic strength and argues another view.
>
> The current considerations need to be made more explicit.
>
> Resolution:
>
>
> Added the following paragraph to section 3.3:
>
>        
>          The motivation for having the ZSK's effectivity period
>          shorter than the KSK's effectivity period is rooted in the
>          operational consideration that it is more likely that
>          operators have more frequent read access to the ZSK than to
>          the KSK. If ZSK's are maintained on cryptographic Hardware
>          Security Modules (HSM) than the motivation to have different
>          key effectivity periods is weakend.
>
>        
>
> 
>
> Olaf M. Kolkman                        NLnet Labs
>                                       Science Park 140,
> http://www.nlnetlabs.nl/               1098 XG Amsterdam
>
>
> ___
> 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] [dnsext] Why ZSK rollover is a Bad Idea (tm)

[Eric Rescorla]

On Wed, Oct 7, 2009 at 6:22 AM, Joe Abley  wrote:
> [from a namedroppers thread, re-pointed as per Olaf's suggestion below]
>
> On 2009-10-07, at 09:23, Olaf Kolkman wrote:
>
>> On Oct 6, 2009, at 10:08 PM, Eric Rescorla wrote:
>>
>>> I don't have a general position on ZSKs--perhaps it's a good idea for
>>> some other reason--but I don't
>>> think that rolling the keys over at high rates provides any
>>> significant security benefit, no matter
>>> where in the hierarchy you're doing it.
>>
>> Really this is an DNSOP issues, more specifically an issue for RFC4641bis.
>>
>> [I've added dnsop, please remove namedroppers when replying to this note]
>>
>> RFC4641 argues for frequent ZSK rollovers, the argument therein is
>> based on operational arguments that are (implicitly) based on operator
>> acces to private keys and/or the timeline in which changes in which
>> the (zone) operator may need to be replaced.
>
> I skimmed through 4641 to try and refresh my memory, but couldn't find the
> discussion on ZSK rollover frequency. No doubt this is my deficiency.
>
> From my perspective the operational argument is that procedures which are
> rarely exercised may not be exercised well when they are needed (a backup
> that is not regularly tested cannot really be relied upon; a protect path
> that is never used might not work when it is needed, etc).
>
> Frequent key rollover has the operational benefit of when you need to do an
> emergency roll you know the procedures work.

I see this argument, but I'm not sure I buy it.

Because DNSSEC has no concept of revocation list or online revocation,
keys remain valid until they expire, so lifetimes must be short (I don't
think 3 months is crazy here, though I would have been tempted to go
even shorter). This means you will be regularly signing new ZSKs, even
if the new ZSKs are the same as the old ZSKs. This will exercise most
of the relevant code and some of the procedures.

Similarly, because there is no way to do immediate key revocation,
you're stuck with having the compromised key valid for weeks or months,
so it's not like you don't have time to figure out the rest of the procedures
if you don't have them exactly right.


> From this perspective we might roll a ZSK more frequently than a KSK because
> the ZSK needs to be stored on-line to facilitate re-signing when the zone
> changes. With the KSK we have the option of keeping it off-line, and
> arguably the risk of compromise is consequently lower. Regular testing of
> the machinery is still important, however.

Again, this seems like an argument for the ZSK/KSK split, which I'm not really
arguing against (I haven't developed an opinion). My argument is purely
against generating a new ZSK every time you sign it with the KSK. I don't
think that provides much security benefit and certainly does have plenty of
room for error.

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