Subject: [dane] dane-smtp and Dane future

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 1 Jun 2015 21:54:02 -0400

Dear Colleagues, 

The latest version of the dane-smtp draft addresses all the issues raised in IETF and IESG reviews and has entered the RFC editors queue where it will wait for OPS document to catch up. 
The chairs want to thank Victor for his outstanding work on getting the draft to this point.

This means that now that both the “Service” DANE documents have now entered the RFC editors queue
and the OPS document is in IESG review.  

We are reaching the point that the core DANE protocol work is complete. 
At this point the WG has a choice as to what direction to take
a) Finish work on OPENPGP and S/MIME documents and close down
b) Start work on DANE-bis document(s) that combines the Protocol parts of the 4 documents that define the DANE protocol. 
c) Just work on promoting existing RFC along the standards track
d) Identify and adopt other documents that are needed for DANE adoptions/operations/specifications 

Please provide guidance to chairs 
Olafur & Warren 

> Begin forwarded message:
> 
> From: [email-masked] <mailto:[email-masked]>
> Subject: [dane] I-D Action: draft-ietf-dane-smtp-with-dane-19.txt
> Date: May 29, 2015 at 10:53:00 AM EDT
> To: <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
> 
> 
> 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 Working Group of the IETF.
> 
>        Title           : SMTP security via opportunistic DANE TLS
>        Authors         : Viktor Dukhovni
>                          Wes Hardaker
> 	Filename        : draft-ietf-dane-smtp-with-dane-19.txt
> 	Pages           : 32
> 	Date            : 2015-05-29

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 2 Jun 2015 02:16:14 +0000

> Please provide guidance to chairs 

I'm still inclined to write a client auth document for SMTP with
DANE and perhaps more broadly, though signalling from the client
to the server that triggers DANE authentication of the client will
be application protocol specific.

I was waiting for closure on the prior documents.

I am also concerned that the working group does not have very many
active participants, so getting feedback is a significant problem.

If we're going to produce more documents, we need more active
participation.

-- 
	Viktor.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 01 Jun 2015 20:23:59 -0600

> If we're going to produce more documents, we need more active

Traditionally at the IETF, working groups start with a bang and end with 
a whimper. Expect less participation in the future, not more. We don't 
have to like it, but it's good to accept reality.

Peter

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 2 Jun 2015 02:25:04 +0000

On Mon, Jun 01, 2015 at 09:54:02PM -0400, Olafur Gudmundsson wrote:

> This means that now that both the "Service" DANE documents have now entered
> the RFC editors queue and the OPS document is in IESG review.

Thanks.  One quick note, I made a mistake in the most recent update
to the OPS document.  I'll push a "-12" version that fixes the
problem.  This will also add a note to explain why mixing "3 1 1"
for a past SPKI with "2 0 1" for a replacement cert is wrong and
the migragation from DANE-EE(3) to DANE-TA(2) was correct in "-10"
(and is now wrong in "-11").

This is not anything new, just application of previous text to the
migration example, but the example will help to clarify the text.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 1 Jun 2015 23:04:38 -0400 (EDT)

> The chairs want to thank Victor for his outstanding work on getting the draft to this point.

Indeed. Thanks for your hard work on the specification and the
implementation Viktor!

> a) Finish work on OPENPGP and S/MIME documents and close down

Not against that.

> b) Start work on DANE-bis document(s) that combines the Protocol parts of the 4 documents that define the

Not against that either, although that should not be interpreted as
volunteering :)

> c) Just work on promoting existing RFC along the standards track

I'm a little concerned if we don't do this, where those documents will
go to get discussed at all. SAAG? Then again, I think most of the new work
would mostly be based on the existing documents, and not contain much
"invention" that needs the guidance of experts. So this is a possible
option as well.

> d) Identify and adopt other documents that are needed for DANE adoptions/operations/specifications 

I still have an IPsec one pending, but most of those issues are with
IPsec and not with the relatively simple DANE, so that could find
an audience in ipsecme (providing it is not closing down too)

Paul

---

From: Shumon Huque <[email-masked]>
Date: Fri, 19 Jun 2015 18:56:28 -0400

On Mon, Jun 1, 2015 at 9:54 PM, Olafur Gudmundsson <[email-masked]> wrote:

> b) Start work on DANE-bis document(s) that combines the Protocol parts of
> the 4 documents that define the DANE protocol.
I've written a draft to describe the use of DANE TLSA records for client
certificate authentication. It needs a bit of fine tuning but I hope to put
it out shortly. I know of several parties interested in using DANE with
client certificates. If the working group is amenable, I would like to
request time for discussion at IETF93.

[Viktor Dukhovni mentioned previously that he was contemplating this also,
and he and I have been subsequently discussing some of the subtle aspects
of this topic.]

Shumon Huque