[DNSOP] Possible missed messages on this list
Possible missed messages on this list Dear list participants - An upgrade to the IETF's custom mail processing software today resulted in some delivery failures for *some* messages to *some* recipients on this list, over the past 3 hours. We invite you to check the mail archives for this list, at: https://mailarchive.ietf.org/arch/search/?email_list=dnsop to ensure that you have received all the relevant messages for this list today. We apologize for the inconvenience. Glen -- Glen Barney IT Director AMS (IETF Secretariat) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnssd] Working Group Last Call - draft-ietf-dnsop-session-signal
On Feb 14, 2018, at 6:06 PM, Jan Komissar (jkomissa) wrote: > Currently, there are only plans for DPN, and that would force every > connection to be TLS. However, if a future protocol “Z-over-DSO” does not > require TLS, it is possible that a client would create a TCP connection for Z > and later would want to send DPN operation to the same server. Note that the > DSO client may represent a single computer, while the Z and DPN requests > represent applications on that computer that implicitly depend on those two > protocols. I guess a new connection could be created, but it would be better > if not necessary. Hm, is that really true? What is the scenario that you envision here? Like, when would this actually happen? What's the client that's making the connection? How is it that it is the same client that's doing DPN? If it is configured to support TLS, why isn't it defaulting to that? > The interop issue is related to section 4.1 that says that any session based > protocol is suitable for DSO. If you make a server that only supports DSO > over TCP and I make a client that only supports DSO over QUIC, they are both > compliant with the draft, but they cannot communicate with each other. To > avoid this, I suggest that this draft only supports TLS (and possibly TCP), > and supporting DSO on any other underlying protocol would require a new > document. I think I've heard other suggestions that we should enumerate which protocols are supported explicitly, but I don't think there's a requirement to support DSO over anything. We're just describing a new DNS message type that can be used with any connection-oriented protocol. You didn't answer my third question: > Also, do you think that DNS-over-TCP should be formally deprecated? If so, > perhaps that's the right way to address this. If not, can you say why DSO > is special and requires TLS, when DNS-over-TCP does not? Is is that you want to make DSO-over-TLS MTI and DSO-over-TCP optional? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnssd] Working Group Last Call - draft-ietf-dnsop-session-signal
On 14/02/2018 23:06, Jan Komissar (jkomissa) wrote: > Currently, there are only plans for DPN, and that would force every > connection to be TLS. DPN is the only current _extension_ to DSO. DSO is also supposed to stand in its own right as a way to improve the management of long-lived connections. This does not mandate TLS. kind regards, Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnssd] Working Group Last Call - draft-ietf-dnsop-session-signal
Hi Ted, I’ll try to clarify: Currently, there are only plans for DPN, and that would force every connection to be TLS. However, if a future protocol “Z-over-DSO” does not require TLS, it is possible that a client would create a TCP connection for Z and later would want to send DPN operation to the same server. Note that the DSO client may represent a single computer, while the Z and DPN requests represent applications on that computer that implicitly depend on those two protocols. I guess a new connection could be created, but it would be better if not necessary. The interop issue is related to section 4.1 that says that any session based protocol is suitable for DSO. If you make a server that only supports DSO over TCP and I make a client that only supports DSO over QUIC, they are both compliant with the draft, but they cannot communicate with each other. To avoid this, I suggest that this draft only supports TLS (and possibly TCP), and supporting DSO on any other underlying protocol would require a new document. Better? Thanks, Jan. From: Ted Lemon Date: Wednesday, February 14, 2018 at 5:22 PM To: "Jan Komissar (jkomissa)" Cc: Paul Hoffman , dnsop , "dn...@ietf.org" , "d...@ietf.org" Subject: Re: [dnssd] [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal On Feb 14, 2018, at 5:12 PM, Jan Komissar (jkomissa) mailto:jkomi...@cisco.com>> wrote: 1: I think that it would be better to require TLS for all DSO connections. This document (DSO) specifies that it should use TCP or TLS for connections, but the DNS Push Notification (DPN) draft requires TLS. This would complicate matters if a standard TCP connection was opened for one purpose and later a DPN operation over the same connection was attempted. Also, it improves security for all DSO operations. Jan, I'm having trouble following your reasoning here. The client that makes the connection presumably knows whether or not it's going to do DPN. Why would there be any confusion? DNS-over-TCP and DNS-over-TLS are standards. It's hard to see where the interop issue would be. Can you expand on that? Also, do you think that DNS-over-TCP should be formally deprecated? If so, perhaps that's the right way to address this. If not, can you say why DSO is special and requires TLS, when DNS-over-TCP does not? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnssd] Working Group Last Call - draft-ietf-dnsop-session-signal
On Feb 14, 2018, at 5:12 PM, Jan Komissar (jkomissa) wrote: > 1: I think that it would be better to require TLS for all DSO connections. > This document (DSO) specifies that it should use TCP or TLS for connections, > but the DNS Push Notification (DPN) draft requires TLS. This would complicate > matters if a standard TCP connection was opened for one purpose and later a > DPN operation over the same connection was attempted. Also, it improves > security for all DSO operations. Jan, I'm having trouble following your reasoning here. The client that makes the connection presumably knows whether or not it's going to do DPN. Why would there be any confusion? DNS-over-TCP and DNS-over-TLS are standards. It's hard to see where the interop issue would be. Can you expand on that? Also, do you think that DNS-over-TCP should be formally deprecated? If so, perhaps that's the right way to address this. If not, can you say why DSO is special and requires TLS, when DNS-over-TCP does not? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal
Two items related to this: 1: I think that it would be better to require TLS for all DSO connections. This document (DSO) specifies that it should use TCP or TLS for connections, but the DNS Push Notification (DPN) draft requires TLS. This would complicate matters if a standard TCP connection was opened for one purpose and later a DPN operation over the same connection was attempted. Also, it improves security for all DSO operations. 2: I also believe this document should only support DSO over TLS, not session based protocols in general. If there is a need/desire for doing DSO over other protocols, a new RFC allowing each protocol would be required. This requirement will ensure that all implementations of this draft would interoperate. (If DSO-over-X and DSO-over-Y both are compliant with this document, they are not likely to interoperate even if both X and Y are session based, which would defeat the purpose of a standard.) Regards, Jan. On 2/2/18, 4:58 PM, "DNSOP on behalf of Paul Hoffman" wrote: The current draft is hand-wavy when it comes to which transports DSO can run on. Section 2 says "such as": The term "connection" means a bidirectional byte stream of reliable, in-order messages, such as provided by using DNS over TCP [RFC1035][RFC7766] or DNS over TLS [RFC7858]. Section 4.1 says "are suitable": Standard DNS over TCP [RFC1035][RFC7766], and DNS over TLS [RFC7858] are suitable protocols. The document should explicitly list which protocols are currently acceptable, and say that the list can change in the future based on standards-track documents. Proposed wording for both of these above are: Section 2: The term "connection" means a bidirectional byte stream of reliable, in-order messages. Section 4.1 says "are suitable": DSO MUST be run as standard DNS over TCP [RFC1035][RFC7766] or DNS over TLS [RFC7858]. This list might expand in the future, such an expansion MUST be in standards-track RFCs. Having developers know exactly which protocols can be used is important so that they do not use protocols that they accidentally think are reliable and in-order. For example, the DOH WG is working on a protocol that might initially seem attractive, but it does *not* qualify for DSO. --Paul Hoffman ___ 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] Updated KSK Sentinel document
At Mon, 12 Feb 2018 15:28:50 -0500,
Warren Kumari wrote:
> Anyway, we've finally posted an updated version -
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/
I've read draft-ietf-dnsop-kskroll-sentinel-01 (this is my first
careful read of this draft) and found it generally well-written.
I have some comments on 01. These are basically editorial.
- General
I think it's worth pointing out that SERVFAIL can be returned for
various other reasons and the detection mechanism relying on it
isn't reliable. This is probably okay given the purpose of this
detection, but I think it's better to note it explicitly.
- Section 1.1
Address Record: Throughout this document we use the term Address
Record (AR) to mean an A or record. [...]
I actually didn't find this term other than here and Section 9
(change log).
- Section 1.1 and throughout the draft
records and the IPv6 documentation prefix (2001:DB8::/32) as
I'd suggest using lower-case letters to show IPv6 addresses and
prefixes, following the recommendation of RFC5952. It's not a big
deal but it would be better if we can be more consistent on the
choice of letter case in RFCs.
- Section 2
Charlie's resolvers are validating, but they have not been upgraded
[...]
resolve it). He is able to fetch both of the other resources - from
this he knows (see the logic below) that he is using legacy, non-
validating resolvers. [...]
Do you mean "he is using legacy validating resolvers"? If it's not
a typo, the behind logic isn't obvious to me and it would help if
you explain it in more detail (instead of just referring to
'below').
- Section 3
[...] Note that
the test is "Is there a key with this KeyID in the resolver's current
trust store for the DNS root", not "Is there any key with this KeyID
in the trust store", nor "Was a key with this KeyID used to validate
this query?".
Unless I miss something, the draft doesn't clarify its use is
limited to root KSK until the next paragraph of this, so I suspect
this statement will confuse a fresh reader who reads this doc from
top to bottom without a particular knowledge of background
discussion. I'd suggest noting it somewhere before this part,
perhaps in the introduction (and maybe also in abstract).
- Section 3
[...] Note
that the is specified in the DNS label using hexadecimal
notation.
I suggest clarifying whether '' contains leading 0s
somewhere in the document (this may not be the best place to do so,
but this is the first reference to 'tag-index' that made the
question occur to me).
- Section 3
If the resolver has not placed a
Root Zone Key Signing Key with tag index value matching the value
specified in the query into the local resolver's store of trusted
keys, then the resolver should return a response indicating that the
response contains authenticated data according to section 5.8 of
[RFC6840].
Should we perhaps define "store of trusted keys" more precisely?
For example, if a key is in the "AddPend" status (per RFC5011) for
the resolver, should it be considered in the "store of trusted
keys"?
- Section 3
This mechanism is to be applied only by resolvers that are performing
DNSSEC validation, and applies only to RRset responses to an A or
query (Query Type value 1 or 28) where the resolver has
authenticated the response RRset according to the DNSSEC validation
process and where the query name contains either of the labels
described in this section as its left-most label.
Is the RRset in 'response RRset' intentionally added (or in other
words can't it just be 'response')? Perhaps is the intent to
exclude negative responses? In any case I think the intent should
be clearer here. And if a mere 'response' suffices it's probably
less confusing to just say so.
BTW, you might want to say 'a query for an Address Record' or 'an
Address Record query' instead of 'an A or query' (I guess
that's the intent of the introduction of this term. See also my
first comment on Section 1.1 above).
- Section 4
o Vleg: A DNSSEC-Validating resolver that does not implement this
mechanism will respond with an A or RRSET response for
"kskroll-sentinel-is-ta", an A record response for "kskroll-
sentinel-not-ta" and SERVFAIL for the invalid name.
+ s/RRSET/RRset/?
+ 'an A record response' should be 'an A or record response' or
it's revised using the "Address Record" term. Same comment
applies to other part of this section including the table.
--
JINMEI, Tatuya
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
