Re: [secdir] [Uta] Secdir last call review of draft-ietf-uta-smtp-tlsrpt-17

[Tim Hollebeek <[e-mail]>]

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:[e-mail]] On Behalf Of Phillip Hallam-Baker
> Sent: Thursday, March 8, 2018 7:39 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta