Re: New drafts: draft-kuehlewind-quic-manageability-00 and draft-kuehlewind-quic-applicability-00

[Christian Huitema <[e-mail]>]

On 3/19/2017 4:09 PM, Martin Thomson wrote:
> In HTTP, when you can't get TLS, you can't resolve an https:// URI.
> We have a very clear rule that says that you prefer to fail than to
> accept the risk of compromise.  This is critical to the functioning of
> the protocol.
>
> That might not be true for DNS over QUIC where the expectations for
> security are - shall we say - lower.  But all this needs to say is
> that if you have some security expectations and you find that fallback
> would lead to them being in some way compromised, you fail.

I am not sure that security expectations for DNS over QUIC should be
lower. I would expect DNS over QUIC to match the security of DNS over
TLS (RFC 7858).

We need consider the "game theory" aspects of any downgrade. If we allow
fall back to a non encrypted alternative, then we reward the attackers.
They block QUIC, observe the protocol silently switching to clear text,
get access to the data that they are seeking, and all that without
causing too many customer complaints. On the other hand, if blocking
QUIC just blocks the service, customers will complain, to the service
providers of course, but also very quickly to the intermediaries that
set the block. For these blockers, the support cost will be much higher.
And that means they will be less likely to block random services.

-- Christian Huitema