Subject: [dane] Working group Last call: draft-ietf-dane-smime-11.txt

From: Olafur Gudmundsson <[email-masked]>
Date: Sat, 9 Jul 2016 12:53:18 -0400

Dear Colleagues 

The editors of https://datatracker.ietf.org/doc/draft-ietf-dane-smime/ <https://datatracker.ietf.org/doc/draft-ietf-dane-smime/> have requested a WGLC, 
the chairs are satisfied that the document is in good shape. This message starts a three week WG LC, 
that concludes on Monday July 25 23:59 UTC (we have extended the
usual 2 weeks because of the upcoming meeting, travel, etc).

This document is on the Experimental track, it is a close relative of a prior document from our group
https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ <https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/>  which is in AUTH-48 at this point. 
Any discussions on “local part” other than to point out a difference between the OPENPGP document and this one are 
out of scope. 

Any other issues should be brought forward 

thanks 
  Olafur & Warren

---

From: "John Levine" <[email-masked]>
Date: 9 Jul 2016 18:15:18 -0000

>Any other issues should be brought forward 

Section 3 says:

      If the local-part contains any non-ASCII characters, it SHOULD be
      normalized using the Unicode Normalization Form C from
      [Unicode52].

but section 4 says:

   Therefor, sending MUAs and MTAs supporting this
   specification MUST NOT perform any kind of mapping rules based on the
   email address.

Section 3 is wrong -- when RFC5321 says that local parts are opaque,
it means it. RFCs 6530 through 6532 deliberately did not provide any
advice on canonicalizing UTF-8 local parts, and it's inappropriate to
do it here.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 9 Jul 2016 18:24:28 -0000

>Any other issues should be brought forward 

Also, I see that there's a disclaimer about the semantics of
the certificates, but I'm still confused.

At this point, all S/MIME certificates are signed by a CA, and MUAs
typically put ugly red marks on message with a cert with an unknown CA.

I gather the idea here is that the certs can be self-signed, and
they're credible in the absence of a CA signature because the domain
is asserting something about them via DNSSEC publication.  But it
never says that, or anything like that.

R's,
John

---

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 09 Jul 2016 11:40:37 -0700

On 9 Jul 2016, at 11:15, John Levine wrote:

> Section 3 is wrong

The wording in this draft matches the wording in 
draft-ietf-dane-openpgpkey that has IETF consensus. Get over it.

--Paul Hoffman

---

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 09 Jul 2016 11:46:34 -0700

> never says that, or anything like that.

I have not done a recent survey of MUAs with S/MIME support and 
self-signed PKIX certs, but when I did an informal survey in the past, 
most of them supported a similar interface to the browsers at the time 
with a layer of "are you really sure you want to do that" followed by 
"OK, you did that" and it worked. We have no idea how they will change 
with the introduction of DANE with SMIMEA records, but I would hope it 
would be even easier. If it turns out that none of the MUAs want that, 
that will be a really good indication of how this experiment is faring. 
(Ditto for the parallel features in OpenPGP with the new OPENPGPKEY 
record.)

--Paul Hoffman

---

From: "Patrik Fältström" <[email-masked]>
Date: Sat, 09 Jul 2016 22:35:37 +0200

On 9 Jul 2016, at 20:40, Paul Hoffman wrote:

> The wording in this draft matches the wording in draft-ietf-dane-openpgpkey that has IETF consensus. Get over it.

In practice, I would be surprised if not matching algorithms used do normalize to normalization form c and case folding before doing matching.

But, to be honest, I think the correct wording we will never know before we actually do have implementations, so lets beat this horse to death when we know what people actually have implemented.

And, FWIW, I have not implemented it. Just to make it clear.

   Patrik

---

From: Sean Leonard <[email-masked]>
Date: Sat, 9 Jul 2016 16:15:38 -0700

> advice on canonicalizing UTF-8 local parts, and it's inappropriate to

+1 to John's point. Remove the sentence in Section 3.

Regards,

Sean

---

