Re: [dane] Ben Campbell's Yes on draft-ietf-dane-ops-14: (with COMMENT)

2015-08-05 Thread Viktor Dukhovni
On Wed, Aug 05, 2015 at 03:57:46AM +, Viktor Dukhovni wrote: > > NEW: > >This section updates [RFC6698] by specifying that the > >TLSA Publisher MUST ensure that each combination of Certificate > >Usage, selector and matching type in the server's TLSA RRset includes at > >least

Re: [dane] right-to-left characters in local part

2015-08-05 Thread Paul Hoffman
On 5 Aug 2015, at 19:27, Jiankang Yao wrote: in section 3 of draft-ietf-dane-openpgpkey, do we need some discusstion about the issues related to local part of the email address which includes the right-to-left characters such as Arabic character? Why would we? Those characters are just as l

[dane] right-to-left characters in local part

2015-08-05 Thread Jiankang Yao
hello, in section 3 of draft-ietf-dane-openpgpkey, do we need some discusstion about the issues related to local part of the email address which includes the right-to-left characters such as Arabic character? Jiankang Yao___ dane mailing list

Re: [dane] [openpgp] The DANE draft

2015-08-05 Thread Daniel Kahn Gillmor
On Wed 2015-08-05 11:25:08 -0400, Stephen Farrell wrote: > Tempora. That on-path attacker has a far easier time reversing the > b32 than anything based on the hash. Even with DPRIVE, we don't know > how to handle the recursive to authoritative part. > > So a "putative other protocol that copies thi

Re: [dane] [openpgp] The DANE draft

2015-08-05 Thread Daniel Kahn Gillmor
On Wed 2015-08-05 04:14:42 -0400, Paul Wouters wrote: > The text does make it clear that you have that choice: > > The proposed new DNS Resource Record type is secured using DNSSEC. > This trust model is not meant to replace the Trust Signature model. > However, it can be used to encryp

Re: [dane] [openpgp] The DANE draft

2015-08-05 Thread Stephen Farrell
Hiya, On 05/08/15 19:32, Viktor Dukhovni wrote: > I don't think hashing (without salt) provides sufficient obfuscation > to deter on-path attacks. Compared to b32 hashing is clearly less bad, if we're putting user-specific identifiers in the DNS. The requirement to have a large table and to pre

Re: [dane] hash truncated to 28 octets

2015-08-05 Thread Viktor Dukhovni
On Tue, Aug 04, 2015 at 12:12:45PM +, Viktor Dukhovni wrote: > On Tue, Aug 04, 2015 at 03:50:32AM -0400, Paul Wouters wrote: > > > >2,since some local-parts are longer than 28 octets, are there some > > >collisions after hash?truncated?to?28?octets?? > > > > I think if you have 100.000 emai

Re: [dane] [openpgp] The DANE draft

2015-08-05 Thread Viktor Dukhovni
On Wed, Aug 05, 2015 at 06:35:09PM +0200, Patrik L?hr wrote: > That's the point - we are concerned with on-path watchers. > That is why we are in strong favour of hashing like I already stated: > Hashing does not protect against "decryption" - but it makes a distinct > difference whether I need to

Re: [dane] [openpgp] The DANE draft

2015-08-05 Thread Patrik Löhr
Hi Paul, that's the point - we are concerned with on-path watchers. That is why we are in strong favour of hashing like i already stated: Hashing does not protect against "decryption" - but it makes a distinct difference whether I need to make a targeted attack on a hash, or can arbitrarily search

Re: [dane] [openpgp] The DANE draft

2015-08-05 Thread Paul Hoffman
On 5 Aug 2015, at 8:25, Stephen Farrell wrote: On 05/08/15 16:12, Paul Hoffman wrote: Wearing my author hat: I don't care between b32 and hashing. Both are equally easy to document. However: On 5 Aug 2015, at 4:28, Stephen Farrell wrote: So sorry to continue an argument but shouldn't this ex

Re: [dane] [openpgp] The DANE draft

2015-08-05 Thread Carsten Strotmann
Hello Paul, Paul Hoffman wrote: > Wearing my author hat: I don't care between b32 and hashing. Both are > equally easy to document. However: > > On 5 Aug 2015, at 4:28, Stephen Farrell wrote: > >> So sorry to continue an argument but shouldn't this experiment be >> a more conservative about priv

Re: [dane] [openpgp] The DANE draft

2015-08-05 Thread Stephen Farrell
On 05/08/15 16:12, Paul Hoffman wrote: > Wearing my author hat: I don't care between b32 and hashing. Both are > equally easy to document. However: > > On 5 Aug 2015, at 4:28, Stephen Farrell wrote: > >> So sorry to continue an argument but shouldn't this experiment be >> a more conservative ab

Re: [dane] [openpgp] The DANE draft

2015-08-05 Thread Paul Hoffman
Wearing my author hat: I don't care between b32 and hashing. Both are equally easy to document. However: On 5 Aug 2015, at 4:28, Stephen Farrell wrote: So sorry to continue an argument but shouldn't this experiment be a more conservative about privacy just in case it ends up wildly successful?

Re: [dane] [openpgp] The DANE draft

2015-08-05 Thread Patrick Ben Koetter
* Stephen Farrell : > > > On 05/08/15 09:14, Paul Wouters wrote: > >> > >> > >> I have no strong preference for base32 vs. digested localpart for the > >> hostname. Digested localparts require a little bit more work to invert > >> than base32, but given the low entropy of typical normalized loca

Re: [dane] [openpgp] The DANE draft

2015-08-05 Thread Stephen Farrell
On 05/08/15 09:14, Paul Wouters wrote: >> >> >> I have no strong preference for base32 vs. digested localpart for the >> hostname. Digested localparts require a little bit more work to invert >> than base32, but given the low entropy of typical normalized localparts, >> they don't provide a lot

[dane] regarding my previous draft-ietf-dane-ops-14 comments

2015-08-05 Thread Paul Wouters
Hi, After a phone conversation with Viktor, he convinced me the current text is actually good and my previous objections were my misinterpretations. So I'm in favour of the document in its current form. Paul ___ dane mailing list dane@ietf.org https

Re: [dane] [openpgp] The DANE draft

2015-08-05 Thread Paul Wouters
On Wed, 5 Aug 2015, Daniel Kahn Gillmor wrote: i'm not subscribed to dane@ietf.org, feel free to forward if you think this would be useful. [ I added dane back to the CC: as I think it will be useful to keep the openpgp discussion there too, as some people there also wanted a different spe