Hi,
a few comments are below.
> >> "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.
> >
> > 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).
> >
> > 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".
Victor, can you please provide a new text?
> >> 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.
>
> 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.
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.
> >> 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.
> >
> > 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.
I think this makes sense.
> >> 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.
> >
> > 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.
>
> 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?
Can you please provide an alternate format?
> >> 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.
>
> 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.
> >> 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.
>
> 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.
Again, can you please provide a text?
Regards,
Valery.
>
> --
> Viktor.
>
> _______________________________________________
> Uta mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