From: Warren Kumari <[email-masked]>
Date: Mon, 11 Jul 2016 09:51:26 -0400

> that has IETF consensus. Get over it.

Yup. Much of the WG (including, I believe, both chairs and the authors
of both -smime and openpgp) does not like the consensus in
draft-ietf-dane-openpgpkey -- however, this was the consensus, and we
really don't need to relitigate it.

W

>
> --Paul Hoffman
>
>
> _______________________________________________
> 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: Warren Kumari <[email-masked]>
Date: Sun, 24 Jul 2016 17:06:51 -0400

Dear Everyone,

A reminder that this WGLC closes tomorrow -- so far we have not really
seen sufficient feedback on this document. PLEASE review this document
and provide comment.

I also wanted to make sure people (including the authors) had seen:
https://www.ietf.org/mail-archive/web/dane/current/msg08382.html

W

On Sat, Jul 9, 2016 at 12:53 PM, Olafur Gudmundsson <[email-masked]> wrote:
>
> Dear Colleagues
>
> The editors of https://datatracker.ietf.org/doc/draft-ietf-dane-smime/ have
> requested a WGLC,
> https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/  which is in
> AUTH-48 at this point.

---

From: "John Levine" <[email-masked]>
Date: 25 Jul 2016 09:31:57 -0000

>seen sufficient feedback on this document. PLEASE review this document

My opinion is the same as it's been all along: this draft is harmful
to the Internet and should not be published at all, as Experimental or
anything else.

I lost this argument on the PGP draft and don't expect to win it here,
but you asked, so that's the comment.

R's,
John

---

From: "Rose, Scott" <[email-masked]>
Date: Mon, 25 Jul 2016 08:08:48 -0400

I have read the document and while not perfect (what is in life?), I 
support its publication.

Scott

On 24 Jul 2016, at 17:06, Warren Kumari wrote:

>> The editors of 
>> https://datatracker.ietf.org/doc/draft-ietf-dane-smime/ have
>> requested a WGLC,
>> the chairs are satisfied that the document is in good shape. This 
>> message
>> starts a three week WG LC,
>> This document is on the Experimental track, it is a close relative of 
>> a
>> prior document from our group
>> Any discussions on “local part” other than to point out a 
>> difference between
>> the OPENPGP document and this one are
>> out of scope.
>>

==================================
Scott Rose, NIST
[email-masked]
ph: +1-301-975-8439
Google Voice: +1-571-249-3671

---

From: Paul Wouters <[email-masked]>
Date: Mon, 25 Jul 2016 09:33:18 -0400 (EDT)

> seen sufficient feedback on this document. PLEASE review this document

I have reviewed the document. I think it is ready for IETF LC but it
could see a few small changes:

It should probably update its reference in the introduction to list
soon to be RFC-7929 (openpgpkey) and wait on that doc (in AUTH48 now)
to go out first.

 	The SMIMEA resource record has no special TTL requirements.

During openpgpkey discussion, it was decided it was better to remove
this line. I would think the same applies to smime.

During openpgpkey discussion, people insisted on specifying the
"experimental goal" of the Experimental RFC. That section is missing
in this document.

Section 3's title is a bit long. In openpgpkey we used a shorter
title. I suggest "Location of the SMIMEA record".

The openpgpkey had updated the "tcp only" phrasing to make it more
layer agnostic and mentions DNS-COOKIES as a defense and method to
allow UDP. You might want to consider using the same approach instead
of banning UDP altogether.

> https://www.ietf.org/mail-archive/web/dane/current/msg08382.html

This has come up in the past when discussing SMIME. One suggestion was
to use a different prefix (like _encrypt. and _sign). When this was
brought up, the patent status of this was not entirely clear, and there
were privacy discussions raised on exposing queries to the purpose of
the query. Perhaps the document can state that if the certificate is
obtained via SMIMEA, it should be checked whether it is suitable for
the task to perform. And that publishers are encouraged to publish
SMIMEA records for certificates that allow both signing and encryption.
But this latter approach did not have a clear consensus.

