Subject: Re: [dane] Deferral of SMIME draft

From: "Wiley, Glen" <[email-masked]>
Date: Wed, 1 Jul 2015 10:59:36 +0000

Does this current thread provide enough evidence of interest to make
progress on the draft?

While there have been discussions about changes to the SMIME draft, is
there anything beyond reconciling the openpgpkey and smimea locating
approach that would be significant enough to warrant holding the draft up?
-- 
Glen Wiley

Principal Engineer
Verisign, Inc.
(571) 230-7917

http://vbsdcon.com

A5E5 E373 3C75 5B3E 2E24
6A0F DC65 2354 9946 C63A

On 6/30/15, 11:23 PM, "Paul Hoffman" <[email-masked]> wrote:

>On Jun 30, 2015, at 8:16 PM, Melinda Shore <[email-masked]>
>wrote:
>> On 6/30/15 6:51 PM, Paul Wouters wrote:
>>> I actually also do not really understand the decision, other than the
>>> authors seeing a hot potato. I still believe it would be in the
>>>interest
>>> of both the OPENPGPKEY and the SMIMEA drafts that they continue to
>>> discuss and attempt to use the same lookup mechanism.
>>> iI suspect many software implementors that will implement one, will
>>> also implement the other. Since it is mostly a different format for the
>>> same idea, attempt to encrypt emails when a public key is advertised.
>> 
>> Yes, to all of this.  I really don't understand the reasoning
>> behind this decision, mostly because the only explanation given
>> has been pretty perfunctory.  Surely a better option right now
>> would be to find additional editors.
>
>We have plenty of willing editors: what we need is WG interest in
>reviewing (not just in asking for us to finish regardless of the open
>issues). The open issue in draft-ietf-dane-smime heavily overlap with
>those in draft-ietf-dane-openpgpkey, but only a very small number of
>people have chimed in on the recent threads.
>
>Without sufficient review, there is a good chance that the protocol will
>be heavily flawed.
>
>Note that the current issues are not the only ones for
>draft-ietf-dane-smime. Eric Osterweil brought up many proposals earlier
>that died because no one even commented on them. WG consensus by silence
>is a good sign that not enough people care about getting the protocol
>right.
>
>--Paul Hoffman
>_______________________________________________
>dane mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dane

---

From: Danny McPherson <[email-masked]>
Date: Wed, 01 Jul 2015 09:57:49 -0600

On 2015-06-30 21:23, Paul Hoffman wrote:

> Without sufficient review, there is a good chance that the protocol
> will be heavily flawed.

And running code, for that matter.  Putting it on the shelf certainly 
won't help with either, methinks.

> draft-ietf-dane-smime. Eric Osterweil brought up many proposals
> earlier that died because no one even commented on them. WG consensus
> by silence is a good sign that not enough people care about getting
> the protocol right.

Agreed.  But I've not seen silences on the SMIMEA approach either on 
the list, or in the working group sessions, or in the community, or in 
lines of code.  Perhaps traffic on the list was as much an artifact of 
'close hold' editing by some passionate factions on several arguably 
competing proposals, that's a good problem to have.  The WG dialog has 
and will surely continue to help us form consensus -- only if this isn't 
put into storage for some arbitrary amount of time.

-danny

---

From: "Mankin, Allison" <[email-masked]>
Date: Wed, 1 Jul 2015 17:47:26 +0000

Another reason not to defer the SMIME draft is that those interested in the NCCOE [*] DNS-Based Secure Email Project may benefit from the draft being active and/or published as Experimental.

NCCOE announced the project and requested interest this week:

http://nccoe.nist.gov/DNSSecuredEmail/

SMIMEA is specifically included in the scope of this project:

The DANE protocol will initially be used to authenticate servers and certificates in two roles in the DNS-Based Security for Email Project:
By binding the X.509 certificates used for
1. Transport Layer Security (TLS) to DNS names verified by DNSSEC and supporting the use of these certificates in the mail server-to-mail server communication;
2. Secure Secure/Multipurpose Internet Mail Extensions (S/MIME) to email addresses encoded as DNS names verified by DNSSEC.

