Subject: [dane] AD review of draft-ietf-dane-smime-14

From: Stephen Farrell <[email-masked]>
Date: Tue, 7 Feb 2017 16:12:57 +0000

Hi,

I've done my AD review of this draft. My own comments
on the content are below (the one I'd most like to
see fixed is the "escrow" stuff) and are ok to be
handled along with other IETF LC comments.

However, before I start IETF LC I would like to be
sure that the WG are ok with the IPR declaration [1]
filed in 2014 that said "Licensing Declaration to
be Provided Later." I think 2017 is "later" enough
to ask whether that the WG (via the chairs) explicitly
declare that they are ok that this has yet to be
clarified.

Cheers,
S.

[1] https://datatracker.ietf.org/ipr/2468/

- abstract: Someone will want DANE expanded. Better to avoid
the acronym maybe.

- intro: "Some people want..." is odd - that is not a
technical justification and the entire paragraph is not that
convincing.  I'd say deleting that para would be better. Or
add a real justification for the experiment which I think
relates more to attempting to mitigate the difficulty of
finding certs from outside the enterprise than anything else.

- intro: I'd suggest adding a sentence about how this is
similar to RFC7929. As a reader, I'd find it odd to only find
that out later.

- section 3: This is the same idea as in RFC 7929 right?
(Other than _smimecert I mean,) If so then saying so is right
as it'll help with IETF LC and IESG review and for
developers. If those differ, then saying how and why I think
would be needed.

- section 4: Please check whether this is all fine when also
considering draft-ietf-lamps-eai-addresses (also in IETF LC).
That check may need to wait a little bit until we're done
with the LC comment handling for the LAMPS deraft.

- Section 9: the discussion of an MTA doing the outbound
encryption seems a bit theoretical - I don't recall that
being dnoe in reality except maybe in very special cases like
nested smime, or military messaging. Am I wrong about that?

- section 9: I think the text about escrow would be better
after the current last para (where you call out the danger of
bad public keys being put in the DNS), and this (escrow)
ought be described as a special case of that attack, where
the attacker is the organisation itself. (While there are
cases where the organisation doing this is not intended as an
attack, were it done for most DNS names, it would mostly be
an attack, and is not distinguishable from an attack for the
sender, so therefore it ought IMO be considered an attack.)

- section 9: s/MUST not/MUST NOT/ or I-D nits complains

- section 11: I-D nits complains, maybe calling this
"normative references" would help, but in any case, please
consider/fix this.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 8 Feb 2017 09:22:12 -0500 (EST)

> [1] https://datatracker.ietf.org/ipr/2468/

The patent is dated 11-27-2013.

The first openpgpkey draft is dated July 15, 2013.
https://tools.ietf.org/html/draft-wouters-dane-openpgp-00

The patent is also completely unrelated to email, and instead mumbles
about using DNSSEC to publish policy for public consumption.

Fortunately, we have the whole origin of DNSSEC and the FreeS/WAN team
with John Gilmore and Hugh Daniel predating that idea to about 1995 and
earlier. In fact, half the people working on DNSSEC 25 years ago had as
_goal_ to use DNSSEC as a PKI to publish policy and I'm sure the heated
namedroppers archive will show that this patent application is absolute
bullshit and Verisign and the authors should be ashamed of such lame
attempts at "inventing".

And the worst is, they weren't even the first to do this. There are
also the patents of Thierry Moreau of Connotech who threatened me
back in 2007 with lawsuits when he warned IETF he had similar broad
patents of having invented using DNSSEC for something non-DNS.

So yeah, I think the WG can safely ignore this nonsense, and if anyone
is ever approached by Verisign for illegal use of their patent, do
contact me to provide you with an expert witness statement.

Paul

---

From: "John Levine" <[email-masked]>
Date: 8 Feb 2017 15:03:20 -0000

>The patent is dated 11-27-2013.

It's not a patent, it's a patent application, and if you read the
first page of the application, it claims priority from a provisional
application dated March 15, 2013, which is earlier than July.

>about using DNSSEC to publish policy for public consumption.

You might want to reread the application.  If you say that a S/MIME
certificate expresses policies, which is not much of a stretch in
patent-ese, then this applies directly to publishing a bunch of DNSSEC
signed certificates.

I agree that the application is pretty weak, and there is probably
lots of prior art, but I'd also note that an e-mail message from long
ago saying that one wanted to do something is not necessarily prior
art if you can't show that someone actually did it.  I would also note
that it is an application, not a patent, and many, perhaps most,
applications never turn into patents.  But it's definitely relevant.

FYI, there are also patent applications pending in Europe and China.

R's,
John

---

From: Paul Wouters <[email-masked]>
Date: Wed, 8 Feb 2017 10:25:39 -0500 (EST)

> application dated March 15, 2013, which is earlier than July.

https://www.mail-archive.com/[email-masked]/msg00272.html

Nov 2012.

https://tools.ietf.org/html/draft-fanf-dane-mua-00

June 27, 2012.

> patent-ese, then this applies directly to publishing a bunch of DNSSEC

We seem to agree the patent application is not specific to email and
thus only affects the smime draft based on its very generic concept.

> applications never turn into patents.  But it's definitely relevant.

https://tools.ietf.org/html/draft-ietf-ipseckey-rr-00

Published March 30, 2003

Although the implementation predates even that:

http://www.freeswan.org/oldnews.html

2001/06/22

     We would like to announce that the Linux FreeS/WAN project has now
     released version 1.91 of our IPSEC system.

      The BIG news for the 1.91 release is that you can now begin to use
      Opportunistic Encryption!

> FYI, there are also patent applications pending in Europe and China.

Still not impressed. This whole exercise is a waste of everyone's time
and Verisign should just put a stop to it.

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 8 Feb 2017 20:40:01 +0000

Hiya,

On 08/02/17 15:25, Paul Wouters wrote:
> Still not impressed.

While I may well agree, that doesn't answer my question,
which doesn't relate to the application itself but to
the IPR declaration's statement that licensing information
will be provided "later."

Cheers,
S.

---

From: "John Levine" <[email-masked]>
Date: 9 Feb 2017 04:17:39 -0000

>will be provided "later."

I agree with Paul that it's a lousy application, and I think that more
likely than not it'll be abandoned with no patents granted.  But if
any of the three applications (US, EU, China) turned into actual
patents, and Verisign were to require a license that cost money, or
that was otherwise incompatible with open source implementations, that
would be a problem.

I see that Verisign has offered a free-unless-you-sue-us license for
other patent applications, like this one, dunno why they do for some
but not others:

https://datatracker.ietf.org/ipr/2703/

In any event, you alrady know what my suggested solution is.

R's,
John

---

From: Marc Groeneweg <[email-masked]>
Date: Fri, 10 Feb 2017 14:28:06 +0000

>>will be provided "later."
As we had with the keyrelay draft in regext (and the draft of Peter Koch with DNSSEC transfers).
    
<SNAP/>
    
>    https://datatracker.ietf.org/ipr/2703/
Other than that the suggested draft is also by Verisign themselves?

> In any event, you alrady know what my suggested solution is.

Regards,
Marc

---

From: Warren Kumari <[email-masked]>
Date: Sun, 12 Feb 2017 17:27:00 -0500

> As we had with the keyrelay draft in regext (and the draft of Peter Koch with DNSSEC transfers).

Can you remind us what ended up happening with those two? I vaguely
remember some discussion about it being hard to get a commitment, and
that "later" seemed like a DoS on the process, but was there ever a
resolution?

Is the WG OK with this, or do you feel that we need to try and get the
IPR statement updated? (Remembering that, AFAIK, we cannot do anything
other than ask nicely...)

W

> _______________________________________________
> dane mailing list
> [email-masked]
> 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

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 12 Feb 2017 22:31:17 +0000

Hiya,

On 12/02/17 22:27, Warren Kumari wrote:
>  do you feel that we need to try and get the
> IPR statement updated? 

