Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-zone-digest-12: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

Hi Duane,

On Wed, Oct 07, 2020 at 07:59:54PM +, Wessels, Duane wrote:
> Hi Benjamin, thanks for the extensive review and comments.  Responses are
> inline.  As you've noted some of this overlaps with Roman's comments as
> well.
> 
> 
> > On Oct 6, 2020, at 10:41 AM, Benjamin Kaduk via Datatracker 
> >  wrote:
> > 
> > --
> > DISCUSS:
> > --
> > 
> > Inclusion of an "implementation requirement" column in the IANA
> > registries implies a need for a defined procedure to make changes to
> > existing registrations.  With only a "specification required" procedure,
> > it seems there would need to be a "change controller" column as well.
> > Furthermore, is it expected that anyone with any specification could
> > set, e.g., an implementation requirement of "MUST"?  It seems like this
> > attribute might be better left for the RFCs defining the protocol, to be
> > modified by an updating RFC...
> 
> To be honest, I feel like the "implementation requirement" column is a
> bit of a can-of-worms.  I have a hard time finding other IANA registries
> that use it.  Would it be better to omit this from the registry?

In my opinion, yes!

There's a pretty strong argument that changing implementation requirements
is placing requirements on implementations with a similar level of
authority to actual protocol changes, and thus that just having the
implementation requirements in an RFC that gets updated as needed makes
more sense.  See, e.g., RFC 8247 (which obsoletes 4307)

> If not, would it be sufficient to say something like "all specifications
> requesting an allocation must have the implementation requirement set to
> MAY unless being published on the standards track"?
> 
> 
> 
> > 
> > If we are to retain the Implementation Status appendix in the final RFC,
> > the boilerplate will need some changes, and I think those changes should
> > get review prior to AUTH48.  For example, "at the time of posting of
> > this Internet-Draft" will make no sense in an RFC, and the relationship
> > to RFC 7942 is not quite as clear given that we diverge from its
> > recommendations.  "[A]ssist the IETF in its decision process" does not
> > seem to apply after the IETF has made its decision, though the
> > disclaimer about endorsement seems highly important to retain.
> 
> 
> Is this okay?
> 
>   RFC Editor: Please retain this section upon publication.
> 
>   This section records the status of known implementations of the
>   protocol defined by this specification, and is inspired by the

We probably do want to keep something about "time of publication" (just not
talk about Internet-Drafts).

>   concepts described in RFC7942.
> 
>   Please note that the listing of any individual implementation here
>   does not imply endorsement by the IETF.  Furthermore, no effort has
>   been spent to verify the information presented here that was supplied
>   by IETF contributors.  This is not intended as, and must not be
>   construed to be, a catalog of available implementations or their
>   features.  Readers are advised to note that other implementations may
>   exist.

But it seems otherwise unobjectionable to me.  (Hopefully we can get some
voices from the WG to chime in as well.)
There is perhaps some question about whether it should get another IETF LC,
but Barry and probably the rest of the IESG should be part of that
conversation.


