Hi, > On 06 May 2016, at 00:06, Daniel Margolis <[email protected]> wrote: > I think it's certainly different in that with DMARC we can assume the report > sender can reliably (and securely, insofar as DMARC assumes SMTP works!) > reach the report recipient; with TLSRPT that's not exactly true. > > I think the primary virtue of accepting HTTP/S reports is really in the case > where the recipient has a severely misconfigured MTA. Hopefully in that case > the report sender can still make an insecure SMTP connection, but it's > possible not.
So in that case why not prefer a secure HTTPS connection over an insecure SMTP connection? > So I sort of like keeping the option (at risk of adding another thing for > reporters to have to implement). > > Tying this back to the original topic in this thread, though, I don't think > DEFLATE attacks on HTTPS are a a huge issue since we don't want report > contents to be very sensitive (since, if sent via SMTP, they may be subject > to interception). So HTTPS is mean't only as authentication mechanism in this scenario? I think feedback could possibly contain sensitive material and should be encrypted where possible. In November of 2014 the Internet Architecture Board posted the following statement to their website: https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/ ``` [...] Newly designed protocols should prefer encryption to cleartext operation. There may be exceptions to this default, but it is important to recognize that protocols do not operate in isolation. Information leaked by one protocol can be made part of a more substantial body of information by cross-correlation of traffic observation. There are protocols which may as a result require encryption on the Internet even when it would not be a requirement for that protocol operating in isolation. We recommend that encryption be deployed throughout the protocol stack since there is not a single place within the stack where all kinds of communication can be protected. The IAB urges protocol designers to design for confidential operation by default. We strongly encourage developers to include encryption in their implementations, and to make them encrypted by default. We similarly encourage network and service operators to deploy encryption where it is not yet deployed, and we urge firewall policy administrators to permit encrypted traffic. [...] ``` It's certainly not easy to modify this attack to instantly work on the feedback mechanism, but I'm sure a few clever scientists and hackers may come up with something in time, so this should be considered. > I would say the main goal should be a format that's easy to generate and easy > to parse, though. My totally unscientific guess is that JSON and XML fit the > bill. Being a Googler, if it were up to me I'd use protocol buffers, but you > know... ;) I like protobufs too (and was actually thinking about them). But,.. :) Aaron
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