[*] NCCOE expands to National Cybersecurity Center of Excellence.  Although NCCOE has been formed by the US agency NIST, its projects are open to both US and non-US participation.

Allison

---

From: Carsten Strotmann <[email-masked]>
Date: Thu, 02 Jul 2015 11:02:17 +0200

Hi,

On 29/06/15 20:41 PM, Olafur Gudmundsson wrote:
> 
> Dear Colleagues The editors of draft-ietf-dane-smime have requested
> that draft be put on hold for at least a year to see how the OPENPGP
> “experiment” works out. The chairs have agreed with this request.

that has been coming out of the blue.

The SMIME-draft shares a great deal of issues with the OPENPGPKEY draft
(e.g. the local-part discussion), and my hope was that whatever changes
are applied to OPENPGPKEY would be merged into the SMIME-draft as well,
and both would advance.

In my view, the SMIME/DANE specification is already usable ("not
perfect, but good enough") once there is a decision for the local part
(and as I said on the discussion on OPENPGPKEY, I'm fine with the SHA256
hashing, but also with base32 if needbe).

Both drafts are important, but SMIME has more relevance to bring
user-friendly encryption to mainstream users. SMIME is more widely
supported in mail-clients "out-of-the-box".

Postponing the work on this draft does not help with the IETF goal of
making the Internet protocols more secure against pervasive monitoring
(RFC 7258). The mail users out there need secure email sooner than later.

There are some ISPs here in Germany that already have running code for
SMIME/DANE to go into production with that service for their customers.

Not having an DNS Type code from IANA is one of the major road-blocks
for going live.

Going into production with SMIME/DANE with a private DNS Type (as
currently used with the Thunderbird Add-on and the SMIME-Milter) would
be possible, but ugly. Migrating from the private DNS type to a standard
DNS type later will be work and pain for admins and users.

Would it be possible to at least update the SMIME draft with the latest
changes on OPENPGPKEY, and get a DNS type code for SMIMEA records from
IANA, before sending the draft to sleep?

(if it needs be sleeping at all, I'm not convinced about that)

Carsten Strotmann

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 2 Jul 2015 14:05:32 +0000

> IANA, before sending the draft to sleep?

I don't think that's a good plan.  Once the email localpart to DNS
owner fqdn prefix mapping is decided, there really not much more
to do for SMIMEA.

    * Possibly separate owner fqdn for signature-only keys vs
      encryption keys:

	_sign._mumble.example.com IN SMIMEA U S M <hash>
	_encrypt._mumble.example.com IN SMIMEA U S M <key>

      This really should be signalled in-band in the certificate,
      but if conceding on this gets the draft over the line, I
      would be willing to accept the compromise.

    * Observe that encryption keys (if published and whether the
      labels for encryption are separate or not) need to have matching
      type Full(0) if encryption is to be possible with the SMIMEA
      record in hand.  So typically the matching type would be
      Full(0).  However, using a different matching type supports
      (for better or worse) a model where encryption is not possible
      on first contact.  Encrypted mail would be possible only
      after the recipient replies with encryption capable keys in
      the signature of the reply message.

    * I am not inclined to budge on any attempts to build explicit
      "revocation" into the draft, as with TLSA, revocation needs
      to be via "de-publication", rather than publication of a
      "revocation" record.  The draft should explain the lifecycle
      model in more detail.

	+ New mail only passes SMIME signature validity with a key
	  whose trust is based on a DANE SMIMEA record, only if
	  that record is (still) present at the time the mail is
	  received.  De-publishing an SMIMEA record immediately
	  (modulo DNS and RRSIG TTLS, ...) deauthorizes the key
	  for signing.

	+ Already received mail is tagged as validated by the
	  MUA at the time the signature is first processed.  Thus
	  years or decades old mail does not become inauthentic,
	  just because the signing key used then has since expired.

	+ Encryption of new mail requires keys (still) valid for
	  use at the time the mail is sent.  A matching type other
	  than Full(0) requires prior possession of the keys, which
	  can be determined still valid via the published digest.

	+ When using DANE-TA(2) or PKIX-TA(0) records, and an
	  individual user's keys need to be "revoked", the user's
	  SMIMEA record can be changed to DANE-EE(3) or PKIX-EE(3)
	  matching a new key/certificate until the compromised
	  certificate expires.  Once the compromised certificate
	  expires, the user can be switched back to the organization-wide
	  SMIMEA trust-anchor record.

	+ When using DANE-EE(3) or PKIX-EE(1) records, to "revoke"
	  just publish a new SMIMEA association.

If "revocation" and owner-label format can be settled, we should
be able to settle any remaining issues.

So for me, the main obstacle is still the owner-label, which is
the same for both OPENPGP and SMIMEA.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 2 Jul 2015 10:34:02 -0400 (EDT)

> the same for both OPENPGP and SMIMEA.

No one has given me feedback (positive or negative) on the "lowercase if
ascii, normalise otherwise", then lookup base32/split or using hash,
that was advised to me by some of the EAI people.

if we do that with base32/split, I think it addresses all concerns:

- no guessing / multiple lookups
- works for non-ascii
- works for ascii
- works for online signing with smtp server integration

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 2 Jul 2015 14:59:58 +0000

> that was advised to me by some of the EAI people.

Works for me.  I don't know which particular unicode normal form
is most appropriate, but so long as you got sound advice on that
I have no objections.

> - works for online signing with smtp server integration

If this really were to be integrated into the SMTP infrastructure
for online signing, I would want a protocol over TCP that is not
proxied by ISP resolvers, so the SMTP server would have a better
idea of where the request is coming from.  Otherwise, a large
fraction of the requests would be proxied by 8.8.8.8 and friends,
and rate limiting abusive clients becomes very difficult.

That said, if rate limiting "dictionary attack" query patterns is
not a concern, the above gives sites that don't mind the exposure
more flexibility.  This is not worse than the opaque hash.  Of
course email addresses that are too long to encode in a 255 octet
owner name can't have keys, but they're unlikely to be very popular
with users.

-- 
	Viktor.

P.S.

In the mean time PHB seems to be working on some sort of comprehensive
end-to-end email architecture.  Is there a possibility that his
"whole elephant" approach will have more traction than adjoining
DANE key management to an otherwise largely unchanged email toolchain?

Has anyone looked at his work in detail (I don't recall how much
has been published in detail so far).

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 02 Jul 2015 09:47:28 -0600

> that was advised to me by some of the EAI people.

What exactly do we mean by "normalise" here? I don't see anything about 
normalization (in the Unicode sense) in draft-ietf-dane-openpgpkey.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Wil Tan <[email-masked]>
Date: Fri, 3 Jul 2015 02:33:42 +1000

> normalization (in the Unicode sense) in draft-ietf-dane-openpgpkey.

It's not in the draft; we were discussing this in Buenos Aires with Paul.

I believe it was suggested that we use Unicode default case folding
(Section 3.13 - http://www.unicode.org/versions/Unicode7.0.0/ch03.pdf#G33992
).

I'm not convinced that we should touch non-ASCII mailbox username.

As for ASCII - the only well-known case for locale-sensitive mapping is the
Turkish dotted/dotless i. If we lowercased capital I according to Turkish
locale, we'd get U+0131 (small letter dotless i) which is not ASCII; see
above. So my preference is to "lowercase if ascii, otherwise verbatim".

.wil

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 02 Jul 2015 10:40:34 -0600

On 7/2/15 10:33 AM, Wil Tan wrote:
>
> On Fri, Jul 3, 2015 at 1:47 AM, Peter Saint-Andre - &yet
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     What exactly do we mean by "normalise" here? I don't see anything
>     about normalization (in the Unicode sense) in
>     draft-ietf-dane-openpgpkey.
>
>
> (Section 3.13 -
> http://www.unicode.org/versions/Unicode7.0.0/ch03.pdf#G33992).
>

I tend to agree.

> As for ASCII - the only well-known case for locale-sensitive mapping is
> the Turkish dotted/dotless i.

In my experience it's usually not safe to say "the only case" when it 
comes to internationalization. ;-)

> If we lowercased capital I according to
> Turkish locale, we'd get U+0131 (small letter dotless i) which is not
> ASCII; see above. So my preference is to "lowercase if ascii, otherwise
> verbatim".

Well, locale-specific case mapping is not part of Unicode Default Case 
Folding, so applying the latter should be fine.

See also https://datatracker.ietf.org/doc/draft-ietf-precis-mappings/ on 
some of these topics.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Warren Kumari <[email-masked]>
Date: Fri, 3 Jul 2015 12:00:43 -0400

Thanks to everyone who offered to help author, but that's not the
issue - the current authors are interested, able, and involved.

Rather the issues include a lack of clear agreement on the email
address processing and difficulty in getting actual review and
feedback on drafts. We have quite active discussions on the ideas and
concepts, but when it actually comes to review, comments and feedback
on documents we often end up with silence.

The email address processing solution that we have in openpgpkey is
not perfect, but we think is good enough. We think that, after we have
gotten some experience with how this works in openpgpkey we will be in
a much better position to try solve the same issue in the SMIME
document.

I'll try chat more with my co-chair / the authors about betting an
early allocation from IANA of a code-point. The advantage is that
people can more easily test / experiment, the disadvantage (obviously)
is that we may end up with differing implementations and
interoperability issues in those experiments.

Also, I;d like to apologize for us dropping the message on the list
and then disappearing. Olafur and myself fell behind on mail because
of the 4th of July / Independence Day (
https://en.wikipedia.org/wiki/Independence_Day_(United_States) for
non-US folk) vacation / travel / etc.

W

On Thu, Jul 2, 2015 at 12:40 PM, Peter Saint-Andre - &yet
<[email-masked]> wrote:
> In my experience it's usually not safe to say "the only case" when it comes
> to internationalization. ;-)
>

-- 
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: "Osterweil, Eric" <[email-masked]>
Date: Fri, 3 Jul 2015 17:39:33 +0000

Hey Warren,

Some comments below:

> On Jul 3, 2015, at 12:00 PM, Warren Kumari <[email-masked]> wrote:
> 
> address processing

My 0.02 is that the approach being followed by the openpgp draft (try something and see if it works) is very helpful for illustrating the utility of DANE.  It looks to me like there is a large contingent of the working group who have spoken up on list to support following this same path with SMIMEA.

> and difficulty in getting actual review and

I can’t quite follow this.  I think the SMIMEA draft has had numerous suggestions (from ideas to text to running code).  If it’s helpful, I can search the email archives and post some links to these discussions that were on list (not to mention the comments at various mics at various wg sessions). :)  Was there some sort of other feedback that would be better?

One example:
  https://www.ietf.org/mail-archive/web/dane/current/msg06964.html

Irrespective of whether any given suggestion was incorporated by the editors, it seems like there has been a lot of suggested text and interest, imho.

> a much better position to try solve the same issue in the SMIME

I would agree with the ``good enough’’ sentiment, and I echo those who have spoken up on the list this week in saying we should let it rip so we can gain real implementation and deployment experience with the S/MIME deployment-base.  It does seem to me that the sentiment on the list is overwhelming to push this forward (roughly 10 people in agreement with moving ahead with it), and I see very little pushing it back, right?

Eric

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 3 Jul 2015 23:19:08 +0000

On Fri, Jul 03, 2015 at 12:00:43PM -0400, Warren Kumari wrote:

> early allocation from IANA of a code-point.

The code point MUST precede settling on the final RRDATA format.
Has that been achieved?  If none of the issues are relate to the
RRDATA payload, then yes, get a codepoint.  Otherwise, it is not
a good idea to have an RRtype assignment whose syntax/semantics
change.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 4 Jul 2015 05:39:26 +0000

> a good idea to have an RRtype assignment whose syntax/semantics

Oops, MUST NOT precede.

-- 
	Viktor.