Subject: [Uta] TLSRPT further comments

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 5 Dec 2017 23:13:34 -0500

Section 4.3.2.1:

      "dnssec-invalid": This would indicate that no valid records were
      returned from the recursive resolver.  The request returned with
      SERVFAIL for the requested TLSA record.  It should be noted that
      if the reporter's systems are having problems resolving
      destination DNS records due to DNSSEC failures, it's possible they
      will also be unable to resolve the TLSRPT record, therefore these
      types of reports may be rare.

Unfortunately, failure to resolve TLSA records is not yet always a
result of a broader DNS outage.  A small fraction of systems have
nameservers that are either behind firewalls which implement misguided
filtering of queries by RRtype (blocking TLSA and other "unusual"
queries) or are buggy and mishandle authenticated denial of existence.
Therefore, the "may be rare" sentence should I think be deleted.

We could perhaps add a "dane-required" failure mode for cases where
DANE is mandatory (by mutual agreement perhaps), but then the receiving
domain's TLSA records (really the records for the underlying MX hosts)
are unexpectedly removed, or become "insecure" if DNSSEC is disabled
(DS records removed from parent zone).

Speaking of field names, a recent discussion on the ACME list concerned
field names and whether to use "camelCase" or "kebab-case" (I hope the
distinction is immediately apparent), and noted that "camelCase" is often
a much better fit for programming language bindings because "camelCase"
field names can be used directly as structure member field identifiers,
enabling machine generation of encoding/decoding code from structure
definitions.  I think this is a reasonable argument for camels over
kebabs, any thoughts on whether it is possible to revise the field names
accordingly?

Section 4.4:

I notice that:

     "failure-details": [
       {
         "result-type": result-type,
         "sending-mta-ip": ip-address,
         "receiving-mx-hostname": receiving-mx-hostname,
         "receiving-mx-helo": receiving-mx-helo,
         "failed-session-count": failed-session-count,
         "additional-information": additional-info-uri,
         "failure-reason-code": failure-reason-code
         }
       ]

includes only the "receiving-mx-hostname" and not its IP address.  Some
sites have multiple hosts behind a single name, e.g. sometimes the IPv4
address for mail.example.com lands on a different machine than the IPv6
address for the same name (and indeed they present different certificate
chains, ...).  Leaving out the address might make it more difficult to
identify the problem receiving machine.  Perhaps the intention here is
that receiving systems should make an effort to assign different
"receiving-mx-helo" names in such to disambiguate these cases?  If so,
perhaps that should be mentioned in the text.

The format for DANE "policy-string" values is both under-specified,
and needlessly complex:

      "policy-string": A string representation of the policy, whether
      TLSA record ([RFC6698] section 2.3) or MTA-STS policy.  Examples:
      TLSA: ""_25._tcp.mx.example.com.  IN TLSA ( 3 0 1 \
      1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D7 47D1D085D
      )""...

It should be more clear whether the "TLSA:" prefix is part of of the
string (I believe it is not), and what the pair of consecutive double
quotes is about, and how multiple TLSA records are represented.  The
JSON policy includes "\n" separators (which JSON maps to actual newlines),
are TLSA records to be separated with similar logical newlines?

More importantly, the form:

  _25._tcp.mx.example.com. IN TLSA ( 3 0 1 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D7 47D1D085D)

carries much unnecessary syntax.  It should instead be a simple
quintuple (qname, usage, selector, mtype, data):

   _25._tcp.mx.example.com. 3 0 1 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D747D1D085D

with the implied "IN TLSA" and "(" ")" removed, and the hex data
presented without any internal whitespace.  With that simplified
it remains only to specify clearly how present a complete TLSA
RRset.

Another nit:

   o  "domain": The Policy Domain is the domain against which the MTA-
      STS or DANE policy is defined.  In the case of Internationalized
      Domain Names ([RFC5891]), the domain is the Punycode-encoded
      A-label ([RFC3492]) and not the U-label.

