[dns-privacy] Ben Campbell's Yes on draft-ietf-dprive-dns-over-tls-07: (with COMMENT)

[Ben Campbell]

Ben Campbell has entered the following ballot position for
draft-ietf-dprive-dns-over-tls-07: Yes

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-dprive-dns-over-tls/



--
COMMENT:
--

I'm balloting yes, but I do have a few comments/questions:

- 3.1, third paragraph:
This seems to put normative requirements on clients and servers that do
not implement this draft. If that is really needed, then perhaps this
needs to update the appropriate base spec(s)?

- 3.2, last paragraph:
That's a bit of an odd use of SHOULD. I suggest s/SHOULD/can

- 3.3:
This section seems more about DNS over TCP in general. Is it specific to
TLS? Are the 2119 keywords in this section new requirements, or do they
describe existing requirements from 5966/7766? (If the latter, please
consider stating them with descriptive language rather than normative
language.)

- 4 and subsections:
There seems to be a notable absence of a profile that requires server
authentication but does not require pinning. I assume there's a good
reason for that which is obvious to people with stronger TLS and/or DNS
backgrounds than mine. But it might be helpful to say why.

Do (or should) the profiles have anything to say about clear-text
fallback if a client cannot connect to the server's DNS-over-TLS port, or
the TLS handshake fails? I infer that such fallback should not occur with
the pinned profile, but what about the opportunistic profile?


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Call for agenda for DPRIVE at IETF95 (BA).

[Warren Kumari]

Hi there all,

We have some agenda time for DPRIVE in Buenos Aires, please let us know is
you need some agenda time to present.

Please also keep in mind that we give time to documents that have had
discussion on-list, and that have open issues that will benefit from
discussions.

Embarrassingly, I've been a little disappointed at the lack of response to
our original call for agenda time.  I was planning on replying to that
email as a reminder -- but I cannot find it. It seems that somehow Tim and
I may not have sent the original call for agenda items...

W
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Two issues on draft-ietf-dprive-dnsodtls-04.txt

[Dan Wing]

On 14-Mar-2016 08:06 am, Stephane Bortzmeyer  wrote:
> 
> On Fri, Jan 22, 2016 at 05:51:22AM +,
> Tirumaleswar Reddy (tireddy)  wrote 
> a message of 62 lines which said:
> 
>> This revision addresses comments from Christian and refers to 
>> draft-dgr-dprive-dtls-and-tls-profiles.
>>Title   : DNS over DTLS (DNSoD)
>>  Filename: draft-ietf-dprive-dnsodtls-04.txt
> 
>> If the DNS client receives a hard ICMP error [RFC1122], it MUST
>> immediately cease attempts to re-transmit its ClientHello.
> 
> Isn't there a risk of downgrade attack here? ICMP errors are not
> authentified so an active attacker, even if off-path, could convince a
> client to disable DNS over DTLS.


> May be add a reference RFC 5927 to
> emphasize that the credibility of ICMP errors should be challenged?
> (RFC 5927 is for TCP, I do not find an equivalent for UDP, where the
> problem is more complicated, we cannot use the sequence numbers to
> check the ICMP message.)

Yeah, so we can adopt same position as DNS-over-TLS, which says in its security 
considerations:

  "1.  There are known attacks on TLS, such as person-in-the-middle and
   protocol downgrade.  These are general attacks on TLS and not
   specific to DNS-over-TLS; please refer to the TLS RFCs for
   discussion of these security issues.  Clients and servers MUST
   adhere to the TLS implementation recommendations and security
   considerations of [RFC7525] or its successor.  DNS clients
   keeping track of servers known to support TLS enables clients to
   detect downgrade attacks.  For servers with no connection history
   and no apparent support for TLS, depending on their Privacy
   Profile and privacy requirements, clients may choose to (a) try
   another server when available, (b) continue without TLS, or (c)
   refuse to forward the query."

-d


> 
>> The existing Query ID allows multiple requests and responses to be
>> interleaved in whatever order they can be fulfilled by the DNS
>> server.
> 
> Only the Query ID? RFC 7766 (a DTLS session, in one way, is a bit like
> a TCP connection) says "Since pipelined responses can arrive out of
> order, clients MUST match responses to outstanding queries on the same
> TCP connection using the Message ID.  If the response contains a
> question section, the client MUST match the QNAME, QCLASS, and QTYPE
> fields." For DNS over ordinary UDP, I do not find a RFC with clear
> rules but RFC 3833 section 2.2 and RFC 5452 section 4 both use more
> than the Query ID. Since we are protected by DTLS, we may be more lax
> but draft-ietf-dprive-dns-over-tls-04 is not "Since pipelined
> responses can arrive out-of-order, clients MUST match responses to
> outstanding queries using the ID field, query name, type, and class."
> 
>> Implementing DNSoD on root servers is outside the scope of this
>> document.
> 
> Should be deleted (why only the root servers?)
> 
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy


___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] Two issues on draft-ietf-dprive-dnsodtls-04.txt

[Stephane Bortzmeyer]

On Fri, Jan 22, 2016 at 05:51:22AM +,
 Tirumaleswar Reddy (tireddy)  wrote 
 a message of 62 lines which said:

> This revision addresses comments from Christian and refers to 
> draft-dgr-dprive-dtls-and-tls-profiles.
> Title   : DNS over DTLS (DNSoD)
>   Filename: draft-ietf-dprive-dnsodtls-04.txt

> If the DNS client receives a hard ICMP error [RFC1122], it MUST
> immediately cease attempts to re-transmit its ClientHello.

Isn't there a risk of downgrade attack here? ICMP errors are not
authentified so an active attacker, even if off-path, could convince a
client to disable DNS over DTLS. May be add a reference RFC 5927 to
emphasize that the credibility of ICMP errors should be challenged?
(RFC 5927 is for TCP, I do not find an equivalent for UDP, where the
problem is more complicated, we cannot use the sequence numbers to
check the ICMP message.)

> The existing Query ID allows multiple requests and responses to be
> interleaved in whatever order they can be fulfilled by the DNS
> server.

Only the Query ID? RFC 7766 (a DTLS session, in one way, is a bit like
a TCP connection) says "Since pipelined responses can arrive out of
order, clients MUST match responses to outstanding queries on the same
TCP connection using the Message ID.  If the response contains a
question section, the client MUST match the QNAME, QCLASS, and QTYPE
fields." For DNS over ordinary UDP, I do not find a RFC with clear
rules but RFC 3833 section 2.2 and RFC 5452 section 4 both use more
than the Query ID. Since we are protected by DTLS, we may be more lax
but draft-ietf-dprive-dns-over-tls-04 is not "Since pipelined
responses can arrive out-of-order, clients MUST match responses to
outstanding queries using the ID field, query name, type, and class."

> Implementing DNSoD on root servers is outside the scope of this
> document.

Should be deleted (why only the root servers?)

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy