Re: [Add] data integrity and DNSSEC or DoH/DoT

[Neil Cook <[e-mail]>]

> On 3 Sep 2019, at 15:46, Eric Rescorla <[e-mail]> wrote:
> 
> It’s not entirely  useless. The problem it does solve is giving the user a better experience when a site is blocked for resolvers that support this extended Error Code. Currently for HTTPS the user will end up with a TLS connection error of some kind (or a blank page in some browsers). If a resolver returns a “blocked/censored/prohibited” response, then the browser can tell the user that the web page was blocked with an informative message. Assuming this becomes the default behaviour for non-malicious resolvers then I think it will a good signal for distinguishing  "this is malware blocking" from "this resolver is malicious”.
> 
> I'm not following. Suppose that we add an error code that says "this site has malware". Now, I operate a resolver which is malicious in the sense that it wishes to block a certain form of content (say, access to the IETF) but don't want the people whose content I am blocking is being blocked for that reason. So, instead I return "this site has malware".
> 
> My point here is that a code of this type only tells you what the resolver *asserts* the reason it blocked it is, it doesn't necessarily tell you what the actual reason that the content was blocked.
> 

Ok yes I understand. The blocking reason wouldn’t be that useful in the general case of not knowing whether a resolver was malicious. However I think the fact that the resolver is telling you that the content is blocked is still useful, no matter what the reason for the blocking is, for the reason described above. For example in your use-case, the user would see “this site is blocked by the DNS resolver” (or whatever) rather than “TLS connection error” which would be the case today.

Also assuming the resolver is “trusted” in some way (e.g. Mozilla TRR program) then the reason for blocking may then become useful I’d have thought.

Neil

> -Ekr
> 
> 
> 
> Neil Cook
> [e-mail] <mailto:[e-mail]>
> 
> -------------------------------------------------------------------------------------
> Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738
> Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein, Stephan Martin 
> Chairman of the Board: Richard Seibt
> 
> European Office: 
> Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District Court Siegen, HRB 8718 
> Managing Director: Frank Hoberg
> 
> US Office: 
> Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA 
> -------------------------------------------------------------------------------------
> 


Neil Cook
[e-mail]

-------------------------------------------------------------------------------------
Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738
Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein, Stephan Martin 
Chairman of the Board: Richard Seibt

European Office: 
Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District Court Siegen, HRB 8718 
Managing Director: Frank Hoberg

US Office: 
Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA 
-------------------------------------------------------------------------------------