Re: [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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

The hashes are very useful since any UDP DNS packet not able to fit into MTU will cause truncation and reconnection to DNS server via TCP. So almost any full certificate will cause two serialized connections anyway UDP and TCP. If you connect to the service and to DNS server, you can make those connections in parallel, which considerably speeds up
this (because you will need that connection to the service anyway).

Yes, I do follow; perhaps I'm expecting this to be swallowed during the DNS phase rather than the service connection phase anyway.

Also, I thought - possibly erroneously - that at least some operating systems were using TCP for the connection to the resolver anyway, which'd lessen this effect.

In any case, I'm not going to demand that hashes are outlawed, I'm mostly moaning about the number of permutations here - testing all these is going to drive me spotty.

> 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.

Dave.
--
Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxxxxxxxxx
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]