Subject: [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal

From: tjw ietf <[email-masked]>
Date: Thu, 1 Feb 2018 14:14:53 -0500

This starts a Working Group Last Call for draft-ietf-dnsop-session-signal

Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/

Please review the draft and offer relevant comments. Also, if someone feels
the document is *not* ready for publication, please speak out with your
reasons.

We are doing a three week Working Group Last Call process, and we're cross
posting to a few groups where we hope to receive some strong reviews.

This WGLC ends at midnight, 22 February 2018.

thanks
Tim/suzanne

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 02 Feb 2018 13:57:32 -0800

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 7 Feb 2018 15:22:01 +0100

On Thu, Feb 01, 2018 at 02:14:53PM -0500,
 tjw ietf <[email-masked]> wrote 

> This starts a Working Group Last Call for draft-ietf-dnsop-session-signal

After reading -05 :

My personal feeling is that it is complicated, with a lot of
details. May be separating in two documents, one for the base DSO
concept and one for the standards TLV (with their detailed behavior)
would have been better.

There is a discussion about a possible Privacy section
<https://github.com/raybellis/draft-bellis-dnsop-session-signal/pull/36> for
which I suggest the following text:

The intention of this specification is to enable stateful information
(connection parameters and DNS data) directly related to the DSO
Session to be transmitted. This creates trackable state and prevents
queries from coming from successive privacy addresses, as could be the
case with regular DNS queries, for a privacy-conscious client. Before
using DSO (or any kind of long-lived DNS sessions), this consequence
should be taken into account. The risk is partially mitigated by using
encryption (which protects against sniffing by a third-party, but not
against logging by the server.)

The design of new TLV must also avoid adding any information that
could make this tracking easier.

Now, other points:

>   There are a myriad of other potential use cases for DSO given the
>   versatility and extensibility of this specification.

I don't really like this sort of sentence. Either we have ideas about
these potential use cases and we should write them down, or we don't
and we should avoid this sort of very general words (after all, human
imagination being what it is, we can be sure surprising use cases will
be found.)

>   If the RCODE is set to any value other than NOERROR (0) or DSONOTIMP
>   (tentatively 11), then the client should assume that the server does
>   not support DSO.

(Why "should" in lower case?) RFC 1035 being very clear that the rcode
from a non-DSO server must be NOTIMP (this is also said in section
4.2.1 of the draft), I suggest to change that to:

If the server does not handle DSO at all, it MUST reply with RCODE
NOTIMP (4) (this is from RFC 1035, section 4.1.1). Because not all
servers will be correct, if the client receives an answer with the
RCODE set to any value other than NOERROR (0) or DSONOTIMP
(tentatively 11), then the client should assume that the server does
not support DSO.

> DNS Stateful Operations uses "DSO request messages" and "DSO
> response messages".  DSO request messages are further subdivided
> into two variants, "acknowledged request messages" (which generate a
> corresponding response message) and "unacknowledged request
> messages" (which do not generate any corresponding response
> message).

It seems to me that the draft uses "response-requiring messages" as a
synonym of "acknowledged request messages" (and
"non-response-requiring messages" as a synonym of "unacknowledged
request messages"). If I'm correct, it would be better to state it
clearly in the terminology section.

> 7.1.  MESSAGE ID
> The table below illustrates the legal combinations:

Since there are only four combinations, I do not find this table useful.

Last, RFC 5226 (IANA considerations section) is now replaced by RFC 8126

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Feb 2018 11:23:57 -0500

> could make this tracking easier.

Thanks for this text.   I am pretty happy with it; the only thing I'd be tempted to change would be the last sentence, which I would state this way instead:

When designing new TLVs, the potential for the TLV to be used as a tracking identifier should be taken into consideration, and should be avoided when not required.

I say this because in some cases it's perfectly fine to know who you're talking to; e.g. in draft-sctl-dnssd-mdns-relay-02, I specified the use of TLS client authentication, because hybrid relays are network infrastructure.   Although this is happening at the TLS layer and not the session signaling layer, it's effectively the same thing.

Your other comments all make sense to me—thanks for the thorough review and particularly for suggesting text and not just saying "you should change this text."   :)

---

From: "Jan Komissar (jkomissa)" <[email-masked]>
Date: Wed, 14 Feb 2018 22:12:29 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    Section 2:

    --Paul Hoffman
    
    _______________________________________________
    DNSOP mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/dnsop

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Feb 2018 17:22:38 -0500

> 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 req…

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?

---