I not sure but if that question is addressed at me, then I
am not trying to insist that the IPR declaration be updated,
but just want to check that the WG are ok with that "later"
statement, despite it now being "much later."

> (Remembering that, AFAIK, we cannot do anything

Yep. We can't force anyone to update a declaration and as
noted there was at least one other case where a year went
by with folks asking and not seeing any update happen in
a quite similar case involving the same entity.

S.

---

From: Warren Kumari <[email-masked]>
Date: Sun, 12 Feb 2017 20:50:15 -0500

> statement, despite it now being "much later."

Sorry, nope, that was directed at the WG...

I personally think that this is "OK" -- not great, but....

> a quite similar case involving the same entity.

Yup.
W

---

From: D S Misell <[email-masked]>
Date: Mon, 13 Feb 2017 02:04:13 +0000

warren,

Mire give the same problem surely
Yours Faithfully,

David S. Misell MIET MBCS CISSP

Skype misell.dave
+44(0)7710380044
0207 7239135
Http://linkedin.com/in/misell
  Box https://db.tt/ncfgMm3J

---

From: D S Misell <[email-masked]>
Date: Mon, 13 Feb 2017 02:10:21 +0000

warren,

Mitre give the same problem surely.

Yours Faithfully,

Skype misell.dave
+44(0)7710380044
0207 7239135

---

From: Warren Kumari <[email-masked]>
Date: Mon, 13 Feb 2017 12:32:44 -0500

Dear WG.

Unless you explicitly let us know that you are NOT OK with the current
IPR declaration ( https://datatracker.ietf.org/ipr/2468/ ) by
Thursday, we will be progressing the document.
Personally I'm not thrilled with the situation, but I don't really
think there is anything we can do about it...

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 13 Feb 2017 17:29:49 -0800

> handled along with other IETF LC comments.

We decided to take these on now, before the IETF LC.

> declare that they are ok that this has yet to be

Warren has stated the question explicitly, and we await the response.

--Paul and Jakob

======================================================================

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the DNS-based Authentication of Named 
Entities of the IETF.

         Title           : Using Secure DNS to Associate Certificates 
with Domain Names For S/MIME
         Authors         : Paul Hoffman
                           Jakob Schlyter
	Filename        : draft-ietf-dane-smime-15.txt
	Pages           : 11
	Date            : 2017-02-13

Abstract:
    This document describes how to use secure DNS to associate an S/MIME
    user's certificate with the intended domain name, similar to the way
    that DNS-Based Authentication of Named Entities (DANE), RFC 6698,
    does for TLS.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dane-smime/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dane-smime-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smime-15

======================================================================

> - abstract: Someone will want DANE expanded. Better to avoid

Done.

> finding certs from outside the enterprise than anything else.

Many people here liked the justification, but we agree that your 
justification is a good one as well. Added.

> similar to RFC7929. As a reader, I'd find it odd to only find

Done.

> developers. If those differ, then saying how and why I think

Done.

> with the LC comment handling for the LAMPS deraft.

The current text is "all fine" with the LAMPS draft.

> nested smime, or military messaging. Am I wrong about that?

Yes, you are. There have been products doing this for many years 
(possibly more than a decade). Having said that...

> sender, so therefore it ought IMO be considered an attack.)

Yes, good call. Done.

> - section 9: s/MUST not/MUST NOT/ or I-D nits complains

And we must keep the tool happy, mustn't we? Done.

> "normative references" would help, but in any case, please

The tool is wrong, but we can fix it easily anyhow. Done.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Feb 2017 01:33:59 +0000

> We decided to take these on now, before the IETF LC.

And for the record, I'm fine with those changes. (Though
a grammar fix may be needed, that can be done later.)

Thanks,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 Feb 2017 17:02:23 +0000

Hiya,

Thanks for checking. As I didn't see any objections, I've
asked for IETF LC to be started.

Cheers,
S.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 17 Feb 2017 12:03:16 -0500

Thank you.
W