Re: [dane] Need some feed back

On Thu, 7 Mar 2019, Pradeep Kumar Xplorer wrote: Pradeep, Subject: [dane] Need some feed back https://datatracker.ietf.org/doc/draft-xplorer-device-association/ There are a number of fundamental problems with your document. First, the document seems to want to tie together and manage

Re: [dane] [Technical Errata Reported] RFC7672 (5395)

On Sat, 16 Jun 2018, RFC Errata System wrote: Original Text - DNS records that would be classified "indeterminate" in the sense of [RFC4035] are simply classified as "insecure". Corrected Text -- DNS records that would be classified "indeterminate" in the

[dane] [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension (fwd)

FYI, Paul -- Forwarded message -- Date: Wed, 4 Apr 2018 13:50:15 From: Joseph Salowey To: "" Subject: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension Hi Folks, Some objections were raised late during the review

Re: [dane] Improving DANE S/MIME Privacy

On Tue, 11 Apr 2017, Alice Wonder wrote: That being said, the suggestion of using 2 1 1 or even 2 0 0 entries may give the privacy I seek. It will, but you will then have to come up with a lookup system to find the SMIME cert for a given user. If I want to email you without having prior

Re: [dane] Review of draft-ietf-dane-smime-15

On Wed, 1 Mar 2017, John Levine wrote: They're experiments. I'd think it'd be useful for the experiments to see whether salted or unsalted hashes work better (or worse.) The experimental RFC for OPENPGPKEY is out already, and it does not support salting. So I don't know how you would

Re: [dane] Review of draft-ietf-dane-smime-15

On Tue, 28 Feb 2017, Dale R. Worley wrote: Well enough. Actually, I thought about this issue some more, and that led to my followup e-mail. I think there is a real desire to not have the DNS provide a direct catalog of valid e-mail addresses, but it conflicts with the weak security of

Re: [dane] [EXTERNAL] Re: Summary of second WGLC for dane-smime

On Wed, 30 Nov 2016, Paul Hoffman wrote: On 30 Nov 2016, at 6:33, Allison Mankin wrote: I think this reference might work as an early archival discussion of rainbow tables for efficient hash breaking: www.iacr.org/cryptodb/archive/2003/CRYPTO/1615/1615.ps Thanks, this looks fine. We have

Re: [dane] Second WGLC draft-ietf-dane-smime

On Wed, 9 Nov 2016, John Levine wrote: If you do publish it, I'd suggest much stronger language in the first sentence of section 9 on security considerations. The security model for S/MIME certs has always been that the trust flows from the CA to the user without involving the user's mail

Re: [dane] Comment on draft-ietf-dane-smime-12

On Thu, 6 Oct 2016, Marcos Sanz wrote: I just got through the dane-smime document and have one ammendment to make to section 7, specifically "applications SHOULD use TCP - not UDP". My impression is that that specific recommendation (and its rationale in the next paragraph) was mimicked from

Re: [dane] Webinterface for DANE-OpenPGPkey look-up available

On Tue, 20 Sep 2016, Martin Rex wrote: Rene 'Renne' Bartsch, B.Sc. Informatics wrote: the german mail-provider mail.de has published a web-interface for RFC 7929 look-ups at https://openpgpkey.info/. That's neat! I tested it out and it found the my pgp key. Perhaps a more human readable

Re: [dane] [Technical Errata Reported] RFC7929 (4796)

On 09/08/2016 04:20 AM, RFC Errata System wrote: > The following errata report has been submitted for RFC7929, > "DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP". > > -- > You may review the report below and at: >

[dane] Postero DANE UI

https://posteo.de/en/blog/new-webmail-interface-displays-servers-with-the-highest-sending-security We have just released a new feature for you: Our webmail interface now shows you which of your contacts you can send to with the optimal security of DANE technology. This

Re: [dane] [Editorial Errata Reported] RFC7929 (4768)

On Sun, 7 Aug 2016, RFC Errata System wrote: The following errata report has been submitted for RFC7929, "DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP". -- You may review the report below and at:

Re: [dane] I-D Action: draft-ietf-dane-smime-12.txt

On Mon, 1 Aug 2016, Paul Hoffman wrote: Jakob and I think this addresses all the actionable comments we got in WG Last Call. You added: 9.1. Response Size To prevent amplification attacks, an Authoritative DNS server MAY wish

Re: [dane] Working group Last call: draft-ietf-dane-smime-11.txt

On Mon, 25 Jul 2016, Jim Schaad wrote: This is not the issue that my message was designed to highlight. In S/MIME it is possible to say which of the message formats and which content encryption algorithms are supported by a client. This is not the same as designating if a certificate is

Re: [dane] Working group Last call: draft-ietf-dane-smime-11.txt

On Sun, 24 Jul 2016, Warren Kumari wrote: A reminder that this WGLC closes tomorrow -- so far we have not really seen sufficient feedback on this document. PLEASE review this document and provide comment. I have reviewed the document. I think it is ready for IETF LC but it could see a few

Re: [dane] I-D Action: draft-ietf-dane-openpgpkey-12.txt

On Mon, 2 May 2016, internet-dra...@ietf.org wrote: Filename: draft-ietf-dane-openpgpkey-12.txt A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-openpgpkey-12 I had forgotten to add text provided by Alexey Melnikov during

Re: [dane] DNSSEC for tools.ietf.org

On Thu, 28 Apr 2016, Viktor Dukhovni wrote: Yes, basically right, here's the DS-free delegation: tools.ietf.org. NS gamay.levkowetz.com. tools.ietf.org. NS zinfandel.levkowetz.com. tools.ietf.org. NS merlot.levkowetz.com. tools.ietf.org.

Re: [dane] Alexey Melnikov's No Record on draft-ietf-dane-openpgpkey-08: (with COMMENT)

On 04/13/2016 07:27 AM, Stephen Farrell wrote: > > Paul, > > If you can make changes easily now, say before Friday, please feel > free to do so. Better to not make too many changes when other ADs > are reading the draft but I suspect Alexey's in early so the next > few days should be fine. It's

Re: [dane] Alexey Melnikov's No Record on draft-ietf-dane-openpgpkey-08: (with COMMENT)

On Sun, 10 Apr 2016, Alexey Melnikov wrote: -- COMMENT: -- I might have more comments/questions before the telechat. Here is my initial batch: Thanks for

Re: [dane] "decoded local-part" for dane-smime and dane-openpgp

On Wed, 9 Mar 2016, Sean Leonard wrote: Subject: [dane] "decoded local-part" for dane-smime and dane-openpgp The problem is that this text does not distinguish between the local-part production, and the decoded (unescaped) local-part characters. As I am discussing in another Internet-Draft

[dane] FWD: I-D Action: draft-ietf-dane-openpgpkey-08.txt

with email addresses Author : Paul Wouters Filename: draft-ietf-dane-openpgpkey-08.txt Pages : 19 Date: 2016-03-08 https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ There's also a htmlized version available at: https

Re: [dane] [secdir] draft-ietf-dane-openpgpkey-06 SECDIR Review

Hi Donald, Thanks for the secdir review. I've incorporated your suggestions and hopefully resolved your issues in the -07 draft I just posted at https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-07 Comments inline below. I think this draft is not ready for publication. It probably

Re: [dane] PGP security models, was Summary of IETF LC for draft-ietf-dane-openpgpkey

On Wed, 23 Sep 2015, Randy Bush wrote: if i think of it as a form of opportunistic encryption with very weak authentication it seems useful. right. but when i want strong authentication i want strong introduction. So pull the key from DNSSEC, check for sigs. If not good enough, you could

Re: [dane] provisioning assumptions, was PGP security models, was Summary

On Tue, 22 Sep 2015, John Levine wrote: Also, this introduces a downgrade attack. User creates a key, gets lots of WoT signatures, publishes it through key servers and DANE. Bad guy takes over the account, publishes a new key with no signatures. According to sec 5.2 of the draft, a mail

Re: [dane] PGP security models, was Summary of IETF LC for draft-ietf-dane-openpgpkey

On Tue, 22 Sep 2015, John C Klensin wrote: However, if you believe that, because of trust issues, people get keys only from personal contacts rather than indirectly from public databases, why are we discussing yet another public database-based approach? Or are you convinced that the problem

Re: [dane] Published Rules for equivalent local-parts

On Sep 20, 2015, at 15:06, John R. Levine wrote: > Since the question will surely come up, it'd be a good idea to explain why > this is better than the existing SMTP command that provides the canonical > address(es) for an input address. Because the anti-spam brigade made

Re: [dane] Last Call: (Using DANE to Associate OpenPGP public keys with email addresses) to Proposed Standard

On Thu, 3 Sep 2015, Petr Spacek wrote: note if you meant this as a comment for the IETF LC, you should use that threat over at i...@ietf.org and not this one. as far as I can tell people favor various LHS-hashing variants for privacy reasons. Assuming that this observation is correct, I

Re: [dane] E-mail Cert left hand side -- what the chairs think the consensus is

On Tue, 1 Sep 2015, Brian Dickson wrote: Suppose there is a domain where email addresses are case-sensitive. (RFC822 et al permit this.) Suppose there is a case-folded collision (two LHS addresses differ only by case). What happens if you want to encrypt ONLY to the correct recipient?

Re: [dane] Fwd: New Version Notification - draft-ietf-dane-openpgpkey-04.txt

On Fri, 28 Aug 2015, Stephen Farrell wrote: Thanks Paul, and all who contributed to the discussion. I've requested IETF LC for that. I've two nits you might want to check as IETF LC comments. 1. section 3 2nd last para - is the example correct? I get a different result but maybe I'm doing

Re: [dane] I-D Action: draft-ietf-dane-openpgpkey-05.txt

On Fri, 28 Aug 2015, internet-dra...@ietf.org wrote: Subject: [dane] I-D Action: draft-ietf-dane-openpgpkey-05.txt A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-openpgpkey-05 The -05 just fixes the outdated/unused RFC references Stephen

Re: [dane] Delivery of email if MX is not signed

On Sun, 23 Aug 2015, Patrik Fältström wrote: 2. Delivery of the mail over TLS to mail.example.net. so example.com is unsigned? and mail.example.net is signed, and the TLSA record in example.net is signed. Correct. In that case, I believe TLS will be used but the TLSA cannot be verified,

Re: [dane] Delivery of email if MX is not signed

On Sun, 23 Aug 2015, Patrik Fältström wrote: What I think I see in the draft is that DANE and SMTP is either on or off, and I want more shades of gray. Well yes. Because you either authenticate or fail to authenticate and refuse to deliver. We cannot decide whether or not to deliver in

Re: [dane] [openpgp] The DANE draft

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

Re: [dane] hash truncated to 28 octets

On Tue, 4 Aug 2015, Jiankang Yao wrote: I just read this draft. Note we are changing that part of the draft to use another mechanism instead of hashing. Question: 1, why should it be  hash truncated to 28 octets ? why choose 28 not other numbers? It was to match the length of the

Re: [dane] [OT] Deployment news (Germany is plowing ahead)

On Tue, 28 Jul 2015, Viktor Dukhovni wrote: I've mentioned before that much of the deployment ( 30%) for DANE SMTP is in Germany. Today something unprecedented happened. The OPENPGPKEY deployment/coders also have a strong German component. Paul

Re: [dane] Stapling DNSSEC/DANE

Sounds familiar :) https://tools.ietf.org/html/draft-ietf-dnsop-edns-chain-query-02 Sent from my iPhone On Jul 28, 2015, at 20:11, Nico Williams n...@cryptonector.com wrote: I doubt this is the right list to send this to, but might as well start here and move this elsewhere as needed.

