Subject: [dane] Informal lunch meeting in Vancouver on Thursday

From: Paul Hoffman <[email-masked]>
Date: Mon, 4 Nov 2013 11:08:46 -0800

Hi again. I have put in a room request for lunch on Thursday; I'll let the list know when I get it. If you're at the Vancouver IETF meeting and want to talk about DANE, hold the date. We'll meet at 11:45 in order to give people time to run out and get some food and bring it to the room; no food or beverage will be provided.

--Paul Hoffman

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Mon, 4 Nov 2013 19:24:54 +0000

> Hi again. I have put in a room request for lunch on Thursday; I'll let the list know when I get it. If you're at the Vancouver IETF meeting and want to talk about DANE, hold the date. We'll meet at…

I would be interested.

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: Paul M <[email-masked]>
Date: Mon, 4 Nov 2013 11:35:04 -0800

+1 Will be there. 

On 4/11/2013, at 11:24 am, Matt Miller (mamille2) <[email-masked]> wrote:

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 04 Nov 2013 11:54:14 -0800

On 11/4/13 11:24 AM, Matt Miller (mamille2) wrote:
>> Hi again. I have put in a room request for lunch on Thursday;
>> I'll let the list know when I get it. If you're at the Vancouver
>> IETF meeting and want to talk about DANE, hold the date. We'll
>> meet at 11:45 in order to give people time to run out and get
>> some food and bring it to the room; no food or beverage will be
>> provided.
>> 
> 
> I would be interested.

I am interested but I have a conflict. I securely delegate all
feedback to Matt. :-)

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Warren Kumari <[email-masked]>
Date: Mon, 4 Nov 2013 12:08:49 -0800

> Hi again. I have put in a room request for lunch on Thursday; I'll let the list know when I get it. If you're at the Vancouver IETF meeting and want to talk about DANE, hold the date. We'll meet at…

Thank you. Will be there.

W

--
"Real children don't go hoppity-skip unless they are on drugs."

    -- Susan, the ultimate sensible governess (Terry Pratchett, Hogfather)

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 04 Nov 2013 12:20:43 -0800

On 11/4/13 11:54 AM, Peter Saint-Andre wrote:
>>> I'll let the list know when I get it. If you're at the
>>> Vancouver IETF meeting and want to talk about DANE, hold the
>>> date. We'll meet at 11:45 in order to give people time to run
>>> out and get some food and bring it to the room; no food or
>>> beverage will be provided.
>>> 
> 
>> I would be interested.
> 

In particular, I'm interested in moving the dane-srv document forward.
If Tony doesn't have the cycles, I'd volunteer to help (because Matt
and I need it to finish draft-ietf-xmpp-dna).

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Yoav Nir <[email-masked]>
Date: Mon, 4 Nov 2013 21:09:51 +0000

Me too.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 04 Nov 2013 22:02:43 +0000

Hi all,

Oops - our side-meetings conflict. Sorry about that.
Not sure if we can at this point.

S.

On 11/04/2013 07:08 PM, Paul Hoffman wrote:
> Hi again. I have put in a room request for lunch on Thursday; I'll
> let the list know when I get it. If you're at the Vancouver IETF
> meeting and want to talk about DANE, hold the date. We'll meet at
> 11:45 in order to give people time to run out and get some food and
> bring it to the room; no food or beverage will be provided.
> 
> --Paul Hoffman _______________________________________________ dane
> mailing list [email-masked] 

Subject: [perpass] informal meeting on open-hardware crypto
From: Leif Johansson <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 04 Nov 2013 22:41:12 +0100
List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " <perpass.ietf.org>

Folks,

Recent revelations have called into question the integrity of
some of the implementations of basic cryptographic functions
and devices used to secure communications on the Internet. 

There are questions about some algorithms but more particularly
about implementations of algorithms in software and hardware.
The Internet community can and must deal with these
implementation issues.

A few individuals and organizations are therefore embarking
on an effort to investigate and promote the development of an 
open-source hardware cryptographic engine that meets the needs 
of high assurance Internet infrastructure that use cryptography.

Such an engine must also be of general use to the broad Internet
community, covering the cryptographic needs for applications
such as secure email, web, DNS, PKIs, etc.

We are therefore hosting an informal discussion focusing on gathering
use-cases for such an engine/module.

Time: Thursday Lunch (11:30)
Place: Plaza B

Randy Bush
Stephen Farrell
Leif Johansson
Lucy Lynch
Linus Nordberg

_______________________________________________
perpass mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/perpass

---

