On Fri, Mar 14, 2014 at 05:15:37PM +0000, Alexey Melnikov wrote:
> >[ Second-last paragraph of 2.2 ]
> >
> >Is it not obvious that this means the misguided:
> >
> > example.com. IN MX 0 192.0.2.1.
>
> No, it is not obvious, otherwise I wouldn't have asked.
The original sentence reads:
Similarly, when an MX RRset incorrectly lists a network address in
lieu of an MX hostname, if the MTA chooses to connect to the network
address, DANE TLSA does not apply for such a connection.
Anyone else feel this deserves an example? There are some poor
sods who attempt to stuff IPv4 addresses into MX hostname RRDATA,
and some MTAs may do them a favour and handle this broken syntax.
In that case DANE is clearly out of scope.
> >In 6125 (where the exceptions dominate the rules) there are no
> >provisions for matching one of a set of candidate names.
>
> I am not sure I understand. If there are multiple subjectAltName
> values of the same type, any match works. Unless you mean something
> else.
No, the SMTP and SRV drafts specify that the client has multiple
names it is willing to accept, any one of which may match one of
the many SAN names in the peer certificate. There can be up to
three names. The original name before redirection by MX or SRV,
the securely CNAME expanded version of that if different, and
finally the TLSA base domain of the server.
> >I don't know whether the Postfix (on by default) Postini work-around
> >deserves IETF blessing. Perhaps it would be better for Postini to
> >fix their certificates,
>
> I think so, yes.
That is Postini fix their mess? Or SMTP support multi-label
wildcards?
> >RFC 6066 is referenced on page 6 (second last paragraph) and appears
> >in the References section. Should the reference be repeated on
> >page 22?
>
> In general, I prefer when references are repeated.
We can do that. There is clearly sufficient distance between page
6, and page 22, for the reference not to appear repetitive.
> >>In 2.3.3: it is not clear whether the client needs to check that for every
> >>record covered by the WORSE hash there is a corresponding record covered
> >>by the BETTER hash.
> >
> >This is not possible. The records don't carry separate "instance"
> >identifiers that allow one to identify all the TLSA records of a
> >single certificate or public key. The various digest algorithms
> >are not invertible! All that the client can check is that the
> >number of records for the best algorithm is the same as that for
> >all other algorithms within each combination of usage and selector.
>
> I think your current text can be misinterpreted that such validation
> is allowed. Use of normative language didn't help. I think I
> interpreted some of the requirements as applying to SMTP clients,
> where they applied to ISPs.
What do you mean by "such validation is allowed"? Would you mind
starting a new thread with questions specifically about the digest
agility part of the SMTP draft? This mechanism is not intended to
be SMTP-specific, and should some day make it into DANEbis via the
SRV draft as a first hop perhaps (unless it should be its own
stand-alone draft on just digest agility for DANE).
> >>I've heard Not checking expiration dates in certificate - I don't think
> >>this was mentioned in the document.
> >>
> >This is in the "ops" draft, but I'll add it to the description in
> >the SMTP draft, after we figure out exactly what should be ignored
> >in DANE-EE(3) certs (and possibly DANE-TA(2) SPKI(1) trust anchor
> >certs). (Separate thread on this soon).
>
> Ok. If you are departing from RFC 5280, they you should state all
> new requirements.
Yes.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