Re: [dane] key distribition and IETF document status

On Mon, 27 Jul 2015, Werner Koch wrote: I also find it _really_ ironic that it is not the openpgp key servers that you are calling vast, aging and vaguely understood infrastructure because if anything is a dangerous misunderstood mess that we cannot seem to clean up, it is the current

Re: [dane] [openpgp] The DANE draft

On Sat, 25 Jul 2015, Phillip Hallam-Baker wrote: This document has not progressed quickly. The original draft was published in July 2013. No one is trying to rush this through I am quite happy waiting till 2016 or 2018.  If it isn't done right its better not to publish at all.

Re: [dane] OPENPGP and SMIME local part question

On Wed, 22 Jul 2015, James Cloos wrote: OG == Olafur Gudmundsson o...@ogud.com writes: OG The sense of the room in the IETF-93 meeting was to do do a BASE32 OG encoding of local part with 60 character labels, shortest label is OG the left most label. Since I've posted on the topic before,

Re: [dane] Another SMIMEA draft review

On Mon, 20 Jul 2015, Wiley, Glen wrote: Which they'll also learn by just looking at the zone data, if the localparts are not hashed in the final spec. Has there been any recent discussion about using a non-hashed LHS encoding? I don¹t think there has so we probably don¹t want to bring that

Re: [dane] Any mail plugins to validate DANE?