> 
> > 
> > This seems to be related to Roman's Discuss point, but the document
> > seems to be inconsistent as to the primary purpose of the mechanism --
> > Section 1.1 says that it is to verify "authenticity" of a stand-alone
> > zone, whereas the Introduction implies that "integrity" is primary (with
> > authenticity as an add-on "when used in combination with DNSSEC), and
> > the Abstract refers to "accuracy and completeness".  In particular, it
> > is easy to read references to "integrity" (and, indeed, the Abstract
> > itself) as referring to something akin to a transport checksum instead
> > of a cryptographic message integrity code.  I think the document needs
> > to be much more clear, and consistent, about what properties it aims to
> > provide.  (I do not believe that the "authenticity" property can be
> > provided without DNSSEC, and Roman covers the cryptographic integrity
> > case in his ballot position.)
> 
> Thanks for pointing this out. Here's some diff showing changes to address
> this:
> 
> -that provides a cryptographic message digest over DNS zone data.
> +that provides a cryptographic message digest over DNS zone data at 
> rest.
> 
> -can verify the zone contents for accuracy and completeness.
> +can verify the zone contents for integrity and, when signed with 
> DNSSEC, origin authenticity.
> 
> -Currently there is no standard way to verify the integrity and 
> authenticity
> +Currently there is no 

Re: [DNSOP] SVCB and the specialness of _

[Tommy Pauly]

> On Oct 7, 2020, at 12:26 PM, Ben Schwartz 
>  wrote:
> 
> 
> 
> On Wed, Oct 7, 2020 at 3:20 PM Brian Dickson  > wrote:
> 
> 
> On Tue, Oct 6, 2020 at 6:10 PM Ben Schwartz  > wrote:
> On Tue, Oct 6, 2020 at 8:51 PM Brian Dickson  > wrote:
> 
> Other than the syntactic brevity, is there any functional difference to the 
> client between a TargetName of "." versus a TargetName of "$HOSTNAME" in the 
> description above?
> 
> Currently, "." means $HOSTNAME for the HTTPS record (when no prefixes are 
> applied).  With the proposed change, "." would always mean $HOSTNAME when a 
> ServiceMode record is returned directly for the original query.  However, if 
> the ServiceMode record is reached via a CNAME or AliasMode record, then "." 
> does not correspond to (the original) $HOSTNAME.
> 
> This presents two significant problems.
> 
> First, this (what you write above) means that "." will not be guaranteed 100% 
> of the time to result in the "correct" value, if I understand correctly.
> 
> I'm not sure what you mean by "correct".  With or without this proposal, the 
> expanded name for "." is well-defined.
> 
> Second, the use of "." by whoever creates the ServiceMode record may not be 
> aware of how it is reached (e.g. by CNAME or AliasMode records not under 
> their control or that they are aware of or which may be added later).
> 
> The expanded name does not depend on how the record was reached.  I'm merely 
> trying to point out that, after an alias has been followed, any information 
> about "$HOSTNAME" has been lost.

+1. The “.” is very clear in meaning, since it is only referring to a name that 
is in the record itself. It’s not about where the chain comes from. This 
proposal is only about cleaning up a case where that name in the record has 
less helpful “_foo" prefixes. We absolutely should keep the “.” meaning as-is 
for all other cases.

Tommy

> 
> ...
> As you note below, "@" is available, and while perhaps not as elegant, is 
> handled in the authority server's loading of zone files, and never results in 
> dynamic processing or additional handling requirements. I.e. it achieves 
> maybe 90% of the intended "happy" result, but does so with 100% 
> interoperability after the zone itself is constructed and loaded.
> 
> My impression is that "@" is always, or nearly always, a zone apex.  I expect 
> that the majority of HTTPS and SVCB records will not be for the zone apex.  
> Setting a ServiceMode TargetName of @ would instruct those records to use the 
> A/ records for the apex name.  This strikes me as an unlikely 
> configuration.
> 
>  
> 
> First, is the use of the standard zone file construct of "@", which only 
> exists within the zone master file, and gets substituted on import with 
> whatever $ORIGIN is.
> 
> Yes, the syntax already supports "@" and relative names when writing out a 
> TargetName in the zone file.  This is useful, but I don't think it has the 
> effect of guiding users toward a good configuration.
> 
> Brian 
> ___
> 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] Roman Danyliw's Discuss on draft-ietf-dnsop-dns-zone-digest-12: (with DISCUSS and COMMENT)

[Roman Danyliw]

Hi Duane,

