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

[Phillip Hallam-Baker]

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

[Brotman, Alexander]

I'm not opposed to change this to be in that form. I don't believe this would cause any technical issues.

--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast

-----Original Message-----
From: Phillip Hallam-Baker [mailto:***@gmail.com]
Sent: Thursday, March 08, 2018 2:39 PM
To: ***@ietf.org
Cc: ***@ietf.org; draft-ietf-uta-smtp-***@ietf.org; ***@ietf.org
Subject: 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

[Phillip Hallam-Baker]

If folk are in London, lets talk to IANA and maybe some DNS folk.

I am pretty sure this is a straightforward issue. But it is one we need to
get right.



On Mon, Mar 12, 2018 at 6:34 PM, Brotman, Alexander <

Post by Brotman, Alexander
I'm not opposed to change this to be in that form. I don't believe this
would cause any technical issues.
--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast
-----Original Message-----
Sent: Thursday, March 08, 2018 2:39 PM
Subject: 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.
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.
[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

[Brotman, Alexander]

Due to various obligations, I don’t believe any of the authors are going to be in London (I’ll double check). I’m open to having a meeting/call to discuss this piece of the draft, whether it be during IETF in London or another time.
--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast

From: Uta [mailto:uta-***@ietf.org] On Behalf Of Phillip Hallam-Baker
Sent: Tuesday, March 13, 2018 11:50 AM
To: Brotman, Alexander <***@cable.comcast.com>
Cc: ***@ietf.org; draft-ietf-uta-smtp-***@ietf.org; ***@ietf.org; ***@ietf.org
Subject: Re: [Uta] Secdir last call review of draft-ietf-uta-smtp-tlsrpt-17

If folk are in London, lets talk to IANA and maybe some DNS folk.

I am pretty sure this is a straightforward issue. But it is one we need to get right.



On Mon, Mar 12, 2018 at 6:34 PM, Brotman, Alexander <***@comcast.com<mailto:***@comcast.com>> wrote:
I'm not opposed to change this to be in that form. I don't believe this would cause any technical issues.
--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast

-----Original Message-----
From: Phillip Hallam-Baker [mailto:***@gmail.com<mailto:***@gmail.com>]
Sent: Thursday, March 08, 2018 2:39 PM
To: ***@ietf.org<mailto:***@ietf.org>
Cc: ***@ietf.org<mailto:***@ietf.org>; draft-ietf-uta-smtp-***@ietf.org<mailto:draft-ietf-uta-smtp-***@ietf.org>; ***@ietf.org<mailto:***@ietf.org>
Subject: 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

[Tim Hollebeek]

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

Post by Brotman, Alexander
-----Original Message-----
Sent: Thursday, March 8, 2018 7:39 PM
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

Post by Brotman, Alexander
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.
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

Post by Brotman, Alexander
delay this and meta-think it. But we should anticipate it being joined by

others

Post by Brotman, Alexander
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

Post by Brotman, Alexander
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.
[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'.

Post by Brotman, Alexander
That is probably easier since this prefix does not fit well with the

existing ones.

Post by Brotman, Alexander
_smtp-tlsrpt._report
_______________________________________________
Uta mailing list
https://www.ietf.org/mailman/listinfo/uta

[Alexey Melnikov]

Hi Phillip,

Post by Phillip Hallam-Baker
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.

After looking at this in more details, I think a new registration in the
registry being created by draft-ietf-dnsop-attrleaf is exactly what you
are asking for. I think registering _smtp-tlsrpt there should be
straightforward. However I don't think this document should be delayed
until after draft-ietf-dnsop-attrleaf is done. So if
draft-ietf-dnsop-attrleaf is taking time, the proposed registration can
be moved to draft-ietf-dnsop-attrleaf itself.

Post by Phillip Hallam-Baker
[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

I think this is covered by draft-ietf-dnsop-attrleaf.

Best Regards,
Alexey

[Phillip Hallam-Baker]

I concur, I had come to essentially the same conclusion after discussions
with IANA. The registry we were looking for was the one Dave had proposed
that has not yet been created.

I can sync with Dave.

It might well be that what we want is a sub registry of the form
_smtp._rpt. That way the reporting info for any protocol can be discovered
with no need to obtain a per service registration.

Post by Alexey Melnikov
Hi Phillip,

Post by Phillip Hallam-Baker
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

Post by Phillip Hallam-Baker
the scope of UTA and therefore MUST have an IANA assignment and is a DNS

code

Post by Phillip Hallam-Baker
point which is shared space and therefore MUST have an assignment.
If no IANA registry exists, one should be created.

After looking at this in more details, I think a new registration in the
registry being created by draft-ietf-dnsop-attrleaf is exactly what you
are asking for. I think registering _smtp-tlsrpt there should be
straightforward. However I don't think this document should be delayed
until after draft-ietf-dnsop-attrleaf is done. So if
draft-ietf-dnsop-attrleaf is taking time, the proposed registration can
be moved to draft-ietf-dnsop-attrleaf itself.

Post by Phillip Hallam-Baker
[RFC6763] S. Cheshire and M. Krochmal "DNS-Based Service Discovery" RFC

6763

Post by Phillip Hallam-Baker
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

Post by Phillip Hallam-Baker
existing ones.
_smtp-tlsrpt._report

I think this is covered by draft-ietf-dnsop-attrleaf.
Best Regards,
Alexey

[Brotman, Alexander]

I may have missed the consensus on this. I don’t believe the final DNS entry is hugely important as it pertains to TLSRPT on its own, as long as it extends from the target domain. So, today we have "_smtp-tlsrpt.example.com", but it seems like to get more in line with a proper IANA registration, we should alter this slightly. Is there any reason to not go forward with “_smtp._tls.example.com” or “_smtp._tlsrpt.example.com”?
--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast

From: Uta [mailto:uta-***@ietf.org] On Behalf Of Phillip Hallam-Baker
Sent: Thursday, March 22, 2018 12:09 PM
To: Alexey Melnikov <***@isode.com>
Cc: ***@ietf.org; draft-ietf-uta-smtp-***@ietf.org; IETF Discussion Mailing List <***@ietf.org>; ***@ietf.org
Subject: Re: [Uta] Secdir last call review of draft-ietf-uta-smtp-tlsrpt-17

I concur, I had come to essentially the same conclusion after discussions with IANA. The registry we were looking for was the one Dave had proposed that has not yet been created.

I can sync with Dave.

It might well be that what we want is a sub registry of the form _smtp._rpt. That way the reporting info for any protocol can be discovered with no need to obtain a per service registration.

On Thu, Mar 22, 2018 at 3:17 PM, Alexey Melnikov <***@isode.com<mailto:***@isode.com>> wrote:
Hi Phillip,

Post by Phillip Hallam-Baker
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.

After looking at this in more details, I think a new registration in the
registry being created by draft-ietf-dnsop-attrleaf is exactly what you
are asking for. I think registering _smtp-tlsrpt there should be
straightforward. However I don't think this document should be delayed
until after draft-ietf-dnsop-attrleaf is done. So if
draft-ietf-dnsop-attrleaf is taking time, the proposed registration can
be moved to draft-ietf-dnsop-attrleaf itself.

Post by Phillip Hallam-Baker
[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

I think this is covered by draft-ietf-dnsop-attrleaf.

Best Regards,
Alexey