On Wed, 15 Jul 2015, Paul Gunman wrote: I would like to know if there is any mail plugins (for Thunderbird or others), except Smaug, that could allow a client to check for SMIMEA records. Anyone have heard of something? openpgpkey-milter is a sendmail/postfix milter to auto-encrypt. A

Re: [dane] SecDir Review of draft-ietf-dane-ops-12

On Sat, 11 Jul 2015, Viktor Dukhovni wrote: * Section 4.8, page 8: Therefore, when a TLS client authenticates the TLS server via a TLSA record with usage DANE-EE(3), CT checks SHOULD NOT be performed. What are the valid reasons for performing th CT checks? If there are not any, why not make

Re: [dane] SecDir Review of draft-ietf-dane-ops-12

On Mon, 13 Jul 2015, Viktor Dukhovni wrote: CT auditors log EE-certs. Checking the CT logs also provides a way to signal rogue EE-certs to the original webserver via a gossip/client protocol. So I would not say Usage 3 should never check the CT logs. DANE-EE(3) certs are often self-signed,

Re: [dane] DANE and IPsec

See my previously sent email. There is still a problem. I can explain more once I have a real keyboard Sent from my iPhone On Jul 2, 2015, at 17:29, Yoav Nir ynir.i...@gmail.com wrote: On Jul 2, 2015, at 10:40 PM, Viktor Dukhovni ietf-d...@dukhovni.org wrote: On Thu, Jul 02, 2015 at