> -Original Message-
> From: iesg  On Behalf Of Wessels, Duane
> Sent: Wednesday, October 7, 2020 3:55 PM
> To: Roman Danyliw 
> Cc: draft-ietf-dnsop-dns-zone-dig...@ietf.org; Tim Wicinski
> ; dnsop@ietf.org; dnsop-cha...@ietf.org; The IESG
> 
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-dnsop-dns-zone-digest-12:
> (with DISCUSS and COMMENT)
> 
> Hi Roman, thanks for the detailed review and comments.  My responses are
> inline.
> 
> 
> > On Oct 5, 2020, at 7:47 PM, Roman Danyliw via Datatracker
>  wrote:
> >
> > Roman Danyliw has entered the following ballot position for
> > draft-ietf-dnsop-dns-zone-digest-12: Discuss
> >
> > 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://secure-
> web.cisco.com/1PmgI5C3eeSLOyMacI0tFtTZ2Xp1ZVDLlBYygPBOj1Q0bVtLkzLw
> mmN5ldjjcypZn5nnasJsm9E5GpsNMDvWdtGaM2kaFHhp7jZlEgufkzdln1LmRT84
> DKcbrePOUdtgU2M4UwQqhJ69IT0KBrKkQNN1OLFRMyYwhXs48zGHMkPxAOQ
> 9L2Je4TLpCoWGXIqZExBn5ErrQBYfVsEcz2xB1L-
> eKHO_l_zDzfiAHtMP8zHJQ_7GCF6YPn4OTvYHtKq1TL85oSNMxkc-
> a9TwIaBuzcEx2aRPzSqAPypDs7bIbFPs/https%3A%2F%2Fwww.ietf.org%2Fiesg%
> 2Fstatement%2Fdiscuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://secure-
> web.cisco.com/1In2W1aOUrhepme0YYTCWi_KVrjzwPz6gRHK3wqiBh8JhXsVPR-
> caNTg-
> liKbKCksx5Y35akHQwb5BB41XUadJT3by_ZmHTxwdiSU3QpC4eNTBAE42Pw2m
> ywlUcsCxUsDMgrwL3ph93cdoIxfnYKlbiF9GQp0v74iO_IcfqqkdmjHCiFqNSIrWIJsj
> sae_FUkueb3LzXcJ3Ine0GDo664s3xd60kYguQsCr17CZmEHlHTLEzHiGGXW8IrEm
> 4JcgBjaAU2ABRPZ-
> bfBv0LsmZR0Q/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-
> dnsop-dns-zone-digest%2F
> >
> >
> >
> > --
> > DISCUSS:
> > --
> >
> > Section 6.1.   My read of the text is that the security properties are 
> > intended
> > to be independent of the transport protocol.  With that assumption and the
> > validation procedures in Section 4, I need help understanding the security
> > properties the client can rely on in the absence of DNSSEC.  Consider the
> > following scenarios and attacker types; and the assurances a client could 
> > have
> > when retrieving the zone file from the server:
> >
> > With an on-path attacker (and trusted server hosting the zone file)
> >
> > ** No DNSSEC; No Secure transport = integrity: NO; authenticity = NO
> >
> > ** No DNSSEC; Secure transport = integrity: YES (from the on-path attacker);
> > authenticity = NO
> >
> > ** DNSSEC = integrity: YES; authenticity = YES
> >
> > With a rogue server hosting the zone file (but is not the operator of the 
> > zone)
> >
> > ** No DNSSEC; No Secure transport = integrity: NO; authenticity = NO
> >
> > ** No DNSSEC/Secure transport = integrity: NO; authenticity = NO
> >
> > ** DNSSEC = integrity: YES; authenticity = YES
> >
> > The text states that:
> >
> > The zone digest allows the recipient of a zone to verify its
> >  integrity.  In conjunction with DNSSEC, the recipient can
> >  authenticate that it is as published by the zone originator.
> >
> > Can the means to realize integrity without DNSSEC unless there is a reliance
> on
> > transport security of some form be clarified.  Minimally, it seems like this
> > section needs cautionary text (likely with normative language) to the 
> > effect of
> > “ZONEMD information from zone files lacking DNSSEC support or that were
> shared
> > over ‘unsecure transport’ cannot be relied upon for cryptographic integrity
> > assurance.”
> 
> You are correct that we intend the security properties to be independent of
> any transport protocol.   I'm reluctant to suggest in this document that
> a recipient could rely on ZONEMD for integrity because it came over a secure
> transport.  Although that might be true, I have to think that the secure
> transport itself provides the integrity assurance, and not the ZONEMD record.

In that case (where no assumptions are made about the transport), it seems that 
only these scenarios from the list above apply:

 With an on-path attacker (and trusted server hosting the zone file)

** No DNSSEC  = integrity: NO; authenticity = NO
** DNSSEC = integrity: YES; authenticity = YES

With a rogue server hosting the zone file (but is not the operator of the zone)

** No DNSSEC = integrity: NO; authenticity = NO
** DNSSEC = integrity: YES; authenticity = YES

Or more succinctly, without DNSSEC, the two stated security properties aren't 
provided.  

I'm not sure of what the best way is to resolve this mismatch based on the use 
cases.  I can see (at least) two paths to resolution:

(1) Specify that ZONEMD records MUST only be used with DNSSEC -- this will 
preserve the authenticity and integrity 

Re: [DNSOP] Éric Vyncke's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)

[Wessels, Duane]

> On Oct 7, 2020, at 2:47 AM, Éric Vyncke via Datatracker  
> wrote:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-dnsop-dns-zone-digest-12: No Objection
> 
> --
> COMMENT:
> --
> 
> Thank you for the work put into this document. I really like the idea of
> protecting the zone integrity even at rest.
> 
> Please find below one non-blocking COMMENT points and one nit. I would really
> appreciate a reply for my comment about section 1.2.
> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> == COMMENTS ==
> -- Section 1.2 --
> Why is draft-ietf-dprive-xfr-over-tls not mentioned in this section as an
> alternative for data on the move?

Just an oversight.  The document does (did) mention "a future version of 
DNS-over-TLS"
which I think was meant as a reference to draft-ietf-dprive-xfr-over-tls when 
that was
just getting started.  Ben pointed this out as well and I suggest changing the 
text to this:

   The Transport Layer Security protocol suite also provides channel
   security.  The DPRIVE working group is in the process of specifying
   DNS Zone Transfer-over-TLS [I-D.ietf-dprive-xfr-over-tls].


> 
> == NITS ==
> -- Section 1.4.3 --
> Suggest to add "(RPZ)" after the first use of the expansion.
> 


Done.

DW




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

Re: [DNSOP] Erik Kline's Yes on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)

[Wessels, Duane]

> On Oct 6, 2020, at 3:26 PM, Erik Kline via Datatracker  
> wrote:
> 
> Erik Kline has entered the following ballot position for
> draft-ietf-dnsop-dns-zone-digest-12: Yes
> 
> 
> --
> COMMENT:
> --
> 
> [[ nits ]]
> 
> [ section 1.2 ]
> 
> * "Whereas DNSSEC is primarily protects" ->
>  "Whereas DNSSEC primarily protects"
> 
> [ section 6.2 ]
> 
> * "DNSSESC" -> "DNSSEC"
> 

Thanks, these have been fixed!

DW



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

Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-zone-digest-12: (with DISCUSS and COMMENT)

[Wessels, Duane]

Hi Benjamin, thanks for the extensive review and comments.  Responses are
inline.  As you've noted some of this overlaps with Roman's comments as
well.


> On Oct 6, 2020, at 10:41 AM, Benjamin Kaduk via Datatracker 
>  wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-dnsop-dns-zone-digest-12: Discuss
> 
> 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://secure-web.cisco.com/1BhOfb00VlP-8nUKujrBf7Xdn619jDI_JYiZUqXkRxJrGzti31tg1_lvl6zhDB3k4IUREe6b8Nw3PlWFa0tN3hSEXudysqKd2OxwaaOs0SBHZvEEKVIPc1f-JzrxCn2NAZvke4gWp4K8Nu32aoVdLQKo7SS5PVgHXC9ilgSSqgG_on7pnLuTvHDjYBitnA0fUBIgsOzbVX0tkBue9G06o0C0r80D6EsaK6UoD5cuNz9mUjPZ56TJxzip1UXrfJZ28kGt4MPwe8JIqa4VLKcwz8GqlffyQuXEquiSqih46whY/https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://secure-web.cisco.com/1xe5afi0q1U9T8XBGtR5t0vEYlrnzaadCkXqE09yMZj4z0tASslenLfkLmcnAJ7Mh9GZqXJwg_vPKpS0X4wUosrcy_CVVGV42vwFrwqpNkm-3ukWQWroGS3v0hj84_EQOKGAHQG7X87FSo9kCMC4VX43uHk4s9tUi1QT-f1gd4kngZnItz73If8TdNzt_dLWdlpOjGkd1YSMOMD9ZAitEfs_X25RrGQdC2vFNdrGXdbChufVU8h4Ex2uZCVCakgPLhbPUKXVdXDkZ5JCPHireHA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dnsop-dns-zone-digest%2F
> 
> 
> 
> --
> DISCUSS:
> --
> 
> Inclusion of an "implementation requirement" column in the IANA
> registries implies a need for a defined procedure to make changes to
> existing registrations.  With only a "specification required" procedure,
> it seems there would need to be a "change controller" column as well.
> Furthermore, is it expected that anyone with any specification could
> set, e.g., an implementation requirement of "MUST"?  It seems like this
> attribute might be better left for the RFCs defining the protocol, to be
> modified by an updating RFC...

To be honest, I feel like the "implementation requirement" column is a
bit of a can-of-worms.  I have a hard time finding other IANA registries
that use it.  Would it be better to omit this from the registry?