From: "Jan Komissar (jkomissa)" <[email-masked]>
Date: Wed, 14 Feb 2018 23:06:42 +0000

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 <[email-masked]>
Date: Wednesday, February 14, 2018 at 5:22 PM
To: "Jan Komissar (jkomissa)" <[email-masked]>
Cc: Paul Hoffman <[email-masked]>, dnsop <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dnssd] [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal

On Feb 14, 2018, at 5:12 PM, Jan Komissar (jkomissa) <[email-masked]<mailto:[email-masked]>> 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.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Feb 2018 18:13:47 -0500

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

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 suppor…

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.

> 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-T…

Is is that you want to make DSO-over-TLS MTI and DSO-over-TCP optional?

---

From: Ray Bellis <[email-masked]>
Date: Wed, 14 Feb 2018 23:13:54 +0000

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

---

From: "Jan Komissar (jkomissa)" <[email-masked]>
Date: Thu, 15 Feb 2018 22:34:48 +0000

Hi Ted,

After pondering your response, my comments are inline:

Date: Wednesday, February 14, 2018 at 6:13 PM

On Feb 14, 2018, at 6:06 PM, Jan Komissar (jkomissa) <[email-masked]<mailto:[email-masked]>> 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.

Jan:
I was imagining a single operating system service performing all DSO based operations on behalf of various applications, but it would probably more likely be one service for all DPN users and another for protocol Z users, and the existing stub resolver for traditional DNS queries. And in that case, there would be no reason to force all DSO based operations into TLS. I can live with that.

Jan:
Upon further review, I agree.

Jan:
It would be nice if we could make steps towards more secure DNS communications, and since DSO requires new client code, it could be a way of moving in that direction. I’m not ready to deprecate DNS-over-TCP, there are probably too many existing clients and servers deployed to start that process. On the other hand, if we want to improve communications security, it might be good to find ways that strongly encourage implementers in our space to adopt secure protocols, and making new features secure is a way to do that. So, it’s not that DSO is special, but It’s an opportunity to improve DNS security. That’s why I would prefer the draft to require TLS. If the WG disagrees, so be it.

Regards,

Jan.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 15 Feb 2018 18:36:31 -0500

> After pondering your response, my comments are inline:

Thanks!

> It would be nice if we could make steps towards more secure DNS communications, and since DSO requires new client code, it could be a way of moving in that direction. I’m not ready to deprecate DNS…

Understood.   One way in which this certainly makes sense is that although DNSSEC can be used to authenticate DNS data, DSO data can't really be validated that way.   And we don't have TSIG either.   So it's certainly worth considering.

---

From: David Schinazi <[email-masked]>
Date: Fri, 16 Feb 2018 09:54:09 -0800

Hi,

(chair hat off)

I've reviewed draft-ietf-dnsop-session-signal-04 and -05 and think -05 is ready to move forward.
Draft -05 addresses the points I raised on -04 and in my opinion makes the document clearer.

Thanks,
David Schinazi

> On Feb 1, 2018, at 11:14, tjw ietf <[email-masked]> wrote:
> 
> 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ <https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/>
> 
> Please review the draft and offer relevant comments. Also, if someone feels the document is *not* ready for publication, please speak out with your reasons.
> 
> We are doing a three week Working Group Last Call process, and we're cross posting to a few groups where we hope to receive some strong reviews. 
> 
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 21 Feb 2018 10:39:15 -0800

I think Jan makes a good point.

Suppose there’s a server that supports DNS over TCP, and DSO signaling, and Push Notifications, and DNS Update, and maybe other things.

Now suppose a client connects to that server. The server doesn’t know what that client is going to do. The client may do queries over TCP, or DNS updates. It may do queries over TCP and use the DSO signaling to request a longer inactivity timeout. It may request Push Notifications (which are currently specified to require TLS). It may do all of those.

When the server receives an incoming TCP connection request from a client, what are the first bytes received over that TCP connection? Are they a DNS header and message body? Are they a TLS handshake message? Can it be either? How does the server know?

Stuart Cheshire

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Feb 2018 13:50:03 -0500

> When the server receives an incoming TCP connection request from a client, what are the first bytes received over that TCP connection? Are they a DNS header and message body? Are they a TLS handsha…

Doesn’t dns over tls use a different port?

---

From: tjw ietf <[email-masked]>
Date: Fri, 23 Feb 2018 08:22:47 -0500

The WGLC last call for session-signal has ended. I was on a conference call
with the Authors yesterday, and they were addressing all open items, with
the plan of releasing an updated version in the next day or so.

Once this version is published, we'll ask all who submitted comments to
confirm they have been addressed adequately, before moving on.

thanks

Tim

On Thu, Feb 1, 2018 at 2:14 PM, tjw ietf <[email-masked]> wrote:

> Please review the draft and offer relevant comments. Also, if someone
> feels the document is *not* ready for publication, please speak out with
> your reasons.
>