Re: [dane] DANE and IPsec

Host to host IPsec is very rare. But that's what we are trying to change :) But regardless, let’s assume that the local address is 198.51.100.2. So the quintuple for the connection would be (UDP, 198.51.100.2:704, 192.0.2.5:53) I don't think you want a tunnel per netflow, and still

Re: [dane] DANE and IPsec

The reverse failed. It is only useful in private cloud deployments lacking other types of authentication for publishing pubkeys (ldap, Kerberos , etc) Sent from my iPhone On Jul 2, 2015, at 19:01, Yoav Nir ynir.i...@gmail.com wrote: On Jul 3, 2015, at 12:28 AM, Viktor Dukhovni

Re: [dane] DANE and IPsec

On Fri, 3 Jul 2015, Yoav Nir wrote: Seems like a limitation of DNS security. DNSSEC can authenticate that “mallory claimed that mallory.example.com is at 8.8.8.8”, but DNSSEC does nothing to tell me whether the claim is true. Ordinarily you gain nothing by pointing your DNS name at a wrong

Re: [dane] DANE and IPsec

if i put in evil.nohats.ca. IN A 8.8.8.8 along with an IPSECKEY and have you trigger opportunistic IPsec to evil.nohats.ca) Of course, a layer of NAT or one-local-ip-per-remote could address that but it is extremely ugly. So we (libreswan) are still undecided. I thought that Paul Wouters

Re: [dane] Deferral of SMIME draft

On Tue, 30 Jun 2015, Danny McPherson wrote: Furthermore, I see no defensible reason why an OPENPGP experiment would be blocking on this work - quite the contrary, actually. Had there been an actual discussion on this already-a-year-overdue-WG-milestone I suspect a responsible action would

Re: [dane] Deferral of SMIME draft

That's a little unfortunate because we're merging two prototypes millers into one. But we'll adapt the smime one based on the same prefix as openpgpkey Sent from my iPhone On Jun 29, 2015, at 15:41, Olafur Gudmundsson o...@ogud.com wrote: Dear Colleagues The editors of

Re: [dane] AD review of draft-ietf-dane-openpgpkey-03

