On Thu, Jan 29, 2015 at 10:43 AM, Sean Turner <[email protected]> wrote: > On Jan 22, 2015, at 17:08, Viktor Dukhovni <[email protected]> wrote: > >> 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. > > Multiple drafts can update one draft so if you want to save time you can just > add > "Updates: 6698 (once approved)" to the header of both drafts and you’d be > procedurally covered. Well I guess technically, you need to also say “This > draft updates RFC 6698” or something like that in the abstract of the nits > checker will complain. > >>> 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. > > Nope that’ll work. > >>> 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. > > I re-read it leave it as is. > >>> 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. > > Yeah just moving some words. > >>> 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? > > I think doing it here is fine. There might be other places we’d also do it, > but here I think is a fine place to start. > >>> 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. > > This is good to know and personally I’m fine with it. I wonder if the mail > folks won’t come unglued about this though because it’s imposing some kind of > requirements on the MTA. But, let’s see what they say before we try to > second guess what might make it through. > >>> 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. > > I guess we’ll see ;) > >>> 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? > > Since we’re changing at least one 2119 keyword, I guess I’d go ahead and spin > a new version before IETF LC - but that’s really up to the chairs.
... and I'd like to apologize for us not having actually called this / answered any of the requests for guidance / actually done anything. We have been stupidly busy recently (in related news: https://blog.cloudflare.com/help-us-test-our-dnssec-implementation/) , and I've been owing Olafur a call back for a few weeks now. We (the chairs and our AD) are planning a call in the next few days to discuss how to make sure we keep things moving... Y'all (DANE) deserve better and we are working on making that happen... W > > spt > >> -- >> Viktor. >> >> _______________________________________________ >> dane mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dane > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
