Re: [DNSOP] Possible issues with DNS over HTTP wire format draft

[Martin Thomson]

Thanks for starting the discussion Shane.

On 8 August 2016 at 23:41, Shane Kerr  wrote:
> My own feeling is that this should be
> enough; apparently the recommendation to require TLS was made in the
> HTTP/2 working group and rejected, so I am not sure that we need to
> re-visit the entire discussion around the DNS over HTTP protocol.

That's the result of a fairly old discussion.  You will note that all
protocols that use HTTP developed since (a long time ago) all require
HTTPS.  The reasons that HTTP decided cleartext wasn't prohibited
don't apply to a new protocol.

Also note that HTTP/2 on the web is - at least to my knowledge -
exclusively HTTPS at the moment.  The RFC might not mandate
encryption, but no one has deployed the unencrypted variant at any
real scale.

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

Re: [DNSOP] Ben Campbell's No Objection on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with COMMENT)

[Ben Campbell]

On 5 Aug 2016, at 16:05, Wes Hardaker wrote:


"Ben Campbell"  writes:

[everything else addressed but I had a question about this last one:]


-8: Seems like there could be  more to say about the potential
consequences about the “fail or proceed without security” 
decision

in 6
and 6.1.


I think the world is very much at a loss as to the best thing to do 
in
that case.  And is likely very case specific.  Military 
installations

tend to be a bit more strict about continuing through to a
unacceptable
security certificate, eg.  I'm not sure we can enumerate every
context,
but rather say each local policy will need to do what is appropriate
for them.



I think it would be useful to say _that_. (as in "here's a security
consideration people need to, well, consider")


How's this sound as a concluding sentence:

  
If Host Validator detects that DNSSEC resolution is not
possible it SHOULD log the event and/or SHOULD warn user. In
the case there is no user no reporting can be performed thus
the device MAY have a policy of action, like continue or
fail.
  new:  Until middle boxes allow DNSSEC protected information to
traverse them consistently, software implementations may need
to offer this choice to let users pick the security level they
require.
  

It's not an easy thing without introducing more "temporal" text into 
the document


I have no objection to adding that that, but I was thinking along the 
lines of "Note that continuing without DNSSEC protection in the absence 
of a notification or report could lead to situations where users assume 
a level of security does not exist."


Thanks!

Ben.

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