So, the CABF discussion was similar, but different (I am a master of the obvious). I'll summarize a bit for those who weren't there, since that's most of the people reading this. This proposal is about Alice providing more information to Bob about problems she is experiencing sending secure messages to Bob. The CABF discussion was about how Phillip retrieves information from and provides feedback to Charlie, where Charlie is a trust provider for Alice and Bob, and Phillip is some random guy on the internet, whose name has been chosen at random. This may or may not be related to actual errors encountered, it was more of a problem reporting address discovery mechanism (at least, that's what motivated the discussion, and it diverged from there). It probably is worth thinking about these problems more in general and trying to group them into use cases. CAA iodef is another example, and closer to the CABF case, since Alice/Bob (whoever is the server, or both for mutual auth) is indicating she/he wants information about failures from Charlie. But yeah, the bigger discussion should not block attempts to solve specific instances of the problem. There are lots of them. There are probably other similar issues in other protocols that I'm less familiar with. -Tim > -----Original Message----- > From: Uta [mailto:uta-bounces@xxxxxxxx] On Behalf Of Phillip Hallam-Baker > Sent: Thursday, March 8, 2018 7:39 PM > To: secdir@xxxxxxxx > Cc: uta@xxxxxxxx; draft-ietf-uta-smtp-tlsrpt.all@xxxxxxxx; ietf@xxxxxxxx > Subject: [Uta] Secdir last call review of draft-ietf-uta-smtp-tlsrpt-17 > > Reviewer: Phillip Hallam-Baker > Review result: Has Issues > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. > > General comments: > > Five minutes after I received the review request, a very similar proposal was > made in CABForum for reporting PKIX cert issues. > > The Security Considerations section proposes use of DNSSEC, what happens if > that is misconfigured? Well it should be reported. > > The logic of this proposal is that something like it become a standard > deliverable for a certain class of service specification. I don't think we should > delay this and meta-think it. But we should anticipate it being joined by others > like it sharing syntax, DDoS mitigation, etc. > > Specific issues > > The DNS prefix _smtp-tlsrpt is defined. This is not mentioned in the IANA > considerations. It is a code point being defined in a protocol that is outside the > scope of UTA and therefore MUST have an IANA assignment and is a DNS code > point which is shared space and therefore MUST have an assignment. > > If no IANA registry exists, one should be created. > > In general, the approach should be consistent with the following: > > [RFC6763] S. Cheshire and M. Krochmal "DNS-Based Service Discovery" RFC > 6763 DOI 10.17487/RFC6763 February 2013 > > It might well be appropriate to create a separate IANA prefix registry 'report'. > That is probably easier since this prefix does not fit well with the existing ones. > > _smtp-tlsrpt._report > > > _______________________________________________ > Uta mailing list > Uta@xxxxxxxx > https://www.ietf.org/mailman/listinfo/uta
<<attachment: smime.p7s>>
