Re: [dane] WGLC: DANE-SRV & DANE-SMTP

[Viktor Dukhovni <[e-mail]>]

On Thu, Jan 22, 2015 at 04:23:36PM -0500, Sean Turner wrote:

> This is procedural but I guess it's major:
> 
> Am I right that this draft is using the new definition for DANE-EE
> that is documented in draft-ietf-dane-ops?  Don't we have to wait
> for it to update RFC 6698 or does this specification have to indicate
> that it updates RFC 6698?

Indeed the semantics of DANE-EE(3) are the same in both the ops
and smtp-with-dane drafts.

The ops draft ammends the semantics for all use-cases of the TLSA
record by updating 6698.  The smtp-with-dane draft makes the same
change only for opportunistic DANE TLS used in MTA to MTA SMTP.

The history is that the decision to turn the ops draft into a 6698
update happened rather late, and until that time, only the smtp
draft had the requisite normative language.

I don't know to best deal with this procedurally.  One might say
that both drafts update 6698, or that only the ops draft does that,
and the smtp draft applies just narrowly to the protocol at hand.

I don't have any views on the logistics.

> 0) s1.1, delayed delivery: r/When an MTA is unable forward/When an MTA is to unable forward

    Muphry bites, but I know what you mean thanks.

> 1) s1.1, delayed delivery: Might be good to have a forward
> reference to "mandatory DANE TLS" in the later section or add it
> as a definition in s1.1.

I'll add a forward reference, unless there is good reason to extend
the terminology.

> 2) s1.1: Couldn?t hurt to have informative references to DNS RR and RRSet.

Sure.

> 3) s1.2: r/Certificate Authority/Certification Authority

Indeed, I thought I fixed all of those...

> 4) s1.3.2: r/and requiring/and require

This is a rather long sentence, but its high level
structure is:

    One might try to ... by using ... and requiring ...

So I think that "requiring" agrees better with the
preceding parts.  It might be clearer with an
extra "by":

    One might try to ... by using ... and by requiring ...

Or a rewrite of the whole sentence.

> 5) s1.3.3: What I think you're trying to say here:
> 
>  Sending systems are in some cases explicitly configured to use TLS
>  for mail sent to selected peer domains.   This requires sending MTAs
>  to be configured with appropriate subject names or certificate
>  content digests to expect in the presented server certificates.
> 
> is this:
> 
>  Sending systems are in some cases explicitly configured to use TLS
>  for mail sent to selected peer domains, but this requires configuring
>  sending MTAs with appropriate subject names or certificate
>  content digests from their peer domains.

These looks largely the same to me, your version is fine too.

> 6) s2.1.3: I think if we're going to have a "MUST NOT" for
> something it's probably worth a pointer to the definition in RFC
> 4033 for "Security-Oblivious stub-resolvers? or add it to s1.1 and
> point to RFC 4033.

Makese sense.  The larger question is whether this is really the
right place for a MUST NOT.  If the client gets this wrong it is
insecure (never sees any "secure" domains and never uses DANE),
but it is still interoperable.  What's the right way to tell clients
that they don't get any security if their recursor is oblivious?

> 7) s2.2.1: The text about MTA delivery logs made me wonder where
> the rest of the normative behavior is for MTA delivery logs and
> whether this text is updating that text.

I don't think there is any such text anywhere else.  The closest
you'll find is "no misrepresentation of security" in RFC 7435
(opportunistic security) of which this is an instance.

> 8) s3.1: Should this be "RECOMMEND":
> 
>   In summary, we recommend the use of either "DANE-EE(3) SPKI(1)
>   SHA2-256(1)" or "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records
>   depending on site needs.

Sure, if there are no objections.

> 9) s3.1: Maybe reword:
> 
>  The mandatory to support digest algorithm in [RFC6698] is
>  SHA2-256(1)
>
> to: 
> 
>  As specified in [RFC6698], the mandatory to implement digest
>  algorithm is SHA2-256(1).

Yes.

> 10) s3.2.3: r/must be entire/must be the entire 

Yes.

When should the suggested changes be made?

-- 
	Viktor.