On Sun, 21 Jun 2015, A. Schulze wrote: That's the point: you EXPECT that. But John has the idea that this could fail. I don't know all the details about UTF8SMTP or EAI, but I could imagine we see the world in ASCII. Most of us have no daily expieriences with chinese or arabian. And at

Re: [dane] AD review of draft-ietf-dane-openpgpkey-03

On Mon, 15 Jun 2015, John Levine wrote: Allow the client to lowercase (initially, or as a fallback) - I think everybody agrees there is no harm in this *in practice*, then encode with split base32. ... No, for two reasons. One is that RFC 5321 clearly says that case folding is forbidden, and

Re: [dane] AD review of draft-ietf-dane-openpgpkey-03

On Mon, 15 Jun 2015, Richard Clayton wrote: And I have repeatedly asking for a single deployment where FOO != foo and not heard a single answer back. here's one (and it took me about 5 minutes to find it...) http://www.sevenforums.com/browsers-mail/229536-yahoo-disposable-

Re: [dane] AD review of draft-ietf-dane-openpgpkey-03

On Sat, 14 Jun 2015, John Levine wrote: There are some advantages to each approach. The main disadvantage of not using DNS (B), is that no such service is readily available, so new code would be required to implement it. At the WG in Dallas, people familiar with mail ops seemed to think that

Re: [dane] AD review of draft-ietf-dane-openpgpkey-03

On Sat, 14 Jun 2015, John Levine wrote: I agree with all of that. If it is to be DNS, then hashing works no worse than most other encodings. As I'm fairly sure I described in detail before, base32 provides the option of reversing the encoding at the server, looking up the local part using

Re: [dane] AD review of draft-ietf-dane-openpgpkey-03

On Sun, 14 Jun 2015, Viktor Dukhovni wrote: I think this assumption is part of the miscommunication in this thread. I don't think that's what being suggested. Rather, users may have lots of valid addresses, known to the receiving system as being the same user and in fact too many to create a

Re: [dane] AD review of draft-ietf-dane-openpgpkey-03

On Thu, 11 Jun 2015, John Levine wrote: This is a strong statement, I have a problem with your word preventing . My reading of the draft is that mail sender can perform the Hash() operation on any name she/he has/guesses for the receiver, and looks each one up in until a match is found or the

Re: [dane] AD review of draft-ietf-dane-openpgpkey-03

On Tue, 9 Jun 2015, Peter van Dijk wrote: Even experimental seems a bit strong for a lookup method that has seen so much debate without serious improvement. Actually, the improvement has been to no longer require multiple records to support Uppercase'ed email addresses often accidentally

Re: [dane] draft-ietf-dane-openpgpkey

On Mon, 1 Jun 2015, Stephan Bosch wrote: While that would be nice, the problem is how you authenticate that to your ISP or mail hoster, DNS hoster or DNS webgui interface. Well, I suppose using the same credentials used to read/send e-mail? For this, I am assuming the mail hoster is the

Re: [dane] draft-ietf-dane-openpgpkey

On Mon, 1 Jun 2015, Stephan Bosch wrote: From what I can tell, this document only describes how to publish and retrieve a key in DNS/DNSSEC, i.e. in what format. I don't see any mention of a procedure by which a key would get published. Since the domain would be controlled by the mail

Re: [dane] dane-smtp and Dane future

On Mon, 1 Jun 2015, Olafur Gudmundsson wrote: The chairs want to thank Victor for his outstanding work on getting the draft to this point. Indeed. Thanks for your hard work on the specification and the implementation Viktor! We are reaching the point that the core DANE protocol work is

Re: [dane] Barry Leiba's Discuss on draft-ietf-dane-smtp-with-dane-17: (with DISCUSS and COMMENT)

On Tue, 26 May 2015, Mark Andrews wrote: In addition it is just plain pointless to do the lookup. If the A/ is insecure the TLSA lookup will be insecure due to there being not DNSSEC trusted path the TLSA node. I don't understand this. Wether the A/AAA is spoofed or someone with

Re: [dane] need not change across certificate renewals with the same key