A domain name is not a "label" it consists of labels separated by "."
characters.

Also how are "policy-domain" and "mx-host" to be specified in the
DANE case?  DANE policy is per-MX, not per-domain, and mx-host seems
redundant in both cases, since with STS the policy string surely
contains the same data.  What goes in these fields when no policy
is obtained, they don't appear to be optional...

Why in Section 5.1 is there a "report filename"?  Surely the
processing and storage of reports is entirely up to the receiving
system, which should ignore filename hints from the sender.

Why is the Content-Encoding (gzip or not) specified via a filename
and not the standard header used for this purpose?

In section 5.3 what are these "%s" prefixes in front of literal
quoted strings?  Is this a standard syntax?

   The [RFC5322].Subject field for report submissions SHOULD conform to
   the following ABNF:

       tlsrpt-subject = %s"Report" FWS               ; "Report"
                        %s"Domain:" FWS              ; "Domain:"
                domain-name FWS              ; per [RFC6376]
                %s"Submitter:" FWS           ; "Submitter:"
                domain-name FWS              ; per [RFC6376]
                %s"Report-ID:" FWS           ; "Report-ID:
                "<" id-left "@" id-right ">" ; per [RFC5322]
                [CFWS]                       ; per [RFC5322]
                                                     ; (as with FWS)

In section 5.4, why a separate GZIP-specific media type and not just
a Content-Encoding?  Surely the media type is just the JSON report
format, and GZIP is an encoding layer...

In section 5.5 there's talk of a "logarithmic scale" for retries,
but normally we speak of *exponential* backoff, not logarithmic!

I can't make head nor tail of the verbiage in 5.6.  Sounds like
someone ran over a thesaurus while riding a lawn mower... :-)

Finally, I am concerned that TLSRPT appears to preclude timely
reports, requiring each report to cover a full 24 hours.  Might
it not be reasonable, in some cases to send a timely report on
first failure, to be followed by a summary end of day report
later?  Surely receiving systems might want to learn of problems
more promptly.

Or are do we want to leave that to a separate spec for in-band
reporting (which I guess nobody has yet had the cycles to work
on)?

-- 
	Viktor.

---

From: "Brotman, Alexander" <[email-masked]>
Date: Thu, 7 Dec 2017 13:17:49 +0000

To reference the other message, we'll change that reference for DANE. I'll try to respond in-line for this one.

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

-----Original Message-----
From: Uta [mailto:[email-masked]] On Behalf Of Viktor Dukhovni
Sent: Tuesday, December 05, 2017 11:14 PM
To: [email-masked]
Subject: [Uta] TLSRPT further comments

Section 4.3.2.1:

Unfortunately, failure to resolve TLSA records is not yet always a result of a broader DNS outage.  A small fraction of systems have nameservers that are either behind firewalls which implement misguided filtering of queries by RRtype (blocking TLSA and other "unusual"
queries) or are buggy and mishandle authenticated denial of existence.
Therefore, the "may be rare" sentence should I think be deleted.

----------
This seems to be a different type of operation issue.  If an admin can never resolve a TLSA record from an external site, there may be larger issues going on.  We can alter/remove the sentence, but I don't think it will change the frequency of those types reports.
----------

We could perhaps add a "dane-required" failure mode for cases where DANE is mandatory (by mutual agreement perhaps), but then the receiving domain's TLSA records (really the records for the underlying MX hosts) are unexpectedly removed, or become "insecure" if DNSSEC is disabled (DS records removed from parent zone).

------
I'd be inclined to say that this would appear in a "v2" of this draft.
------

Speaking of field names, a recent discussion on the ACME list concerned field names and whether to use "camelCase" or "kebab-case" (I hope the distinction is immediately apparent), and noted that "camelCase" is often a much better fit for programming language bindings because "camelCase"
field names can be used directly as structure member field identifiers, enabling machine generation of encoding/decoding code from structure definitions.  I think this is a reasonable argument for camels over kebabs, any thoughts on whether it is possible to revise the field names accordingly?