Paul

---

From: Jim Schaad <[email-masked]>
Date: Mon, 25 Jul 2016 07:02:36 -0700

> -----Original Message-----
> From: dane [mailto:[email-masked]] On Behalf Of Paul Wouters
> Sent: Monday, July 25, 2016 6:33 AM
> To: Warren Kumari <[email-masked]>
> Cc: dane WG list <[email-masked]>
> Subject: Re: [dane] Working group Last call: draft-ietf-dane-smime-11.txt
> 
> I have reviewed the document. I think it is ready for IETF LC but it could see a
> few small changes:
> 
> It should probably update its reference in the introduction to list soon to be RFC-
> 7929 (openpgpkey) and wait on that doc (in AUTH48 now) to go out first.
> 
> During openpgpkey discussion, it was decided it was better to remove this line. I
> would think the same applies to smime.
> 
> During openpgpkey discussion, people insisted on specifying the "experimental
> goal" of the Experimental RFC. That section is missing in this document.
> 
> Section 3's title is a bit long. In openpgpkey we used a shorter title. I suggest
> "Location of the SMIMEA record".
> 
> The openpgpkey had updated the "tcp only" phrasing to make it more layer
> agnostic and mentions DNS-COOKIES as a defense and method to allow UDP.
> You might want to consider using the same approach instead of banning UDP
> altogether.
> 
> This has come up in the past when discussing SMIME. One suggestion was to use
> a different prefix (like _encrypt. and _sign). When this was brought up, the
> patent status of this was not entirely clear, and there were privacy discussions
> raised on exposing queries to the purpose of the query. Perhaps the document
> can state that if the certificate is obtained via SMIMEA, it should be checked
> whether it is suitable for the task to perform. And that publishers are
> encouraged to publish SMIMEA records for certificates that allow both signing
> and encryption.

This is not the issue that my message was designed to highlight.  In S/MIME it is possible to say which of the message formats and which content encryption algorithms are supported by a client.  This is not the same as designating if a certificate is being used for encryption or signing.

Jim

> >> requested a WGLC, the chairs are satisfied that the document is in
> >> good shape. This message starts a three week WG LC, that concludes on
> >> Monday July 25 23:59 UTC (we have extended the usual 2 weeks because
> >> of the upcoming meeting, travel, etc).
> >>
> >> a prior document from our group
> >> Any discussions on “local part” other than to point out a difference
> >> between the OPENPGP document and this one are out of scope.
> >>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 25 Jul 2016 17:38:05 -0400 (EDT)

> This is not the issue that my message was designed to highlight.  In S/MIME it is possible to say which of the message formats and which content encryption algorithms are supported by a client.  Th…

Oh I see. How is this "possible to say" ? If it is part of the S/MIME
certificate, wouldn't it be part of the SMIME record provided that
TLSA selector type 0 (full certificate)

If there are no commonly shared algorithms, perhaps only this type
should be supported?

Paul

---

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 31 Jul 2016 18:06:13 -0700

> soon to be RFC-7929 (openpgpkey) and wait on that doc (in AUTH48 now)

There is no need for that. The IESG can correlate them just fine.

> this line. I would think the same applies to smime.

Sorry, I missed that in my review of the openpgpkey document. I'll 
remove it for the next draft.

> "experimental goal" of the Experimental RFC. That section is missing

<sigh> Added.

> title. I suggest "Location of the SMIMEA record".

Done.

> of banning UDP altogether.

Done.

> But this latter approach did not have a clear consensus.

See the following message.

--Paul Hoffman

---

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 31 Jul 2016 18:08:11 -0700

On 25 Jul 2016, at 7:02, Jim Schaad wrote:

> This is not the issue that my message was designed to highlight.  In 
> S/MIME it is possible to say which of the message formats and which 
> content encryption algorithms are supported by a client.  This is not 
> the same as designating if a certificate is being used for encryption 
> or signing.

We will add a mention of RFC 4262 to the draft.

--Paul Hoffman