From: Dan York <[email-masked]>
Date: Mon, 4 Nov 2013 14:14:13 -0800

On Mon, Nov 4, 2013 at 12:08 PM, Warren Kumari <[email-masked]> wrote:

> > Hi again. I have put in a room request for lunch on Thursday; I'll let
> the list know when I get it. If you're at the Vancouver IETF meeting and
> want to talk about DANE, hold the date. We'll meet at 11:45 in order to
> give people time to run out and get some food and bring it to the room; no
> food or beverage will be provided.
>

Yes, thanks for organizing, Paul.  I will plan to be there, too.

Dan

-- 
--
Dan York, [email-masked]
http://danyork.me   http://twitter.com/danyork

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 4 Nov 2013 14:27:47 -0800

+1

--
 Ondřej Surý -- Chief Science Officer
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, CZE
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110      fax:+420.222745112
 -------------------------------------------

> On 4. 11. 2013, at 12:08, Warren Kumari <[email-masked]> wrote:
> 
>

---

From: Sean Leonard <[email-masked]>
Date: Mon, 4 Nov 2013 14:30:26 -0800

Is there any way the DANE meeting can happen on Wednesday or Friday at lunch?

-Sean

On Nov 4, 2013, at 2:02 PM, Stephen Farrell <[email-masked]> wrote:

> <Attached Message.eml>_______________________________________________
> dane mailing list
> [email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 4 Nov 2013 22:32:19 +0000

On Mon, Nov 04, 2013 at 11:08:46AM -0800, Paul Hoffman wrote:

> If you're at the Vancouver IETF meeting and want to talk about
> DANE, hold the date.

Though I am not attending the Vancouver IETF meeting, I am interested
in feedback on the below DANE-related issue:

    - Suppose some day we discover that SHA256 is flawed and is
      subject to effective second-preimage attacks.

    - Suppose that hypothetically SHA512 remains secure.

    - How would clients and servers gracefully cut-over to only
      use SHA512 and avoid SHA256?

My proposal is as follows:

When a TLSA RRset contains multiple RRs of the form:

	_<port>._tcp.server.example.com. IN TLSA <U> <S> <M> <D>

with the same values of "U" and "S" but different values of the
matching type, a client MAY ignore a "weaker" matching type
(deprecated digest algorithm) when a "stronger" matching type for
the same usage and selector is present.  Which matching types are
considered "weaker" is generally at the client's discretion.

Rationale:

    Avoid algorithm switch flag days.  Once a widely used digest
    algorithm is deemed no longer robust, servers continue to
    include it in their TLSA records along with stronger digests.
    Correctly configured clients use only the stronger digests and
    are not exposed to the flaws of weaker algorithms.  Eventually,
    (once few clients remain that don't support strong digests)
    servers stop including weak digests in their TLSA RRsets.

Consequences:

    - TLSA records that specify multiple certificates or public
      keys for a single (U,S) combination (e.g. multiple trust
      anchors, or multiple EE certificates during key roll-over)
      MUST use the same set of matching types for all of them!

      Otherwise, clients may fail to support one of the desired
      certificates, when they choose to support only the RRs with
      the strongest matching type.

    - Changes in the mixture of matching types (digest algorithms)
      used in a given TLSA RRset should be made when the set of
      keys is stable.  In other words, do either key rotation or
      change of digest algorithms, but not both at the same time.

      (Recall, that with key rotation, one must publish TLSA RRs
      for new keys before they are deployed in the field, as clients
      may for a short time see only the old RRs due to DNS caching).

Alternative:

    - Clients always accept all supported digests, without pruning
      for the strongest.

    - But then there is no good way to obsolete an algorithm, a
      server publishing a "weaker" digest exposes all clients
      risk.  A server publishing only the strongest digests risks
      not interoperating with many clients (flag day).

    - To avoid flag days, we need multiple strong *mandatory* to
      implement digest algorithms, and rely on them not all failing
      at the same time.

    - At this time RFC 6698 only mandates SHA256, so we don't have
      digest algorithm agility.

-- 
	Viktor.

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 05 Nov 2013 13:21:46 -0800

Paul Hoffman <[email-masked]> writes:

> the list know when I get it. If you're at the Vancouver IETF meeting
> and want to talk about DANE, hold the date. We'll meet at 11:45 in
> order to give people time to run out and get some food and bring it to
> the room; no food or beverage will be provided.

I'll definitely be there, and thank you for putting it together Paul.
Viktor and I have a few things to bring up and was disappointed that
there was no DANE meeting this time, especially in light of the
Wednesday discussions and how much DANE has been talked about in light
of the perforce work.  If possible, there is one particular topic I'd
like to take some time for on Thursday if you're carving off blocks (15
minutes or so).

-- 
Wes Hardaker
Parsons

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Nov 2013 14:21:00 -0800

Just to be clear, there is no agenda: note the first word in the subject line.

This is a good place to talk, clear up misconceptions, and maybe foment new work.

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 6 Nov 2013 00:18:49 +0000

> This is a good place to talk, clear up misconceptions, and maybe foment new work.

Noted.  If Thursday lunch is not a good opportunity to provide
feedback on the digest algorithm agility question, I am of course
more than happy to receive feedback via this list that is not based
on intruding on a pleasant lunch. :-)

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 6 Nov 2013 00:27:38 +0000