On Tue, 12 May 2015, Kyle Rose wrote: If the DANE-EE entry has a SubjectPublicKeyInfo hash, then the metadata within the certificate can be trusted only if the certificate signature is validated against a trust anchor: a self-signed certificate is sufficient (and probably ideal) here, since

Re: [dane] Where to flesh out a DNSSEC extension proposal?

On Sun, 26 Apr 2015, Viktor Dukhovni wrote: On Sun, Apr 26, 2015 at 04:59:12PM -0400, Paul Wouters wrote: Great, it looks like the proposed standard for hardening SMTP/TLS could be repurposed for either http(s) or arbitrary ports as per my proposal no? There is nothing left to harden

Re: [dane] Where to flesh out a DNSSEC extension proposal?

On Sun, 26 Apr 2015, Chris Monteiro wrote: Apologies is this in an inappropriate list, but I'm unfamiliar with the channels for opening discussions about new web standards and this list seemed least inappropriate. :) I've blogged a proposal for a couple of DNS/ DNSSEC extensions that I would

Re: [dane] Where to flesh out a DNSSEC extension proposal?

On Sun, 26 Apr 2015, Scott Kitterman wrote: There is nothing left to harden. The presence of TLSA means, never go to the insecure port. Yes, when the client is not already committed to using TLS, i.e. it is opportunistic. The opportune part is hey, they are publishing a key to use for

Re: [dane] AD review of draft-ietf-dane-smtp-with-dane

On Fri, 17 Apr 2015, Stephen Farrell wrote: My understanding is that some people wanted to experiment with TLSA without having to have had DNSSEC deployed. But I take your answer to be that no such behaviour is defined here, which is fine. So consider this one answered. I go back and forth

Re: [dane] AD review of draft-ietf-dane-smtp-with-dane

On Sat, 18 Apr 2015, Stephen Farrell wrote: On 17/04/15 21:41, Nico Williams wrote: As Paul says, there is a UI here: logs for sysadmins, Received headers for users and sysadmins. Paul's initial mail on this referred to UI and downgrade attack possibilities. I don't believe there is any such

Re: [dane] AD review of draft-ietf-dane-smtp-with-dane

On Thu, 16 Apr 2015, Viktor Dukhovni wrote: In any case this draft was ready (and has been largely unchanged) for about a year now, *before* all the fuss about SSL 3.0. Clients MUST support at least TLS 1.0 (to use SNI). Servers MAY support SSL 3.0 (allowing them to publish TLSA RRs with

Re: [dane] AD review of draft-ietf-dane-smtp-with-dane

On Thu, 16 Apr 2015, Stephen Farrell wrote: My understanding is that some people wanted to experiment with TLSA without having to have had DNSSEC deployed. But I take your answer to be that no such behaviour is defined here, which is fine. So consider this one answered. I go back and forth

Re: [dane] Updated draft-ietf-dane-openpgpkey

On Thu, 2 Apr 2015, Christian Rößner wrote: Latest version: http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-03 Diff: http://www.ietf.org/rfcdiff?url1=draft-ietf-dane-openpgpkey-02url2=draft-ietf-dane-openpgpkey-03 Items changed: Is this also an option for SMIMEA draft? And is

Re: [dane] Updated draft-ietf-dane-openpgpkey

On Thu, 2 Apr 2015, Viktor Dukhovni wrote: Just a question for ._encr and ._sign: Do you really plan to store private keys in public DNS? Is it, what ._sign will be used for? Isn?t this really a security issue? No they are public keys in both cases. Some public keys are for signing only,

Re: [dane] Updated draft-ietf-dane-openpgpkey

On Thu, 2 Apr 2015, Osterweil, Eric wrote: Also, the smime key attributes will tell if if they are usable for signing and/or encrypting. So my preference is to not have another place to indicate this so we avoid needing to deal with mismatches. I think this was better described by Doug M

Re: [dane] Updated draft-ietf-dane-openpgpkey

On Thu, 2 Apr 2015, Viktor Dukhovni wrote: Your initial thinking was right, the private key is used for signing, but the public key is published so that verifiers can validate the signature. The proposal is to publish verification (public) keys (that validate received mail) separately from

Re: [dane] Updated draft-ietf-dane-openpgpkey

On Thu, 2 Apr 2015, Paul Wouters wrote: Right, and: for email signing): - must have the Digital Signature or Non-Repudiation OID?s as a Key Usage. (for email encryption): - must have the Key Agreement or Data Encipherment OID?s as a Key Usage. So why add the dns complexity for _sign

