Re: [dane] Review of DANE SMTP draft

[Alexey Melnikov <[e-mail]>]

Hi Victor,

> On 14 Mar 2014, at 17:41, Viktor Dukhovni <[e-mail]> wrote:
> 
> 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.

Ok, after thinking more about this, your current text looks Ok as is.
> 
>>> 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.

RFC 6125 allows for that, so I see no conflict.
> 
>>> 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?

Yes.

> Or SMTP support multi-label wildcards?

I suppose this might be another reasonable outcome, if we can get IETF consensus on this.