On 17/07/2016 10:52, Matthew Pounsett wrote: > I think this draft is a good candidate for adoption. > > I'd like to echo Ted's comment that the draft should explicitly > state the sort of context this is meant to be used in. Calling out > TCP sessions as an example would be a good start.
OK, that's worth calling out, and I'll incorporate something in the next revision. It's *definitely* intended for TCP. > I found myself wondering how the server is meant to initiate SS > messages to the client in a UDP context where the client is behind a > NAT, for example. On that particular note - see the first paragraph of the "Protocol Details" section. Since UDP doesn't provide the required guarantee it's implicitly not suitable. For other "session like" protocols, in discussion with Tom and others last night, I think it should be suitable for DNS-o-TLS, and likely DNS-o-DTLS but *not* w.r.t a (D)TLS session resumption. That is to say, if a new TCP connection uses the same TLS session as a prior one, that doesn't count as the same "DNS session". I think it would *not* be suitable for DNS with Cookies, since that has an expectation that server farms could share cookie state, and I think it would be onerous to expect any other "session state" to be shared across farms. > I'm also wondering if wouldn't be possible to implement this in a > more backward-compatible way. I anticipate a lot of people who don't > even intend to capture SS messages having to update their code > anyway, because the messages won't be automatically discarded and > will confuse parsers that attempt to analyze them. On the other > hand, I am wiling to discuss the merits of advancing the expectation > that the message format could change with the opcode. I've had feedback from both ends of the spectrum - some would like to use an RR, others would like a completely clean break. Personally, I think the 12-octet header with what should appear as "trailing garbage" is a fair compromise. I've written plenty of DNS packet parsing code myself that I know would do "interesting things" if the octets used for the section counts had "odd" data in them, but never any that would reject a packet outright if there was stuff tacked on the end. That said, I could live with an RR-based format, but do feel *very* strongly that if so it must be a new RR, and not an overload of the already confused and poorly implemented EDNS OPT RR. Even then, though, I think it would be a mistake to permit this RR to end up "tagging along" with a query or response - that's what EDNS is for, and in part why this specifies an OpCode. Ray _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