Re: [dane] Email box mapping: Who is responsible ?

On Wed, 1 Apr 2015, Rose, Scott W. wrote: The goal is to create a simple way to find email key for a known correspondent. Can we assume that the email encryptor knows the address of recipients in a format emitted by the recipients email system, and is that good enough? I believe so. I

Re: [dane] encoding mail addresses in the DNS

On Wed, 1 Apr 2015, John R Levine wrote: So, if hashing anything here, please stick with sha256 and truncate the output if you need it shorter. For reasons discussed at great length, I don't think any sort of hash is a good idea here. Do you see any problems with the base32 encoding? The

[dane] Updated draft-ietf-dane-openpgpkey

I have updated draft-ietf-dane-openpgpkey Latest version: http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-03 Diff: http://www.ietf.org/rfcdiff?url1=draft-ietf-dane-openpgpkey-02url2=draft-ietf-dane-openpgpkey-03 Items changed: - SHA-224 changed to SHA-256 truncated at 28 octets. It

Re: [dane] online vs. offline signing, was encoding mail addresses in the DNS

On Thu, 2 Apr 2015, John Levine wrote: Most important, there's the scale issue. Reports say that Yahoo has over 300,000,000 active mailboxes and Gmail has over 500,000,000. I gather the goal here is to make publishing your key cheap and easy, so let's posit modest success and say that 20% of

Re: [dane] encoding mail addresses in the DNS

On Wed, 1 Apr 2015, John R Levine wrote: I do not understand the advantage of base32 in the QNAME. As Viktor pointed out, the advantage is that the server can easily recover the local-part from the query, which makes it possible for a specialized server to do whatever it does and generate a

Re: [dane] encoding mail addresses in the DNS

On Wed, 1 Apr 2015, Nico Williams wrote: DNS servers exist which serve dynamically-generated data, and DNS servers exist which serve signed (on the fly) dynamically-generated RRsets with non-existence proofs. IIUC PowerDNS is one example. And requiring the private DNS key is available on all

Re: [dane] encoding mail addresses in the DNS

On Wed, 1 Apr 2015, John R Levine wrote: That said, I really don't mind living with users having to type in peers' e-mail addresses correctly. I just don't see that agreeing with reality. Particularly with non-ASCII names, there's way too many ways to type what looks like the same thing.

Re: [dane] encoding mail addresses in the DNS

On Wed, 1 Apr 2015, Nico Williams wrote: And requiring the private DNS key is available on all name servers for online signing really adds a huge amount of risk to the server in case of compromise - an attacker could make up OPENPGPKEY records. Any dynamic lookup will have this problem. Not

Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd)

On Mon, 30 Mar 2015, Nico Williams wrote: * Suffer from bloated caches full of negative replies for billions of accounts. Ditto. Caches already need to have extensive policies for abuse queries and when legitimatelly running out of resources and figuring out what to flush. Let the

Re: [dane] IPSECA

On Tue, 24 Mar 2015, Osterweil, Eric wrote: Given the discussion on milestones re: IPSEC DANE work at the beginning of the DANE session today we’d like to request working group adoption of the existing IPSECA document: https://tools.ietf.org/html/draft-osterweil-dane-ipsec-02 We’ve

Re: [dane] A novel idea on the local-part problem for both SMIMEA and OPENPGPKEY?

On Wed, 25 Mar 2015, Nico Williams wrote: On Wed, Mar 25, 2015 at 04:32:03PM +0100, Pieter Lexis wrote: Disadvantages: - MTAs will need to talk HTTPS - It's not DANE (more like 'DNS-Assisted') - It kind-of defeats the purpose of this WG - No NSEC3-like protection from address leakage (see

Re: [dane] IPSECA

