On Fri, Dec 15, 2017 at 04:46:10PM +0300, Valery Smyslov wrote:
> > >> 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.
> > >>
> > >> ..., the "may be rare" sentence should I think be deleted.
>
> I think this sentence can be deleted, since what is really "rare" is highly
> personal and subjective.
Thanks. I hope the draft will be amended accordingly.
> > >> 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.
> >
> > 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".
>
> 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.
> > 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.
>
> 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.
> > 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?
>
> 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.
> > 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.
>
> I tend to agree.
Anyone else?
> > 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.
>
> 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.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