If not, would it be sufficient to say something like "all specifications
requesting an allocation must have the implementation requirement set to
MAY unless being published on the standards track"?



> 
> If we are to retain the Implementation Status appendix in the final RFC,
> the boilerplate will need some changes, and I think those changes should
> get review prior to AUTH48.  For example, "at the time of posting of
> this Internet-Draft" will make no sense in an RFC, and the relationship
> to RFC 7942 is not quite as clear given that we diverge from its
> recommendations.  "[A]ssist the IETF in its decision process" does not
> seem to apply after the IETF has made its decision, though the
> disclaimer about endorsement seems highly important to retain.


Is this okay?

  RFC Editor: Please retain this section upon publication.

  This section records the status of known implementations of the
  protocol defined by this specification, and is inspired by the
  concepts described in RFC7942.

  Please note that the listing of any individual implementation here
  does not imply endorsement by the IETF.  Furthermore, no effort has
  been spent to verify the information presented here that was supplied
  by IETF contributors.  This is not intended as, and must not be
  construed to be, a catalog of available implementations or their
  features.  Readers are advised to note that other implementations may
  exist.


> 
> This seems to be related to Roman's Discuss point, but the document
> seems to be inconsistent as to the primary purpose of the mechanism --
> Section 1.1 says that it is to verify "authenticity" of a stand-alone
> zone, whereas the Introduction implies that "integrity" is primary (with
> authenticity as an add-on "when used in combination with DNSSEC), and
> the Abstract refers to "accuracy and completeness".  In particular, it
> is easy to read references to "integrity" (and, indeed, the Abstract
> itself) as referring to something akin to a transport checksum instead
> of a cryptographic message integrity code.  I think the document needs
> to be much more clear, and consistent, about what properties it aims to
> provide.  (I do not believe that the "authenticity" property can be
> provided without DNSSEC, and Roman covers the cryptographic integrity
> case in his ballot position.)

Thanks for pointing this out. Here's some diff showing changes to address
this:

-that provides a cryptographic message digest over DNS zone data.
+that provides a cryptographic message digest over DNS zone data at 
rest.

-can 

Re: [DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-dns-zone-digest-12: (with DISCUSS and COMMENT)

[Wessels, Duane]

Hi Roman, thanks for the detailed review and comments.  My responses are inline.


> On Oct 5, 2020, at 7:47 PM, Roman Danyliw via Datatracker  
> wrote:
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-dnsop-dns-zone-digest-12: Discuss
> 
> 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://secure-web.cisco.com/1PmgI5C3eeSLOyMacI0tFtTZ2Xp1ZVDLlBYygPBOj1Q0bVtLkzLwmmN5ldjjcypZn5nnasJsm9E5GpsNMDvWdtGaM2kaFHhp7jZlEgufkzdln1LmRT84DKcbrePOUdtgU2M4UwQqhJ69IT0KBrKkQNN1OLFRMyYwhXs48zGHMkPxAOQ9L2Je4TLpCoWGXIqZExBn5ErrQBYfVsEcz2xB1L-eKHO_l_zDzfiAHtMP8zHJQ_7GCF6YPn4OTvYHtKq1TL85oSNMxkc-a9TwIaBuzcEx2aRPzSqAPypDs7bIbFPs/https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://secure-web.cisco.com/1In2W1aOUrhepme0YYTCWi_KVrjzwPz6gRHK3wqiBh8JhXsVPR-caNTg-liKbKCksx5Y35akHQwb5BB41XUadJT3by_ZmHTxwdiSU3QpC4eNTBAE42Pw2mywlUcsCxUsDMgrwL3ph93cdoIxfnYKlbiF9GQp0v74iO_IcfqqkdmjHCiFqNSIrWIJsjsae_FUkueb3LzXcJ3Ine0GDo664s3xd60kYguQsCr17CZmEHlHTLEzHiGGXW8IrEm4JcgBjaAU2ABRPZ-bfBv0LsmZR0Q/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dnsop-dns-zone-digest%2F
> 
> 
> 
> --
> DISCUSS:
> --
> 
> Section 6.1.   My read of the text is that the security properties are 
> intended
> to be independent of the transport protocol.  With that assumption and the
> validation procedures in Section 4, I need help understanding the security
> properties the client can rely on in the absence of DNSSEC.  Consider the
> following scenarios and attacker types; and the assurances a client could have
> when retrieving the zone file from the server:
> 
> With an on-path attacker (and trusted server hosting the zone file)
> 
> ** No DNSSEC; No Secure transport = integrity: NO; authenticity = NO
> 
> ** No DNSSEC; Secure transport = integrity: YES (from the on-path attacker);
> authenticity = NO
> 
> ** DNSSEC = integrity: YES; authenticity = YES
> 
> With a rogue server hosting the zone file (but is not the operator of the 
> zone)
> 
> ** No DNSSEC; No Secure transport = integrity: NO; authenticity = NO
> 
> ** No DNSSEC/Secure transport = integrity: NO; authenticity = NO
> 
> ** DNSSEC = integrity: YES; authenticity = YES
> 
> The text states that:
> 
> The zone digest allows the recipient of a zone to verify its
>  integrity.  In conjunction with DNSSEC, the recipient can
>  authenticate that it is as published by the zone originator.
> 
> Can the means to realize integrity without DNSSEC unless there is a reliance 
> on
> transport security of some form be clarified.  Minimally, it seems like this
> section needs cautionary text (likely with normative language) to the effect 
> of
> “ZONEMD information from zone files lacking DNSSEC support or that were shared
> over ‘unsecure transport’ cannot be relied upon for cryptographic integrity
> assurance.”

You are correct that we intend the security properties to be independent of
any transport protocol.   I'm reluctant to suggest in this document that
a recipient could rely on ZONEMD for integrity because it came over a secure
transport.  Although that might be true, I have to think that the secure
transport itself provides the integrity assurance, and not the ZONEMD record.


> 
> 
> --
> COMMENT:
> --
> 
> Thank you for addressing the SECDIR review (and thank you to Donald Eastlake
> for performing the review).
> 
> ** Section 1.  s/allowing verification of the zone/allowing verification of 
> the
> integrity of the zone/

The sentence preceding this one talks about verifying both integrity and
authenticity (given DNSSEC).  I'm not sure why you want to focus on just
integrity here in this sentence?


> 
> ** Section 1.2.  In the discussion about alternatives, it seems like the two
> competing designs are “channel security” vs. “data security”?  Is the latter
> the equivalent to “object security”, a term with which I’m more familiar?  
> That
> is, the data itself carries a set of security properties independent of the
> channel or session exchanging it.

Yes, data security means the same thing as object security.


> 
> ** Section 1.3.  Clarifying language.
> OLD
> As specified herein, the digest is re-calculated over the
>  entire zone content each time
> 
> NEW
> As specified herein, the digest is re-calculated over the
>  entire zone content each time the zone is updated.

Okay.


> 
> ** Section 1.3.  Editorial.  The sentence “It is, however, extensible so 
> future
> schemes to 

Re: [DNSOP] SVCB and the specialness of _

[Brian Dickson]

On Tue, Oct 6, 2020 at 6:10 PM Ben Schwartz  wrote:

> On Tue, Oct 6, 2020 at 8:51 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>> Other than the syntactic brevity, is there any functional difference to
>> the client between a TargetName of "." versus a TargetName of "$HOSTNAME"
>> in the description above?
>>
>
> Currently, "." means $HOSTNAME for the HTTPS record (when no prefixes are
> applied).  With the proposed change, "." would always mean $HOSTNAME when a
> ServiceMode record is returned directly for the original query.  However,
> if the ServiceMode record is reached via a CNAME or AliasMode record, then
> "." does not correspond to (the original) $HOSTNAME.
>

This presents two significant problems.

First, this (what you write above) means that "." will not be guaranteed
100% of the time to result in the "correct" value, if I understand
correctly.

Second, the use of "." by whoever creates the ServiceMode record may not be
aware of how it is reached (e.g. by CNAME or AliasMode records not under
their control or that they are aware of or which may be added later).

Unless I misunderstand, I think the lack of 100% correctness in all
scenarios means this will cause difficult-to-find-and-fix operational
problems.

For this reason, I strongly suggest removing the "." and its special
handling.

As you note below, "@" is available, and while perhaps not as elegant, is
handled in the authority server's loading of zone files, and never results
in dynamic processing or additional handling requirements. I.e. it achieves
maybe 90% of the intended "happy" result, but does so with 100%
interoperability after the zone itself is constructed and loaded.


>
> First, is the use of the standard zone file construct of "@", which only
>> exists within the zone master file, and gets substituted on import with
>> whatever $ORIGIN is.
>>
>
> Yes, the syntax already supports "@" and relative names when writing out a
> TargetName in the zone file.  This is useful, but I don't think it has the
> effect of guiding users toward a good configuration.
>

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

Re: [DNSOP] [Gen-art] Genart last call review of draft-ietf-dnsop-dns-zone-digest-09

[Alissa Cooper]

Elwyn, thanks for your review. Duane, thanks for your response. I entered a No 
Objection ballot.

Alissa


> On Sep 14, 2020, at 6:43 PM, Wessels, Duane 
>  wrote:
> 
> I'm not sure why received messages in this thread are being truncated.  The 
> archive 
> has my full response here:
> 
> https://mailarchive.ietf.org/arch/msg/gen-art/MVl2P81bCi6d5l1QhuNluJZB52g/
> 
> DW
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

Re: [DNSOP] SVCB and the specialness of _

[Tommy Pauly]

This change seems reasonable, and makes “.” still more useful for the generic 
SVCB case.

Thanks,
Tommy

> On Oct 6, 2020, at 4:51 PM, Ben Schwartz  
> wrote:
> 
> Hi DNSOP,
> 
> There was recently an interesting proposal [1] for a change to the SVCB draft 
> that seems to merit input from the working group.
> 
> Background:
> When using SVCB, clients append an underscore prefix ("Attrleaf") to the 
> name, containing the "scheme".  When there is an actual URI involved this 
> will literally be the URI scheme, e.g. _ftp.ftp.example.net 
> .  Schemes can prepend additional 
> underscore-prefix labels to encode scheme-specific service identifiers; the 
> only anticipated use for this is a port number (e.g. 
> _8080._https.www.example.com ).
> 
> SVCB also contains a small optimization: In ServiceMode, if the TargetName is 
> ".", this means "use the address records for the owner name".  This reduces 
> packet size (since name compression is not possible in new RR types), but 
> more importantly, it makes zone file editing easier and guides zone owners 
> toward the "happy path", where there is no latency penalty because the 
> resolver has already requested the corresponding address records.
> 
> This construction works well for HTTPS on port 443, and for any lookup 
> following an AliasMode record, because in those cases the SVCB/HTTPS, A, and 
>  queries all share the same QNAME.  However, it does not work when the 
> initial query has underscore labels and returns a ServiceMode record, because 
> the ServiceMode record's name is not the hostname (due to the underscore 
> labels).
> 
> Proposal:
> The proposal would change the meaning of "." from "Use the SVCB record's 
> owner name" to "Use the SVCB record's owner name *minus any leading 
> underscore labels*".
> 
> Pro: TargetName = "." would now coincide with the "happy path" in all 
> ordinary cases.
> * Simpler guidance to zone owners (always prefer ".")
> * Clearer design rationale ("." is where the address queries already went)
> * Shorter RDATA in the "happy path" case (for some non-HTTPS uses)
> 
> Con:
> * Servers (recursive and authoritative) that perform Additional Section 
> processing would have to implement this underscore-label stripping procedure. 
>  This would be a rare violation of DNS's usual abstraction barrier (servers 
> don't normally discriminate based on the format of labels).
> * There could be a change of operational control (e.g. zone cut or CNAME) 
> between _port._scheme.$HOSTNAME and $HOSTNAME, in which case the ServiceMode 
> record might actually prefer to use address records at its own name, despite 
> the latency cost.
> * This gets very tricky if an AliasMode or CNAME target contains underscore 
> prefixes.  It may be impossible to stay on the "happy path" in all these 
> cases.
> 
> [1] https://github.com/MikeBishop/dns-alt-svc/issues/252 
> 
> ___
> 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] Éric Vyncke's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)

[Éric Vyncke via Datatracker]

Éric Vyncke has entered the following ballot position for
draft-ietf-dnsop-dns-zone-digest-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-dns-zone-digest/



--
COMMENT:
--

Thank you for the work put into this document. I really like the idea of
protecting the zone integrity even at rest.

Please find below one non-blocking COMMENT points and one nit. I would really
appreciate a reply for my comment about section 1.2.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==
-- Section 1.2 --
Why is draft-ietf-dprive-xfr-over-tls not mentioned in this section as an
alternative for data on the move?

== NITS ==
-- Section 1.4.3 --
Suggest to add "(RPZ)" after the first use of the expansion.



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