On Wed, 25 Mar 2015, Viktor Dukhovni wrote: Finally, what I think is the biggest issue: --- IPSEC and forward DNS [ The below was explained to me by Paul Wouters in London, thanks Paul. Any mistakes in the below are mine, so if I've got the wrong end of the stick, that's

Re: [dane] A novel idea on the local-part problem for both SMIMEA and OPENPGPKEY?

On Wed, 25 Mar 2015, Nico Williams wrote: On Wed, Mar 25, 2015 at 02:34:01PM -0400, Paul Wouters wrote: If the lookup service is on port X, and the attacker blocks port X, you do not know whether there is a service interruption or an active attack. How is that different from the attacker

Re: [dane] email oracle and lookup, was A novel idea

On Wed, 25 Mar 2015, Viktor Dukhovni wrote: It makes NO difference what protocol is used to find the address - key mapping. Using something other than DNS just makes it easier to rate control clients, because they are not proxied by their ISP's DNS cache. You mean it makes it easier to DDOS

Re: [dane] A novel idea on the local-part problem for both SMIMEA and OPENPGPKEY?

On Wed, 25 Mar 2015, Viktor Dukhovni wrote: THe problem with canonicalizing addresses (akin to EXPN) is that most sites simply won't want to publish this data. Returning a key is very different from returning a canonical address. Any alternative protocol should just return the SMIME or PGP

Re: [dane] email oracle and lookup, was A novel idea

On Wed, 25 Mar 2015, Nico Williams wrote: On Wed, Mar 25, 2015 at 08:45:57PM +, Viktor Dukhovni wrote: On Wed, Mar 25, 2015 at 04:30:36PM -0400, Paul Wouters wrote: On Wed, 25 Mar 2015, Viktor Dukhovni wrote: Attacks will just take out the oracle to induce plaintext, or will spoof

Re: [dane] IPSECA

On Wed, 25 Mar 2015, Nico Williams wrote: Any IPsec-based proposals for DNS confidentiality would seem to belong in DPRIVE WG, not DANE WG. DPRIVE's approach seems to be: secure the stub resolver to recursive resolver connection. IPsec fits in that approach, and all that's needed is

[dane] FYI: OpenKeychain - Keys in DNSSEC/DANE

https://github.com/open-keychain/open-keychain/wiki/Google-Summer-of-Code-2015#keys-in-dnssecdane Keys in DNSSEC/DANE Brief explanation: Together with the XMPP Standards Foundation (XSF), see their GSoC idea, we would like to extend the MiniDNS library with DNSSEC support to allow the

Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd)

On Tue, 18 Mar 2015, John Levine wrote: I'd suggest taking out based on special characters, since the most common mapping is case folding. The standard term for the LHS is local-part, so you might as well use that and reference RFC 5321, sec 2.3.11 where it's defined. Also, the SHOULD NOT

Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd)

On Sun, 15 Mar 2015, John R Levine wrote: That did not answer my question though. Do you prefer the example mappings to be in the document or not? As I think I said, the entire section 3.1 needs to go. That includes the examples. What's the logic behind not mentioning a possible known

Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd)

On Sun, 15 Mar 2015, John R Levine wrote: That sounds fine. Are you saying you prefer the document to not list the example mappings we know about, or are you okay with still mentioning the example mappings? This whole can of worms needs attention from the people who think about mail all the

Re: [dane] Comments on draft-ietf-dane-openpgpkey-02 (fwd)

On Sat, 14 Mar 2015, Viktor Dukhovni wrote: EAI email *addresses* ARE UTF-8 by definition. There is simply no mechanism to signal any other encoding, either in SMTP envelopes or in primary message headers (where one can signal the encoding of phrases like the display name, but not the address

Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review.

On Sat, 14 Mar 2015, John Levine wrote: In article CAHw9_iLafyHnbnii2huxoR48rybydu-tT4rScm6oo9p==yt...@mail.gmail.com you write: Thanks everyone for your feedback and comments, the WGLC is now closed. I think that it looks like there is strong consensus for publishing, but I'm hoping to

Re: [dane] Start of WGLC for draft-ietf-dane-openpgpkey - *please* review.

On Fri, 13 Mar 2015, Pieter Lexis wrote: Thanks for the review Pieter, I'm very much on the Yes, this is good-side of things. 3.1: The MAY in the last sentence is much too weak. We can’t have interoperability without some stronger rules. Suggest moving this whole section into -usage or

  1   2   >