Subject: Re: [xmpp] [dane] Last Call: <draft-ietf-dane-protocol-19.txt> (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 12 Apr 2012 06:35:01 -0600

On 4/12/12 6:33 AM, Ondřej Surý wrote:
> 
> On 12. 4. 2012, at 14:18, Dave Cridland wrote:
> 
>> On Thu Apr 12 12:03:37 2012, Ondřej Surý wrote:
>>> Please see http://trac.tools.ietf.org/wg/dane/trac/ticket/28
>>> before discussing SRV records further.  We have left SRV
>>> records on purpose and we expect that this will be solved in 
>>> separate document (for each affected protocol).
>> Foolish me, I must have missed the reference to that ticket in
>> the draft.
>> 
>> Really, if this is out of scope, declare it as such - but then
>> don't use SMTP either, given that's very close in spirit to SRV.
>> 
>> But certainly for XMPP, DANE is currently insufficient, which is
>> a real shame.
> 
> We would certainly welcome new document defining interaction of
> XMPP and DANE.  But I think that this needs to be crafted in the
> XMPP working group.

We had a long discussion about this in the DANE WG. Matt Miller and I
volunteered to write a document about this, but other folks are
welcome to beat us to it if they please. :)

Peter

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

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 12 Apr 2012 14:33:22 +0200

On 12. 4. 2012, at 14:18, Dave Cridland wrote:

>> Please see http://trac.tools.ietf.org/wg/dane/trac/ticket/28 before discussing SRV records
>> further.  We have left SRV records on purpose and we expect that this will be solved in
> Foolish me, I must have missed the reference to that ticket in the draft.
> 
> Really, if this is out of scope, declare it as such - but then don't use SMTP either, given that's very close in spirit to SRV.
> 
> But certainly for XMPP, DANE is currently insufficient, which is a real shame.

We would certainly welcome new document defining interaction of XMPP and DANE.  But I think
that this needs to be crafted in the XMPP working group.

>> > As a final comment, I'd presonally like to see some comments about how, and when, extended validation information should be checked and trusted. It seems to me that such information  should be ignored when handling type 2 or type 3 certificates; or at best it should be validated independantly using the traditional methods - that is, it should be treated as a type 0 or type 1 certificate for the purposes of extended validation.
>> I think that Extended Validation is out of the scope of this document.  And if I am not
>> mistaken the CA which are able to issue EV certificates are hardcoded in the browsers.
>> Thus I think that DANE-aware applications can use standard rules for EV certificates.
> 
> I think this needs calling out. EV seems like a very good argument for the existence of CAs in a DANE world; I think it would be beneficial to touch on the subject if possible.

Alright point taken.  I have opened http://trac.tools.ietf.org/wg/dane/trac/ticket/39

O.
--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------