Subject: [saag] Agenda request: draft-barnes-dane-uks

From: Martin Thomson <[email-masked]>
Date: Fri, 28 Oct 2016 08:19:56 +1100

DANE aren't meeting this time around, and this has a pretty strong
security bent.  The implications for web security in particular are
interesting.  I'm also interested in discussing how we can avoid
creating more cases like this in the future.  Can we have 10-15 for
this?

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 28 Oct 2016 00:18:03 +0000

> creating more cases like this in the future.  Can we have 10-15 for

If the discussion is about how to ammend RFC 7671, and what
counter-measures are appropriate in any update, then I think this
discussion is best handled on list.  I won't be at the meeting.

The recommendations of the draft in the subject are IMHO too broad
and, for example, needlessly limit the use of raw public keys even
in protocols where UKS is a non-issue [*].

If the discussion is of a more general nature, on how to avoid
potential pitfalls in future documents, by all means proceed on-site.

-- 
	Viktor.

[*] While indeed RFC 7671 introduces issues for HTTPS, DANE is not
in use with HTTPS, and if and when it is, it will almost certainly
use DNSSEC stapling, in which case the UKS attacks don't apply as
the server then signs its TLSA records.  For applications much
simpler than browsers with their "same-origin" trust-mode, and
especially applications that already employ MX, SRV or similar
indirection, UKS is out of scope.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 28 Oct 2016 16:58:09 +1100

> potential pitfalls in future documents, by all means proceed on-site.

This was my intent.  I think we can work out the detail on a mailing list.

> For applications much

For the record, I disagree with this very broad assertion.