-----
The draft has been like this since the inception, and I can't say I'm inclined to change it.  If there's strong group consensus, we can do it.
-----

Section 4.4:

I notice that:

     "failure-details": [
       {

includes only the "receiving-mx-hostname" and not its IP address.  Some sites have multiple hosts behind a single name, e.g. sometimes the IPv4 address for mail.example.com lands on a different machine than the IPv6 address for the same name (and indeed they present different certificate chains, ...).  Leaving out the address might make it more difficult to identify the problem receiving machine.  Perhaps the intention here is that receiving systems should make an effort to assign different "receiving-mx-helo" names in such to disambiguate these cases?  If so, perhaps that should be mentioned in the text.

----------
We can add this, though, in the case of a front-end VIP, you're going to have the same target IP in many stanzas.  I understand the rationale, just wonder how useful it will be in the end.
---------

The format for DANE "policy-string" values is both under-specified, and needlessly complex:

It should be more clear whether the "TLSA:" prefix is part of of the string (I believe it is not), and what the pair of consecutive double quotes is about, and how multiple TLSA records are represented.  The JSON policy includes "\n" separators (which JSON maps to actual newlines), are TLSA records to be separated with similar logical newlines?

carries much unnecessary syntax.  It should instead be a simple quintuple (qname, usage, selector, mtype, data):

with the implied "IN TLSA" and "(" ")" removed, and the hex data presented without any internal whitespace.  With that simplified it remains only to specify clearly how present a complete TLSA RRset.

------------
The intent was to have the record and the result.  Your changes are acceptable, and we can make the alterations.    In the case of multiple record results, how would you like that to be displayed?  Separated with a semicolon is sufficient I would think.  We'll firm up the examples.
-------------

Another nit:

----
I believe you're asking to replace "label" with "labels", and that's fine.
----

Also how are "policy-domain" and "mx-host" to be specified in the DANE case?  DANE policy is per-MX, not per-domain, and mx-host seems redundant in both cases, since with STS the policy string surely contains the same data.  What goes in these fields when no policy is obtained, they don't appear to be optional...

-----
Perhaps I'm misinterpreting the statement. The policy domain is the recipient domain, while the mx-host is the MX that is attempted.  Those do not need to align, and multiple recipient domains can point to a single MX.  I'm not quite sure which policy you're referring to in the last portion of that paragraph.
-----

Why in Section 5.1 is there a "report filename"?  Surely the processing and storage of reports is entirely up to the receiving system, which should ignore filename hints from the sender.

-----
This is the filename upon delivery.  The receiver can rename the file to anything they'd like.
-----

Why is the Content-Encoding (gzip or not) specified via a filename and not the standard header used for this purpose?

-----
It's specified as both the attached filename and in the Content-Type header.

In section 5.3 what are these "%s" prefixes in front of literal quoted strings?  Is this a standard syntax?

-----
Yes, I believe Chris asked for that change.  I'd have to check list history.
-----

In section 5.4, why a separate GZIP-specific media type and not just a Content-Encoding?  Surely the media type is just the JSON report format, and GZIP is an encoding layer...

----
I believe this was at the request of the WG Chairs.  I'd have to go back through history to verify this.
-----

In section 5.5 there's talk of a "logarithmic scale" for retries, but normally we speak of *exponential* backoff, not logarithmic!

------
Agreed
------

I can't make head nor tail of the verbiage in 5.6.  Sounds like someone ran over a thesaurus while riding a lawn mower... :-)

--------
If the filename/subject disagree with the report, then the report is the authoritative source.
--------

Finally, I am concerned that TLSRPT appears to preclude timely reports, requiring each report to cover a full 24 hours.  Might it not be reasonable, in some cases to send a timely report on first failure, to be followed by a summary end of day report later?  Surely receiving systems might want to learn of problems more promptly.

Or are do we want to leave that to a separate spec for in-band reporting (which I guess nobody has yet had the cycles to work on)?

-------
In-band would be a better place I would think.  The sender cannot guarantee that the receiving site will process reports in a timely fashion.
-------

-- 
	Viktor.

_______________________________________________
Uta mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/uta

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 7 Dec 2017 13:30:58 -0500

> On Dec 7, 2017, at 8:17 AM, Brotman, Alexander <[email-masked]> wrote:
> 
> 
>> Section 4.3.2.1:
>> 

I run a roughly daily survey of the now ~5.1 million DNSSEC-signed
domains that I've gathered from various sources.  Today, among these
5.1 million domains 132 have the property that:

	0. They have a working MX host
	1. DNS lookups work fine for "typical" MX/A/AAAA/... queries.
	2. TLSA lookups consistently ServFail.

The reason is either misguided firewall that filters the query stream
or incorrect handling of DNSSEC "denial of existence", causing some or
all queries for records that don't exist to fail.  The problem is even
more common (another ~400 domains) if we remove requirement 0 and
include parked or otherwise non-email domains, but these are of course
out of the scope for the moment.

Also today 87 MX hosts have non-matching TLSA records, 4 don't offer
STARTTLS despite published TLSA records, 2 have certificates with
non-matching names, and 2 more are expired.  So in the "problem
landscape" DNSSEC failures that break primarily TLSA records, while
the DNS appears to otherwise be working are not actually unusual.
One would expect that all TLS policy problems are comparatively
rare (and indeed at present they are), and the question is now
about frequency among problem destinations.

So in fact the qualifier that "these types of reports may be rare"
is unnecessary, speculative and does not match present reality.

> I'd be inclined to say that this would appear in a "v2" of this draft.

Drafts don't have a "v2".  I don't expect to see a "bis" revision
of the published RFC any time soon, the WG will soon be closed.
There is still time to make some final changes.  I apologize for
the belated "tlsrpt" feedback, I was too busy with STS and other
matters to give any feedback on "tlsrpt", so here it is, "late",
but not "never".

>> I think this is a reasonable argument for camels over kebabs, any thoughts on whether it is possible to revise the field names accordingly?
> 

Please do consider this.  I've lately been doing some Haskell
programming, and it supports implicit generation of JSON encoders
from structure type definitions, freeing the developer from having
to write any code to get JSON output, but with "kebab-case" direct
"deriving" of a JSON encoder is no longer possible and one would
have to explicitly define some encoding rules.  I don't think that
Haskell is unique in allowing camelCase identifiers and not
"kebab-case" identifiers.

> We can add this, though, in the case of a front-end VIP, you're going to have the same target IP in many stanzas.  I understand the rationale, just wonder how useful it will be in the end.

Yes, the IP will not always be sufficient to disambiguate
all problems, but load-balanced MX-pools are more typical
of large providers that presumably have more operational
discipline and one hopes will rarely if ever mess up. On
the other hand, smaller SOHO domains do make mistakes from
time to time, and it is among these that I in fact sometimes
see TLS working for (say) IPv4 and not (say) IPv6 of the
"same" MX host, which turns out to be the "same" in name
only.

> The intent was to have the record and the result.  Your changes are acceptable, and we can make the alterations.    In the case of multiple record results, how would you like that to be displayed?…

The "(" and ")" are entirely optional, the TLSA record is well-formed
without them.  Since the policy type is TLSA, why repeat "IN TLSA",
it is redundant.  Internal optional white-space in the data payload
needlessly and significantly complicates parsing.  As for separators,
I would much prefer newline ("\n" just like in the STS policy blob).

This portion of the spec really should be more formal, it presently
just presents a free-form example, rather than a well-defined syntax.
What's the intent of the consecutive double-quote characters for
example?

> I believe you're asking to replace "label" with "labels", and that's fine.

Yes, basically though the change requires a few more words to make the
grammar work.

> Perhaps I'm misinterpreting the statement. The policy domain is the recipient domain, while the mx-host is the MX that is attempted.

That's not what the draft text says.  Instead it has:

  o  "mx-host-pattern": The pattern of MX hostnames from the applied
      policy.  It is provided as a string, and is interpreted in the
      same manner as the "Checking of Wildcard Certificates" rules in
      Section 6.4.3 of [RFC6125].  In the case of Internationalized
      Domain Names ([RFC5891]), the domain is the Punycode-encoded
      A-label ([RFC3492]) and not the U-label.

So it sure seems to be the "mx" element of the policy, repeated for
some reason.

>  Those do not need to align, and multiple recipient domains can point to a single MX.  I'm not quite sure which policy you're referring to in the last portion of that paragraph.

The "policy-string" in the JSON report in Section 4 already contains
the same "mx-host-pattern" (called just "mx").

>> Why in Section 5.1 is there a "report filename"?  Surely the processing
>> and storage of reports is entirely up to the receiving system, which
>> should ignore filename hints from the sender.
> 

A JSON report is NOT a file.  It makes no sense to have to specify
a filename and just creates security issues when one is processed
by poorly thought out receiving software.  If the intended purpose
of the filename is to carry useful metadata (rather than suggest
a storage location), such metadata should be encoded via additional
MIME attributes of the media type.

> It's specified as both the attached filename and in the Content-Type header.

I see this as a mistake.  There is only one media type involved
here, which may have a Content-Encoding.  A receiving system may
always decompress any compressed form as it comes in (or just
use uncompressed inputs as-is) parse the JSON and load the data
into a database.  Another receiving system may always compress
any uncompressed inputs and save the reports into a file store
for archival or onward delivery.  This is up to the receiving
system, but either way I see only the one media type here.

The issue is perhaps that while "HTTP" has "Content-Encoding",
MIME as defined in RFC-2045 does not:

    https://www.ucolick.org/~sla/fits/mime/inetstds.html

       MIME media types and the WWW
       ...
       Section 14.11 gives the proper means of describing the HTTP
       transmission of a file which is already compressed

       The Content-Encoding entity-header field is used as a modifier
       to the media-type. When present, its value indicates what
       additional content codings have been applied to the entity-body,
       and thus what decoding mechanisms must be applied in order to
       obtain the media-type referenced by the Content-Type header field.
       Content-Encoding is primarily used to allow a document to be
       compressed without losing the identity of its underlying media
       type. Unfortunately it seems reasonably clear that Content-Encoding
       cannot be applied as if it were a MIME "Optional parameter" with the
       expectation that it could be used when transferring compressed files
       via e-mail. This observation is based upon section 19.4.4. It appears
       that a complete description of compressed files transmitted via e-mail
       requires a new RFC enhancing the MIME standard.
    
    https://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.4.4

        19.4.4 Introduction of Content-Encoding

        RFC 2045 does not include any concept equivalent to HTTP/1.1's
        Content-Encoding header field. Since this acts as a modifier on
        the media type, proxies and gateways from HTTP to MIME-compliant
        protocols MUST either change the value of the Content-Type header
        field or decode the entity-body before forwarding the message.
        (Some experimental applications of Content-Type for Internet mail
        have used a media-type parameter of ";conversions=<content-coding>"
        to perform a function equivalent to Content-Encoding. However, this
        parameter is not part of RFC 2045.)

Thus, at the very least for HTTP, there should be just one media type,
and Content-Encoding should be used to signal compression.  For email,
since we're introducing a new "multipart/report" subtype, and "Content-Encoding"
is not a standard MIME header, an appropriate media-type parameter (what
I earlier referred to as MIME "attribute") should be defined for
"application/tlsrpt".  It could be the above "; conversions=gzip" or
something similar.  The "application/tlsrpt" being a new media type,
you're free to define appropriate additional metadata.

> Yes, I believe Chris asked for that change.  I'd have to check list history.

A reference to a document that defines such syntax would
be helpful.  It just looked confusing to me...

> I believe this was at the request of the WG Chairs.  I'd have to go back through history to verify this.

Please do.  Keep in mind that absent a "Content-Encoding" header, one
should indeed specify that the content is compressed by means other
than a filename (which I argue should not be present at all).  However,
the solution as I see it is to employ the already defined for this
purpose "Content-Encoding" header (with HTTP, and a new media-type
parameter for MIME email) and avoid a separate media type for
compressed JSON reports.

> If the filename/subject disagree with the report, then the report is the authoritative source.

That's much simpler and clearer than the current text.  Of
course no "filename" should be used to convey *any* structured
information about the report, indeed a filename should be
entirely optional (unspecified in this draft).

Like the optional filename, the subject should be for human
consumption only.  A suggested subject does make it easier
for reports from multiple sources to stand out as such at a
glance, when the "rua" email address is for a human postmaster
and lands in a general-purpose (personal?) mailbox.

Solely as a *convenience* to a human postmaster, the only
structured data that might be appropriate to include as
part of an optinal filename would be a ".gz" or a ".txt.gz"
suffix to make it easier for postmasters to save reports
that land in their mailbox.  The rest of any filename
should be uninterpreted opaque data, and it could simply
be "tlsrpt.txt" or "tlsrpt.gz", but again for convenience
it *may* be friendlier to include a date:

	tlsrpt-20171206.txt
	tlsrpt-20171206.txt.gz

Whether or where the recipient saves such reports in some
filesystem is entirely at the recipient's discretion.

-- 
	Viktor.

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 15 Dec 2017 16:46:10 +0300

Hi,

a few comments are below.

> >> Unfortunately, failure to resolve TLSA records is not yet always a result of a broader DNS outage.  A small
> fraction of systems have nameservers that are either behind firewalls which implement misguided filtering of
> queries by RRtype (blocking TLSA and other "unusual"
> > This seems to be a different type of operation issue.  If an admin can never resolve a TLSA record from an
> external site, there may be larger issues going on.  We can alter/remove the sentence, but I don't think it will
> change the frequency of those types reports.

I think this sentence can be deleted, since what is really "rare" is highly personal and subjective.

> >> We could perhaps add a "dane-required" failure mode for cases where DANE is mandatory (by mutual
> agreement perhaps), but then the receiving domain's TLSA records (really the records for the underlying MX
> hosts) are unexpectedly removed, or become "insecure" if DNSSEC is disabled (DS records removed from
> parent zone).
> >

Victor, can you please provide a new text?

> "kebab-case" identifiers.

While having this feature would be nice, I don't think it justifies changing the document.
Note that RFC7469, from which this schema was derived, also uses "kebab" style.

> >> includes only the "receiving-mx-hostname" and not its IP address.  Some sites have multiple hosts behind a
> single name, e.g. sometimes the IPv4 address for mail.example.com lands on a different machine than the
> IPv6 address for the same name (and indeed they present different certificate chains, ...).  Leaving out the
> address might make it more difficult to identify the problem receiving machine.  Perhaps the intention here is
> that receiving systems should make an effort to assign different "receiving-mx-helo" names in such to
> disambiguate these cases?  If so, perhaps that should be mentioned in the text.
> >
> > We can add this, though, in the case of a front-end VIP, you're going to have the same target IP in many
> stanzas.  I understand the rationale, just wonder how useful it will be in the end.
> 

I think this makes sense.

> >> It should be more clear whether the "TLSA:" prefix is part of of the string (I believe it is not), and what the
> pair of consecutive double quotes is about, and how multiple TLSA records are represented.  The JSON policy
> includes "\n" separators (which JSON maps to actual newlines), are TLSA records to be separated with similar
> logical newlines?
> >>
> >>  _25._tcp.mx.example.com. IN TLSA ( 3 0 1
> 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D7 47D1D085D)
> >>
> >>   _25._tcp.mx.example.com. 3 0 1
> 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D747D1D085D
> >>
> >> with the implied "IN TLSA" and "(" ")" removed, and the hex data presented without any internal
> whitespace.  With that simplified it remains only to specify clearly how present a complete TLSA RRset.
> >
> > The intent was to have the record and the result.  Your changes are acceptable, and we can make the
> alterations.    In the case of multiple record results, how would you like that to be displayed?  Separated with a
> semicolon is sufficient I would think.  We'll firm up the examples.
> 

Can you please provide an alternate format?

> MIME attributes of the media type.

I tend to agree.

> you're free to define appropriate additional metadata.

Again, can you please provide a text?

Regards,
Valery.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 18 Dec 2017 03:01:37 +0000

On Fri, Dec 15, 2017 at 04:46:10PM +0300, Valery Smyslov wrote:

> > >>      It should be noted that
> > >> ..., the "may be rare" sentence should I think be deleted.
>

Thanks.  I hope the draft will be amended accordingly.

> Vi[ck]tor, can you please provide a new text?

   o "dane-required": This indicates that the sending system is
     configured to require DANE TLSA records for all the MX hosts
     of the destination domain, but no DNSSEC-validated TLSA records
     were present for the MX host that is the subject of the report.
     Mandatory DANE for SMTP is described in section 6 of RFC7672.
     Such policies may be created by mutual agreement between two
     organizations that frequently exchange sensitive content via
     email.

> I think this makes sense.

Thanks, so I would like to see the IP address (v4 or v6, the type
should be clear from the address syntax) added to the report schema.

> Can you please provide an alternate format?

I don't have cycles to draft a more formal grammar, but it should be
done.  The TLSA part should be a JSON encoding of the RData of the
MX host's TLSA RRSet in the form:

	_25._tcp.smtp.example.com 3 1 1 <sha256-digest><NEWLINE>
	_25._tcp.smtp.example.com 2 1 1 <sha256-digest><NEWLINE>

The name on each line should be the QNAME from the question section
of the DNS query that elicited the TLSA records, that is, "_25._tcp."
prefixed to the "TLSA base domain".  When that name is an alias,
the actual answer TLSA RRset may have a different "owner", but the
report should convey the initial QNAME.  A JSON encoding of this
"policy-string" will be something like:

    "_25._tcp.smtp.example.com 3 1 1 <sha256-digest>\n_25._tcp.smtp.example.com 2 1 1 <sha256-digest>\n"

Mind you, a more natural form might be not "policy-string", but rather

	"policy-records":
	    [ "_25._tcp.smtp.example.com 3 1 1 <sha256-digest>"
	    , "_25._tcp.smtp.example.com 3 1 1 <sha256-digest>"
	    ]

which would probably also be a good fit for STS policies as well.
So it probably makes more sense to switch to that than invent some
in-string record separator/terminator.

> > MIME attributes of the media type.

Anyone else?

> Again, can you please provide a text?

No, but I don't think it is much to ask from the draft authors.
The text can describe:

	Content-Type: application/tlsrpt; conversions=gzip
	Content-Type: application/tlsrpt; conversions=none
	Content-Type: application/tlsrpt

with the last form implicitly equivalent to the second.

-- 
	Viktor.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 18 Dec 2017 14:23:15 +0100

<snip>

> MX host's TLSA RRSet in the form:

Victor - this draft has passed WGLC and since you're the only one who
has (so far) raised a requirement for a formal syntax here, so unless
you or somebody provides concrete suggestions *and* there is clear WG
support for the change, we are not going to spend more time on this.

This does not *exclude* making further change but we are past the
time for open-ended discussions about this document.

<snip>

> No, but I don't think it is much to ask from the draft authors.

cf my comments above.

	Cheers Leif

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 18 Dec 2017 10:50:13 -0500

> On Dec 18, 2017, at 8:23 AM, Leif Johansson <[email-masked]> wrote:
> 

My hope is that the authors/editors will recognize the defect and
make the necessary changes.  The current syntax (of the "policy-string"
element) is under-specified.  It contains just a vague example.
So the original actual intent is unclear.  At the very least the
original intent should be more specific.

This is an esoteric topic, I don't expect that very many others
did a close reading of the document.  I am sorry I got to it
somewhat late, but it is not a published RFC yet, and I hope
that bug-fixes are still possible.

Perhaps one of the authors is willing to propose a more
explicit grammar.

The "policy-string" should be machine-readable, and therefore
should have an explicit syntax.

-- 
-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 18 Dec 2017 11:04:59 -0500

> On Dec 18, 2017, at 10:50 AM, Viktor Dukhovni <[email-masked]> wrote:
> 

If one or more of the authors/editors are willing to do some
rapid iterations on final changes, I promise to provide feedback
in near-real-time to get through this quickly.

-- 
	Viktor.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 18 Dec 2017 17:42:35 +0100

> that bug-fixes are still possible.

Certainly we can do changes to the document but the IETF consensus
process depends on multiple people making their voices heard - this
is the rough part of "rough consensus and running code". Sometimes
under-specified is actually good enough.

As somebody who implements specifications I totally sympathize with
your desire to have a specification that is as specific as possible...

However as chair, the later in the process we get the more I'm going
to insist on putting "pen to paper" in order to progress the document.

	Cheers Leif

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 18 Dec 2017 15:52:03 -0500

> On Dec 18, 2017, at 11:42 AM, Leif Johansson <[email-masked]> wrote:
> 

I am sympathetic to your perspective, and indeed an effective chair is
one who moves ready documents along, fending off spurious late changes.

However, in this case, I think we have a situation in which despite
appearances the document is not actually ready.  There were not enough
eyeballs to make all the bugs shallow.

   * The MIME issues should be resolved, and there should not be any
     semantics associated with any optional "filename" for the report.
     The requisite metadata should be explicit in the Content-Type
     and (in the case of HTTP) Content-Encoding.  The Content-Disposition
     (where any optional filenames lives) should be entirely optional.

   * The "policy-string" is poorly specified, the below:

      o  "policy-string": A string representation of the policy, whether
         TLSA record ([RFC6698] section 2.3) or MTA-STS policy.  Examples:
         TLSA: ""_25._tcp.mx.example.com.  IN TLSA ( 3 0 1 \
         1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D7 47D1D085D
         )"" MTA-STS: ""version: STSv1\nmode: report\nmx:
         mx1.example.com\nmx: \ mx2.example.com\nmx: mx.backup-
         example.com\nmax_age: 12345678""

     is not a sound way to specify the format, and JSON has array types,
     that obviate the need to "stringify" record-oriented data.  As I
     already mentioned, the exammple TLSA syntax carries needless extra
     syntax that just makes parsing more difficult.  Since the TLSA base
     domain is potentially subject to CNAME expansion, there needs to
     be text that asks the sender to specify the QNAME used to locate
     the TLSA RRset.

     I did suggest a better format for the policy string, though not a BNF
     grammar, but I think that the final step is easy enough.

   * I provided suggested text for "dane-required".

   * The IP address of the MX host should be included in the report schema.

-- 
	Viktor.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 18 Dec 2017 23:58:38 +0100

> one who moves ready documents along, fending off spurious late changes.

Great. I suggest we spend the time reading and reviewing specific text
instead of spending additional time re-iterating "bugreports".

Putting some words together is arguably less work than you're spending
arguing that they are necessary :-)

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 19 Dec 2017 22:14:39 -0500

> On Dec 18, 2017, at 5:58 PM, Leif Johansson <[email-masked]> wrote:
> 

I will allocate some time to work with Alex to draft the requisite
changes...

-- 
	Viktor.

---

From: Leif Johansson <[email-masked]>
Date: Wed, 20 Dec 2017 11:29:37 +0100

> I will allocate some time to work with Alex to draft the requisite

Great!