Minutes for DANE at IETF-90
minutes-90-dane-2

Administrivia DANE status,
(appoint scribes, blue-sheets, agenda bashing)
Chairs - 5 min

DANE has a new charter, and the DANE specification documents will be
revised by the end of next year, according to this new charter.

DANE activites in Other WGs
Chairs -  5 min

Dan York: Reported on a draft proposing using DANE in SIP in SIPCORE
WG, also a draft on using DANE with TURN servers in the TRAM WG in the
RAI area.

Working group documents:
SRV and SMTP status
http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-10
http://tools.ietf.org/html/draft-ietf-dane-srv-06
Chairs 10 min

Awaiting final edits from the authors before conducting WG Last Call

Matt Miller: Existing edits need to be sync’ed with co-authors, then submitted.

Wes Hardaker: SMTP Draft functionally done. The SRV draft may want to
look at the SMTP draft style for considerations and usage description.


OPENPGP and SMIME status
http://tools.ietf.org/html/draft-ietf-dane-openpgp-00
http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-usage-00
http://tools.ietf.org/html/draft-ietf-dane-smime-06
Chairs 5 min

Call for comments on OpenPGP and SMIME.

Eric Osterweil: Concerns that the suggestions on the mailing list
(Feb’14) concerning deployment were not pulled into the draft

Paul Hoffman: Did not see enough interest in this to integrate it it,
but if there is more interest if this is applicable then we will put
it in.

Eric O: We have implementations. What is the right way to bring this
to the group to ensure that there is notice and interest?

Paul H: Sure - bring it up again.

Olafur G: Tasked Eric to restart this discussion on the mailing list.


DANEbis and operational guidance
http://tools.ietf.org/html/draft-ietf-dane-ops-05
Wes Hardaker - 30 minutes.

[see presentation]

Paul Wouters: When you say “non-PKIX” do you mean “non-TLS”?

Wes H: Right now for SMTP the only non-PKIX protocol is SMTP, but for
now thats it. The protocol operators need to think about the world
that they are in and their expectations and think about what types to
use

Paul W: But in switching you may need to run them for 10 years in parallel?

Wes H: Yes

Paul W: Should we think about this, and have a new usage type?

Wes H: It would be great to say that this end system will only use
PKIX-trust and this system will not. But how to signal this division
is challenging. The protocol is that trumping one over the other.

Victor D: non-PKIX means where there is not an established and used PKIX

Phil HB: this is about what RPs should (or may) do. If a RP checks the
DANE records are they allowed NOT to check PKIX revocation? (for
example)

Wes H: Why is a decision for a protocol to use DANE a deliberate
decision? For these very considerations, as the protocol trust model
cannot be left in an undistinguished state

Olafur G: I am slightly confused. The decision of which to use (DANE
or PKIX) would be left tot he protocol designers, rather than the
operators

Wes H: Yup. Don’t leave it to the operators

Victor D: When clients support both then they are vulnerable to
DNSSEC-only attacks.

Olafur G: I thought that operators could chose to use DANE in SRV -
you are saying that this is a protocol designer decision?

Viktor D: The important thing to realize is that the choice of PKIX
vs. DANE is a CLIENT-side choice that needs to be made.  The server
can publish whatever it wants, but clients need to pick which world
they are in.

Paul H: This WG needs to think about this to assist in the users of DANE

Wes H: This sounds like future BCP material once we have some experience here

Keith Moore: One of the issues here is mixed motives for DANE. Extend
TLS into areas where the CA model has not worked well, and there are
situations to use DANE where there was no CA model. These are
different. You need a template that says what protocol design should
specify. But this conflicts with the desire to extend existing
protocols with DANE. This is messy.

Dan Y: This is about best practices for a protocol to chose to use DANE or not

Paul W: as a PKIX protocol you could use DNAE as an add-on to further
restrict the PKIX model.

Wes H: there are tradeoffs here


TLSA Raw Keys
http://tools.ietf.org/html/draft-ietf-dane-rawkeys-00
Paul Wouters 20 min

(slides)

"Should every protocol that uses TLSA records need its own RFC?”

Wes: we just tried to not break things in our draft, but did not go
into the semantics of when and how to use it in the TLS protocol. If
you think there is just one more paragraph then great, send us the
paragraph!

Viktor: The draft suggests that any usage 3 works with RPK, but in
fact only "3 1 X" works.  Also with anything other than "3 1 0", there
needs to be some way to convey the actual key (as in TLS).

Paul: Yes you need to use the correct TLSA type that publishes the
full public key

Peter Koch: Existing protocols need this kind of specification, but
are you also taking about future protocols?