> and I need it to finish draft-ietf-xmpp-dna).

It seems most likely that Tony does not.  In which case, I'd like
to ask you to read the closely related new (Hardaker/Dukhovni) SMTP
draft, and, if you're willing, to negotiate some Skype or Google
Hangout time to discuss how much of that is generally applicable
(not just to SMTP) to protocols that use SRV or similar (e.g. MX)
indirection.

Drop Wes and me an off-list email when you're ready to move forward.

-- 
	Viktor.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 05 Nov 2013 16:38:17 -0800

On 11/5/13 4:27 PM, Viktor Dukhovni wrote:
>> In particular, I'm interested in moving the dane-srv document
>> forward. If Tony doesn't have the cycles, I'd volunteer to help
>> (because Matt and I need it to finish draft-ietf-xmpp-dna).
> 
> to ask you to read the closely related new (Hardaker/Dukhovni)
> SMTP draft,

Just to be sure, that is draft-ietf-dane-smtp-with-dane, right? Thanks
for your work on this topic.

> and, if you're willing, to negotiate some Skype or Google Hangout
> time to discuss how much of that is generally applicable (not just
> to SMTP) to protocols that use SRV or similar (e.g. MX) 
> indirection.

Yes, I will investigate that. As far as I know, the main technologies
under consideration here are SMTP/IMAP/POP and XMPP (which uses SRV).
Do we know of others we need to consider?

> Drop Wes and me an off-list email when you're ready to move

I can finish re-reading your spec tonight or tomorrow morning and we
can chat this week (or at least I can chat with Wes, because I know
I've seen him in the hallways in Vancouver).

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 05 Nov 2013 16:58:54 -0800

> on intruding on a pleasant lunch. :-)

That wasn't even what I was going to bring up :-)

(but the list is the right place to discuss *any* final solution, obviously)
-- 
Wes Hardaker
Parsons

---

From: Paul Wouters <[email-masked]>
Date: Tue, 5 Nov 2013 20:01:45 -0500 (EST)

> Hi again. I have put in a room request for lunch on Thursday; I'll let the list know when I get it. If you're at the Vancouver IETF meeting and want to talk about DANE, hold the date. We'll meet at…

Will be there. Very happy to explain, comment, take questions on:

http://tools.ietf.org/html/draft-wouters-dane-otrfp-01

http://tools.ietf.org/html/draft-wouters-dane-openpgp-01

Paul

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 5 Nov 2013 17:08:24 -0800

I will be there, 

	Olafur

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 05 Nov 2013 17:40:43 -0800

>       the strongest matching type.

I.e., the same solution that is de facto used by DNSSEC DS records
(https://www.ietf.org/mail-archive/web/dnsext/current/msg11008.html).

I believe in the need for algorithm agility and proposed three possible
solutions including the above during the original design process
(https://trac.tools.ietf.org/wg/dane/trac/ticket/22), but got no
traction.

Matt

---

From: Daniel Migault <[email-masked]>
Date: Wed, 6 Nov 2013 02:50:52 +0100

I will try to make it. Thanks Paul for organizing it.
BR
Daniel

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: "Dickson, Brian" <[email-masked]>
Date: Wed, 6 Nov 2013 02:10:09 +0000

+1

Brian

Sent from my iPhone

> On Nov 4, 2013, at 2:28 PM, "Ondřej Surý" <[email-masked]> wrote:
> 
> +1
> 
> --

---

From: Anton Baskov <[email-masked]>
Date: Wed, 6 Nov 2013 21:52:28 +0200

And me.

-- 
Anton Baskov 

On Mon, 4 Nov 2013 14:27:47 -0800

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 15 Nov 2013 05:45:04 +0000

> (https://trac.tools.ietf.org/wg/dane/trac/ticket/22), but got no

Thanks, yes, so my proposal requires no changes to the DANE RRset,
rather it requires sensible DNS operator practice.  For each 
(usage, selector) combination the mapping:

    "data" -> SET OF mtype for RRs that correspond to "data"

must be the same for all "data" that use the same (usage, selector).
I think this is the "Cartesian Product" option in your ticket, but
the set of mtypes may differ from one (usage, selector) pair to another.

This is now queued for inclusion in the next Postfix snapshot.  Details
that the group may want to comment on:

    - Records with mtype "0" are always considered stronger than any
      hash function for where collisions are unavoidable in principle,
      even if believed computationally infeasible.

    - Before choosing the "best" (client selected, not specified by RFC)
      digest for a particular (usage, selector) pair found in the TLSA
      RRset, any plainly unusable RRs are discarded:

	* With "X 0 0", discard RR if the associated data is not an
	  ASN.1 encoding of an X.509 certificate.

	* With "X 1 0", discard RR if the associated data is not an
	  ASN.1 encoding of an X.509 SPKI structure.

	* Otherwise, with "X [01] Y" for non-zero "Y", discard the RR
	  when the length of "Y" is not a valid length for digest
	  algorithm "Y".

Basically, when all the RRs for a particular mtype (that would otherwise
be considered strongest present) are a-priori unusable due to malformed
data, we can't be sure whether even the "selector" and "mtype" are valid,
after all the record is junk.  So it seems reasonable to not impute any
meaning to such a record's meta-data in the face of broken data.

Otherwise, we commit to failing all all clients that support the
apparently stronger algorithm, without in fact knowing where the
problem lies.

I must admit that of course this is an incomplete solution, some
particularly elite domain administrators could replace all the hex
E's in their association data with 3's and clearly some clients
will again fail.  So the strategy does not catch all problems, just
the most obvious ones where we would otherwise have to fail when
all the records of (apparently) the best mtype are unusable.

If the majority feel strongly that one must take as much of a broken
record as one can at face value, we should include this in the OPs
BCP, and perhaps in any future DANE bis.  My preference is to
not read any meaning into unusable records.

-- 
	Viktor.

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 14 Nov 2013 22:27:21 -0800

> the set of mtypes may differ from one (usage, selector) pair to another.

Right.

Sensible as this practice may seem, it's not required by the standard,
which may reduce the likelihood that any given zone administrator will
be willing to follow it.  You may get fewer interoperability failures at
the cost of missing some attacks by having the zone opt into an
algorithm agility scheme by publishing additional RRs.

Matt

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 15 Nov 2013 06:37:32 +0000

> algorithm agility scheme by publishing additional RRs.

Fortunately, there is zero installed base for DANE.  So even if
RFC 6698 does not require the practice I am suggesting, I can add
it to the SMTP draft, and make sure it is implemented in the first
MTA to implement DANE (and likely also the second, as Exim developers
are likely to work towards a compatible implementation soon).
Therefore, it can become standard practice for SMTP from the outset.

We can also publish this in the OPs draft, and encourage other
protocol implementors (hint: XMPP, ...) to do likewise.  It may
also be time to start thinking about DANE bis, and this could be
one of the additions.

So it is far from too late to add this requirement without the
complexity of additional new records.

Given the "greenfields" state of DANE adoption today, is there a
plausible consensus for moving forward with this proposal.  Any
positive or negative feedback on the processing of a-priori unusable
records?

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 15 Nov 2013 06:55:19 +0000

> meaning to such a record's meta-data in the face of broken data.

A closer reading of 6698 seems to support the above:

	https://tools.ietf.org/html/rfc6698#appendix-B.2

before any processing of the TLSA RRset, we see:

   for each R in TLSArecords {
     // unusable records include unknown certUsage, unknown
     // selectorType, unknown matchingType, erroneous RDATA, and
     // prohibited by local policy
     if (R is unusable) {
       remove R from TLSArecords
     }
   }

with supporting language in https://tools.ietf.org/html/rfc6698#section-4.1

   If a certificate association contains a certificate usage, selector,
   or matching type that is not understood by the TLS client, that
   certificate association MUST be considered unusable.  If the
   comparison data for a certificate is malformed, the certificate
   association MUST be considered unusable.

so certainly the malformed "X Y 0" cases are explicitly out of
scope, and I think so are the cases where the digest length is
absurd.

So if the rest of the digest agility proposal is acceptable, the
semantics of unusable records in this case are perhaps already
defined the way I thought most natural.

-- 
	Viktor.