Paul: For a new protocol you can just use the TLSA record, and say so.

Peter: you need to be explicit about the use of non-TLSA records

Paul Hoffman: You don’t need to create a new record type with the same
format as TLSA then if you are going to use TLSA for a non-TLS
protocol then you should describe that use, and do so in the context
of the protocol description. It may not need a dedicated RFC, but it
does need to be described.

Viktor: My intention was to put in enough RPK semantics into the OPS
draft, to make a separate draft unnecessary.

Dan York: We need to minimise the number of documents that an apps
developer needs to refer to to implement an app

Adam ?: there are situations of interop problems with RSA key use of
explicit “null” values to parameters.

Jeff Hodges: +1 to Paul Hoffman and Adam. You have to write all this stuff down.

Wes: Is a document needed? Those 14,000 RFCS are all useful and
valuable. [Really? :-)  Your cynical minute taker!]

Keith: disagrees with all the discussion item prompts. He argues in
favour of explicit prohibition, against, reuse of existing RRtypes,
against not requiring new specifications per protocol.

Paul: DANE made these mistakes in the past, and this document tried to
remove these restrictions and limitations on the usage of these types

Olaf: Is this TLS of the use of TLSA?

Keith: Well we are already in that zone and we can’t go back.

Viktor:  With TLS the server presents the public key to the client,
provided it uses the same format on the wire as in DNS, it should just
work.  I've never seen any problems with 3 1 1 records with respect to
SPKI encoding.  And in practice all the keys are RSA.  So it looks
like the issue is absent in practice…

(room) RFC3279: its already written down  section: 2.3.1

Dan: Specification of the use of TLSA is good, but look at SIP - the
glomming of PSTN goop in SIP lead to RFC5411, which is 42 pages of
meta info about SIP that refers to the other RFCs. We should not
reproduce this for DANE. That;’s what I want.

Wes: Could be IANA Registry

Paul: We’ve already lost that registry naming.

Matt Miller: generic and simple. but. if folk have to write something
for their protocol. then fine, but its good to think that this is
generic.

Phil HB: If you are going to put raw things in then it depends on the
crypto - for example RSA has a lot of ancillary infer there, and if
you use curve 25519 with short keys, then there is a point to this.
2048 bits of raw keys squished into a DNS would be a more comfortable
fit.

Adam: If you can do this for DNSSEC, then you can do this for DANE

Keith: Section in a document that describes its usage in the context of DANE

Paul W: Should the 6689 restrictions be dropped? Is there an objection
to dropping these restrictions?

Paul Hoffman: Well you should say when to drop and provide context:

Paul W: I meant "drop the restrictions to PKIX-only"

Paul Hoffman: Yes

Paul W: Which document should include this dropping of restrictions

Olaf: Should we think about a new RRtype for protocols that only use raw keys?

Wes: Didn’t we have a failed key-type RRtype and didn’t it fail?

Viktor:  NO. 3 1 X is sufficient to represent keys. The SPKI selector
already solves the problem.

Peter Koch: Unless the protocol is clear in the beginning that it
wants type “foo”

Paul Hoffman: Agree with Victor - TLSA is sufficient

Andrew Sullivan: Agree. on grounds of reuse of TLSA to make it simpler to use


A DANE based solution for improving the security of HTTPS in CDN
http://netsec.ccert.edu.cn/duanhx/files/2014/05/httpsincdn.pdf
Haixin Duan -- 25 min

Keith Moore: Doubts that additional security is being provided here

Adam Langley: +1

Yoar Nir: Similar doubts. If you already have DNSSEC then the CNAME is
enough. There is no other requirement for the TLSA record

Viktor: Yes. Exactly. This proposal is fatally flawed. The design is
broken.  And failed to use the origin site cert for anything.  Anyone
can copy a cert!  This is profoundly broken EV or NOT.

Philip HB: Perhaps there is a need for a publication protocol to allow
one to easily acquire and publish a new certificate, and thereby avoid
delegation records

Erik N; You need to be careful of conflating a bunch of discrete
issues. There is some opportunities for opportunistic security in
using DANE for TLSA records for traffic heading through a CDN.

Chairs: Write an individual draft on the problem statement

"Reverse DANE" i.e. can server check TLSA records for client?
no draft
Chairs - 10 min

How can a server look up a client DANE key? Some protocols send names
via handshake. Some protocols only have the addresses of the client.
Can a server validate a client

WG Feedback: There is the feel that this is interesting, and there are
some challenges here, but it would be useful to start with some form
of problem statement draft. Perhaps some use cases would help and
perhaps the protocol should perform this itself?


End of meeting