From ifette@google.com Tue Sep 3 18:31:38 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E93F21E80C3 for ; Tue, 3 Sep 2013 18:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZaMhn5H9rmr for ; Tue, 3 Sep 2013 18:31:37 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7756A21F9B81 for ; Tue, 3 Sep 2013 18:31:34 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id c10so66415ieb.3 for ; Tue, 03 Sep 2013 18:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=rMMIsa/ugofGOxGOJJ4vnvYlJCfqeNWPWGxAzT8Y34c=; b=Mo9HRiH5AINdE18ILtmt4Z3SLxygY3YUaqdDFnrN0SFoi5L45xj1iqS8PIAX9grHpw T/JFjRAtoFPFnxLi0dQDS/LNken3JtphIsB8X5ZPseqW5DdEPzWd/tpz2PfYpnHx4pnN IQP2WzO88d+bYcH6Kp6OVdA05xUegx6jYN5TnGvSLJz2bHwHbxv82OKuM8tZJU48Y2f6 +OfQhk9TebsXidH8fpw+0pLMhXVidFEj5I/9ZJak7Efk3ZCehXIRRr1nAKEgvQdPqjzi NxxFJIQQnyIJZlyNcqrgSATAAW0VlMKXEXMM5obxrPMuOiWsKPRgcgvL7oZzTlFMyBzd nMbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:date:message-id:subject :from:to:content-type; bh=rMMIsa/ugofGOxGOJJ4vnvYlJCfqeNWPWGxAzT8Y34c=; b=dYoEIwEOgWpZyp/6g2xxoZCHs/VOfIV3lmt8W+bJF7ygxkfnkjU9NXuGvJ68nArLxS gAnDz6rsC4t34NAoQI83DLFIRcTpQWuZicYoLMJfRusqCrM6tQ6/hhF1C7ab0n0zEtnX sAsmDlfpYsx4DA9EGJdmEq0IsqoJj3iwJiTzHMnzSKsEsQ9n8yECdWIf/qviBIDIrhVV QRkEg7hLPKvQC3lwjqbWOONvgpNKb6HCtkuBneYsm06GVJk3e3kzg3sK1+jfkKwYOHqu EugUCStBoFHHXsptPICqatXpKPCOWrdXhgDd9oaCWtLBWv0A2J11umhhYfI6lYlkMh6v QLsw== X-Gm-Message-State: ALoCoQmpweTvdValfunp4Uxg6Orusyg/sJBIa0BLQzIYheo1W+2WMYA4SgPkKuZ39K9w4Y7wEttpRXVZY8q5h6+mPCTY5y4QX94hSXHoQcuTe9ezkpEaUvz/YhJUN6o9nniJKbLIJLZzYOcUMVFOyI+5n2ax9JLfGqm1UN9ww0P+ObIR3wYHH8jXEhalk26/3+DfjaOtmZCV MIME-Version: 1.0 X-Received: by 10.50.25.39 with SMTP id z7mr17945936igf.59.1378258293901; Tue, 03 Sep 2013 18:31:33 -0700 (PDT) Received: by 10.231.161.70 with HTTP; Tue, 3 Sep 2013 18:31:33 -0700 (PDT) Date: Tue, 3 Sep 2013 18:31:33 -0700 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: dane@ietf.org Content-Type: multipart/alternative; boundary=047d7bd7689804b84f04e584c415 Subject: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ifette@google.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 01:31:38 -0000 --047d7bd7689804b84f04e584c415 Content-Type: text/plain; charset=UTF-8 RFC6698 contemplates the use of DANE records with SMTP. (_25._ tcp.mail.example.com is given as an example in the document). However, one of the problems with SMTP is that it's not known to the sending server whether the receiving server supports STARTTLS a-priori. (One connects to the SMTP server, issues an EHLO command and is informed whether the server supports STARTTLS or not. This can be trivially removed by a malicious MITM). Similar downgrade vulnerabilities exist for other protocols that rely on STARTTLS-type commands. DANE lets one specify what certificate is acceptable if a certificate is required, but not whether a certificate should be expected. I'm curious to know if there's any appetite to allow this information to be conveyed via a DANE record. For instance, again with SMTP as an example, one can remember whether STARTTLS was offered on a previous connection to try to protect against downgrade attacks, but this is rather brittle, doesn't work well for new / long-tail hosts, and it's not clear in such a scenario if someone simply disabled STARTTLS intentionally or if it's actually representative of an attack. One could use DANE to convey, for STARTTLS-type services, whether a client should treat the lack of encryption support as a fatal error or not. One possible way to achieve this would be using the high bit of the certificate usage octet to specify whether the TLSA is advisory ("if you get a certificate from me, it must match in the following manner") or mandatory ("I offer certificates that match in the following form, if you are unable to obtain a certificate from me treat it as a hard failure"). I'm not stuck on the particulars of which bit gets used or where it gets implemented, other than it would be nice (from my perspective) if it could be combined in an existing record rather than having to fetch yet another RR for just one bit of information. Fundamentally, the problem I'm trying to solve is the problem of downgrade attacks against protocols like SMTP that advertise their STARTTLS capability in the clear. It seems like DANE, where one is specifying a policy about how to validate a TLS connection, might be a reasonable fit for information about whether STARTTLS (be it POP3/IMAP, FTP, XMPP, LDAP or any other protocol) should be expected or not. I'm not sure if this has been considered or not. Thoughts welcome. -Ian --047d7bd7689804b84f04e584c415 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
RFC6698 contemplates the use of DANE records with SMTP. (<= span style=3D"color:rgb(0,0,0);font-size:13px;line-height:1.2em">_25._tcp.mail.example.com is given as an = example in the document). However, one of the problems with SMTP is that it= 's not known to the sending server whether the receiving server support= s STARTTLS a-priori. (One connects to the SMTP server, issues an EHLO comma= nd and is informed whether the server supports STARTTLS or not. This can be= trivially removed by a malicious MITM). Similar downgrade vulnerabilities = exist for other protocols that rely on STARTTLS-type commands.

DANE lets one specify what certificate is acceptable if a certificate i= s required, but not whether a certificate should be expected. I'm curio= us to know if there's any appetite to allow this information to be conv= eyed via a DANE record. For instance, again with SMTP as an example, one ca= n remember whether STARTTLS was offered on a previous connection to try to = protect against downgrade attacks, but this is rather brittle, doesn't = work well for new / long-tail hosts, and it's not clear in such a scena= rio if someone simply disabled STARTTLS intentionally or if it's actual= ly representative of an attack.

=
One could use DANE to convey, for STARTTLS-type services, whether = a client should treat the lack of encryption support as a fatal error or no= t. One possible way to achieve this would be using the high bit of the cert= ificate usage octet to specify whether the TLSA is advisory ("if you g= et a certificate from me, it must match in the following manner") or m= andatory ("I offer certificates that match in the following form, if y= ou are unable to obtain a certificate from me treat it as a hard failure&qu= ot;). I'm not stuck on the particulars of which bit gets used or where = it gets implemented, other than it would be nice (from my perspective) if i= t could be combined in an existing record rather than having to fetch yet a= nother RR for just one bit of information.

=
Fundamentally, the problem I'm trying to solve is the problem of = downgrade attacks against protocols like SMTP that advertise their STARTTLS= capability in the clear. It seems like DANE, where one is specifying a pol= icy about how to validate a TLS connection, might be a reasonable fit for i= nformation about whether STARTTLS (be it POP3/IMAP, FTP, XMPP, LDAP or any = other protocol) should be expected or not. I'm not sure if this has bee= n considered or not.

Thoughts welcome.
-Ian
--047d7bd7689804b84f04e584c415-- From marka@isc.org Tue Sep 3 19:26:02 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E3321E80C3 for ; Tue, 3 Sep 2013 19:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HbDlAUOfIhV for ; Tue, 3 Sep 2013 19:25:57 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 494AE21E810A for ; Tue, 3 Sep 2013 19:25:53 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 63373C9423; Wed, 4 Sep 2013 02:25:40 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1378261553; bh=66hpSyyf8iqlroKuotZWIyKyzB+h+vcng8rO3EkJp5o=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=OugxM5fZ8j92LMWN+zbmS/ToRoXK3WCS1pTss7qb4gH2wcSc5+qizdYBvP599Wggb Bvu0LUIFZ8vZvImgMeeWhWRRDujAsC/Gu/eaThXMRh6BbSjc5guMyuGUXlhKj7kKSA EZEyvHgZpiKVxro4CWIFjZXPiI8n/1Fm7G56M98o= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 4 Sep 2013 02:25:40 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CC50B160459; Wed, 4 Sep 2013 02:26:49 +0000 (UTC) Received: from drugs.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 994EC16030E; Wed, 4 Sep 2013 02:26:49 +0000 (UTC) Received: from drugs.dv.isc.org (localhost [IPv6:::1]) by drugs.dv.isc.org (Postfix) with ESMTP id B05A239302EF; Wed, 4 Sep 2013 12:25:33 +1000 (EST) To: ifette@google.com From: Mark Andrews References: In-reply-to: Your message of "Tue, 03 Sep 2013 18:31:33 -0700." Date: Wed, 04 Sep 2013 12:25:33 +1000 Message-Id: <20130904022533.B05A239302EF@drugs.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: dane@ietf.org Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 02:26:02 -0000 In message , =?UTF-8?B?SWFuIEZldHRlI CjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= writes: > --===============5680513047430573670== > Content-Type: multipart/alternative; boundary=047d7bd7689804b84f04e584c415 > > --047d7bd7689804b84f04e584c415 > Content-Type: text/plain; charset=UTF-8 > > RFC6698 contemplates the use of DANE records with SMTP. (_25._ > tcp.mail.example.com is given as an example in the document). However, one > of the problems with SMTP is that it's not known to the sending server > whether the receiving server supports STARTTLS a-priori. (One connects to > the SMTP server, issues an EHLO command and is informed whether the server > supports STARTTLS or not. This can be trivially removed by a malicious > MITM). Similar downgrade vulnerabilities exist for other protocols that > rely on STARTTLS-type commands. > > DANE lets one specify what certificate is acceptable if a certificate is > required, but not whether a certificate should be expected. I'm curious to > know if there's any appetite to allow this information to be conveyed via a > DANE record. For instance, again with SMTP as an example, one can remember > whether STARTTLS was offered on a previous connection to try to protect > against downgrade attacks, but this is rather brittle, doesn't work well > for new / long-tail hosts, and it's not clear in such a scenario if someone > simply disabled STARTTLS intentionally or if it's actually representative > of an attack. > > One could use DANE to convey, for STARTTLS-type services, whether a client > should treat the lack of encryption support as a fatal error or not. One > possible way to achieve this would be using the high bit of the certificate > usage octet to specify whether the TLSA is advisory ("if you get a > certificate from me, it must match in the following manner") or mandatory > ("I offer certificates that match in the following form, if you are unable > to obtain a certificate from me treat it as a hard failure"). I'm not stuck > on the particulars of which bit gets used or where it gets implemented, > other than it would be nice (from my perspective) if it could be combined > in an existing record rather than having to fetch yet another RR for just > one bit of information. > > Fundamentally, the problem I'm trying to solve is the problem of downgrade > attacks against protocols like SMTP that advertise their STARTTLS > capability in the clear. It seems like DANE, where one is specifying a > policy about how to validate a TLS connection, might be a reasonable fit > for information about whether STARTTLS (be it POP3/IMAP, FTP, XMPP, LDAP or > any other protocol) should be expected or not. I'm not sure if this has > been considered or not. > > Thoughts welcome. > -Ian The presence of the rrset prevents the downgrade attack. A validating resolver can detect when there should be a RRset but it is not being returned. The STARTTLS client then expects to see STARTTLS in the EHLO response if it has a TLSA RRset. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From andrewgwilson@gmail.com Tue Sep 3 19:33:21 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F6221F9D7B for ; Tue, 3 Sep 2013 19:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msGRFaGawu5r for ; Tue, 3 Sep 2013 19:33:20 -0700 (PDT) Received: from mail-bk0-x229.google.com (mail-bk0-x229.google.com [IPv6:2a00:1450:4008:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5334821F9D68 for ; Tue, 3 Sep 2013 19:33:20 -0700 (PDT) Received: by mail-bk0-f41.google.com with SMTP id na10so2449431bkb.14 for ; Tue, 03 Sep 2013 19:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yewTSh1d7hcEg/Q0zpgEH0aeKEaEWBRef34qA0rCipM=; b=DJv4w8h8e/7/I6+ol3Pun2XqmmAlUvOQso4SnvMJPgZ5MF0i5P+LYCbjjhLwDm+UaF lv1lJAamE7YrLGS6GWLovb7Kur7qx9ikkrUU/06wkSzVWMGLYHkiWGG/0N/naKAjBdDS bMl5K3uaVUVlblxxGAjgXyMRpfyT4coVJbhjCT/FzpEbwT8cyJx2Wn7H1iUfpl+nEc55 gc3oLEODx/GnJn/epkY8/EgpS3XwAegxH5KcFauLswFWkonNo5e+mbESmRdDVid0vdjA MW7q8JiOI8nyV2gncvLY96SU0w9WT0XqspFg34Ti709DaZSNXuRmXIHgtUa/bXJBnPIA QBIA== MIME-Version: 1.0 X-Received: by 10.204.71.133 with SMTP id h5mr171782bkj.0.1378261998460; Tue, 03 Sep 2013 19:33:18 -0700 (PDT) Received: by 10.205.18.193 with HTTP; Tue, 3 Sep 2013 19:33:18 -0700 (PDT) In-Reply-To: <20130904022533.B05A239302EF@drugs.dv.isc.org> References: <20130904022533.B05A239302EF@drugs.dv.isc.org> Date: Wed, 4 Sep 2013 14:33:18 +1200 Message-ID: From: Andy Wilson To: Mark Andrews Content-Type: multipart/alternative; boundary=047d7b8747cad39f7104e585a0e8 Cc: dane@ietf.org Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 02:33:21 -0000 --047d7b8747cad39f7104e585a0e8 Content-Type: text/plain; charset=UTF-8 I would agree with Mark. It's based on local policy ultimately. One would assume if a TLSA RR exists for a host on port 25, a certificate will be presented. STARTTLS would be handled a little differently of course (send a EHLO first etc. instead of ClientHello for TLS) but this is down to implementation. On 4 September 2013 14:25, Mark Andrews wrote: > > In message Xdru_KOFKRs-o1Pdnj6g@mail.gmail.com>, =?UTF-8?B?SWFuIEZldHRlI > CjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= writes: > > --===============5680513047430573670== > > Content-Type: multipart/alternative; > boundary=047d7bd7689804b84f04e584c415 > > > > --047d7bd7689804b84f04e584c415 > > Content-Type: text/plain; charset=UTF-8 > > > > RFC6698 contemplates the use of DANE records with SMTP. (_25._ > > tcp.mail.example.com is given as an example in the document). However, > one > > of the problems with SMTP is that it's not known to the sending server > > whether the receiving server supports STARTTLS a-priori. (One connects to > > the SMTP server, issues an EHLO command and is informed whether the > server > > supports STARTTLS or not. This can be trivially removed by a malicious > > MITM). Similar downgrade vulnerabilities exist for other protocols that > > rely on STARTTLS-type commands. > > > > DANE lets one specify what certificate is acceptable if a certificate is > > required, but not whether a certificate should be expected. I'm curious > to > > know if there's any appetite to allow this information to be conveyed > via a > > DANE record. For instance, again with SMTP as an example, one can > remember > > whether STARTTLS was offered on a previous connection to try to protect > > against downgrade attacks, but this is rather brittle, doesn't work well > > for new / long-tail hosts, and it's not clear in such a scenario if > someone > > simply disabled STARTTLS intentionally or if it's actually representative > > of an attack. > > > > One could use DANE to convey, for STARTTLS-type services, whether a > client > > should treat the lack of encryption support as a fatal error or not. One > > possible way to achieve this would be using the high bit of the > certificate > > usage octet to specify whether the TLSA is advisory ("if you get a > > certificate from me, it must match in the following manner") or mandatory > > ("I offer certificates that match in the following form, if you are > unable > > to obtain a certificate from me treat it as a hard failure"). I'm not > stuck > > on the particulars of which bit gets used or where it gets implemented, > > other than it would be nice (from my perspective) if it could be combined > > in an existing record rather than having to fetch yet another RR for just > > one bit of information. > > > > Fundamentally, the problem I'm trying to solve is the problem of > downgrade > > attacks against protocols like SMTP that advertise their STARTTLS > > capability in the clear. It seems like DANE, where one is specifying a > > policy about how to validate a TLS connection, might be a reasonable fit > > for information about whether STARTTLS (be it POP3/IMAP, FTP, XMPP, LDAP > or > > any other protocol) should be expected or not. I'm not sure if this has > > been considered or not. > > > > Thoughts welcome. > > -Ian > > The presence of the rrset prevents the downgrade attack. A validating > resolver can detect when there should be a RRset but it is not being > returned. The STARTTLS client then expects to see STARTTLS in the > EHLO response if it has a TLSA RRset. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Regards Andy --047d7b8747cad39f7104e585a0e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would agree with Mark.
It's based on local polic= y ultimately. One would assume if a TLSA RR exists for a host on port 25, a= certificate will be presented.
STARTTLS would be handled a littl= e differently of course (send a EHLO first etc. instead of ClientHello for = TLS) but this is down to implementation.


On 4 Se= ptember 2013 14:25, Mark Andrews <marka@isc.org> wrote:

In message <CAF4kx8fSVL5UouVgJubkrNj=3DBJAyV=3DXdru_KOFKRs-o1Pdnj6g@mail.gmail.com>, = =3D?UTF-8?B?SWFuIEZldHRlI
CjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=3D writes:
> --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D5680513047430573670=3D= =3D
> Content-Type: multipart/alternative; boundary=3D047d7bd7689804b84f04e5= 84c415
>
> --047d7bd7689804b84f04e584c415
> Content-Type: text/plain; charset=3DUTF-8
>
> RFC6698 contemplates the use of DANE records with SMTP. (_25._
> tcp.mail.exa= mple.com is given as an example in the document). However, one
> of the problems with SMTP is that it's not known to the sending se= rver
> whether the receiving server supports STARTTLS a-priori. (One connects= to
> the SMTP server, issues an EHLO command and is informed whether the se= rver
> supports STARTTLS or not. This can be trivially removed by a malicious=
> MITM). Similar downgrade vulnerabilities exist for other protocols tha= t
> rely on STARTTLS-type commands.
>
> DANE lets one specify what certificate is acceptable if a certificate = is
> required, but not whether a certificate should be expected. I'm cu= rious to
> know if there's any appetite to allow this information to be conve= yed via a
> DANE record. For instance, again with SMTP as an example, one can reme= mber
> whether STARTTLS was offered on a previous connection to try to protec= t
> against downgrade attacks, but this is rather brittle, doesn't wor= k well
> for new / long-tail hosts, and it's not clear in such a scenario i= f someone
> simply disabled STARTTLS intentionally or if it's actually represe= ntative
> of an attack.
>
> One could use DANE to convey, for STARTTLS-type services, whether a cl= ient
> should treat the lack of encryption support as a fatal error or not. O= ne
> possible way to achieve this would be using the high bit of the certif= icate
> usage octet to specify whether the TLSA is advisory ("if you get = a
> certificate from me, it must match in the following manner") or m= andatory
> ("I offer certificates that match in the following form, if you a= re unable
> to obtain a certificate from me treat it as a hard failure"). I&#= 39;m not stuck
> on the particulars of which bit gets used or where it gets implemented= ,
> other than it would be nice (from my perspective) if it could be combi= ned
> in an existing record rather than having to fetch yet another RR for j= ust
> one bit of information.
>
> Fundamentally, the problem I'm trying to solve is the problem of d= owngrade
> attacks against protocols like SMTP that advertise their STARTTLS
> capability in the clear. It seems like DANE, where one is specifying a=
> policy about how to validate a TLS connection, might be a reasonable f= it
> for information about whether STARTTLS (be it POP3/IMAP, FTP, XMPP, LD= AP or
> any other protocol) should be expected or not. I'm not sure if thi= s has
> been considered or not.
>
> Thoughts welcome.
> -Ian

The presence of the rrset prevents the downgrade attack. =C2=A0= A validating
resolver can detect when there should be a RRset but it is not being
returned. =C2=A0The STARTTLS client then expects to see STARTTLS in the
EHLO response if it has a TLSA RRset.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2= 9871 4742 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 INTE= RNET: marka@isc.org
_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



-- Regards

Andy
--047d7b8747cad39f7104e585a0e8-- From viktor1dane@dukhovni.org Tue Sep 3 20:21:53 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDAA21F9675 for ; Tue, 3 Sep 2013 20:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wsjKQipa3+L for ; Tue, 3 Sep 2013 20:21:50 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id E414921F95DD for ; Tue, 3 Sep 2013 20:21:49 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DF2B42AB07A; Wed, 4 Sep 2013 03:21:46 +0000 (UTC) Date: Wed, 4 Sep 2013 03:21:46 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130904032143.GY29796@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 03:21:54 -0000 On Tue, Sep 03, 2013 at 06:31:33PM -0700, Ian Fette (????????) wrote: > However, one of the problems with SMTP is that it's not known to > the sending server whether the receiving server supports STARTTLS > a-priori. Similar downgrade vulnerabilities exist for other > protocols that rely on STARTTLS-type commands. This is well understood, and downgrade resistance is built into: https://tools.ietf.org/html/draft-dukhovni-smtp-opportunistic-tls-01 as well as the earlier: https://tools.ietf.org/html/draft-ietf-dane-srv-02 and not surprisingly into the Postfix DANE implementation, currently available in the 2.11-20130825 snapshot from www.postfix.org or from the Debian experimental package repository. -- Viktor. From ifette@google.com Tue Sep 3 20:59:30 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7A321E815A for ; Tue, 3 Sep 2013 20:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjhS9Eo97hWk for ; Tue, 3 Sep 2013 20:59:29 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 84D4D21E8170 for ; Tue, 3 Sep 2013 20:59:25 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id m16so9584953ieq.24 for ; Tue, 03 Sep 2013 20:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=s4V6bnay0dQu5RcxAu9VK3IQux81IUKk3oYz9fw9r40=; b=l454KYL3t6TdbaPWXYz5VBdw+qAg2YCJB3H3JamsZdG9GTANXd5laFHPXzx5NWUfiM xxHWv7x1cXy9IOqRILvrYJuX+7ajclQhNq1X3OyaUaxfGY0n44Du4bII3WUd43gCbtGM ZLewTGg7bmRJFqscb0JgWiqUmAMUd78sZUC0aStKDfH3ELCpIPGbukPYX/JxHN41cLOZ VTgc3b0gph2ULo5Qi2NmgGtQM4vSMfWuaL3OsCAj1lg4NygAOA8aSQPRsNTXBmm63yTL oPggOCYYetLxxG5CP21pw27PHKZeF6JgA3mVwTCXK3EULU9uHPurRxxQoeW3rvZ+DNuA uQOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=s4V6bnay0dQu5RcxAu9VK3IQux81IUKk3oYz9fw9r40=; b=S/pc7+5Ds2DVz0mKFTqa+AqFG3EqLfrrtHOyGTbU0kdnUU/tE6DFn4EZ0Pbw6zCqds 7IAPMnWz34fFsYFDVq+kg+uwqKQaNRSBjW+WSXY7lbqBcokai/lUtumFL/nlrP7pBlWp CJUTUeQwLNrXiZZ+KIHDT5gHf7ptfa4QdBDzfGvAjmp4j3eYHPOCX+WpBbNQZKSIiN6u 4tuyzlK3deNR+ulWF8Y2OmaSzLCEIw1/FXo0iWs5qoAlKbG7J5aTuSPmZ2eZ3RDU5DUH GsuN9mh96nf9SBgm+esg5bT5slQAZilVlLCLiIqUXd8PGL432i7urJKSnm3xv1u+CAe7 VypQ== X-Gm-Message-State: ALoCoQky8WU9f5NT7lhHEyOnT4BW1SoGfyjCwVrt9pwH0Ob4VAviNL838HmtUqQ4E5Wb8iPT+qMdxmJCY9xw1qHXK+CW/VhITrP3ih3IhBeJLKyVnQRdSWrhtfTSil4SpWw4MFEdq8aKc2XyQkqAj1XQn0KMJMQbpIDj00nDuecv4d0k2MkU+upJPlaLDLvfR/MARzBgkn6t MIME-Version: 1.0 X-Received: by 10.50.108.71 with SMTP id hi7mr272785igb.59.1378267164986; Tue, 03 Sep 2013 20:59:24 -0700 (PDT) Received: by 10.231.161.70 with HTTP; Tue, 3 Sep 2013 20:59:24 -0700 (PDT) In-Reply-To: <20130904022533.B05A239302EF@drugs.dv.isc.org> References: <20130904022533.B05A239302EF@drugs.dv.isc.org> Date: Tue, 3 Sep 2013 20:59:24 -0700 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: Mark Andrews Content-Type: multipart/alternative; boundary=089e0149c4a0c6718704e586d44f Cc: dane@ietf.org Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ifette@google.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 03:59:30 -0000 --089e0149c4a0c6718704e586d44f Content-Type: text/plain; charset=UTF-8 " The STARTTLS client then expects to see STARTTLS in the EHLO response if it has a TLSA RRset." - this wasn't clear from my reading of the RFC. Where is that specified, or well understood? If that's a safe assumption, that certainly simplifies things, but this was not clear from my (admittedly hurried) reading of the RFC. On Tue, Sep 3, 2013 at 7:25 PM, Mark Andrews wrote: > > In message Xdru_KOFKRs-o1Pdnj6g@mail.gmail.com>, =?UTF-8?B?SWFuIEZldHRlI > CjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= writes: > > --===============5680513047430573670== > > Content-Type: multipart/alternative; > boundary=047d7bd7689804b84f04e584c415 > > > > --047d7bd7689804b84f04e584c415 > > Content-Type: text/plain; charset=UTF-8 > > > > RFC6698 contemplates the use of DANE records with SMTP. (_25._ > > tcp.mail.example.com is given as an example in the document). However, > one > > of the problems with SMTP is that it's not known to the sending server > > whether the receiving server supports STARTTLS a-priori. (One connects to > > the SMTP server, issues an EHLO command and is informed whether the > server > > supports STARTTLS or not. This can be trivially removed by a malicious > > MITM). Similar downgrade vulnerabilities exist for other protocols that > > rely on STARTTLS-type commands. > > > > DANE lets one specify what certificate is acceptable if a certificate is > > required, but not whether a certificate should be expected. I'm curious > to > > know if there's any appetite to allow this information to be conveyed > via a > > DANE record. For instance, again with SMTP as an example, one can > remember > > whether STARTTLS was offered on a previous connection to try to protect > > against downgrade attacks, but this is rather brittle, doesn't work well > > for new / long-tail hosts, and it's not clear in such a scenario if > someone > > simply disabled STARTTLS intentionally or if it's actually representative > > of an attack. > > > > One could use DANE to convey, for STARTTLS-type services, whether a > client > > should treat the lack of encryption support as a fatal error or not. One > > possible way to achieve this would be using the high bit of the > certificate > > usage octet to specify whether the TLSA is advisory ("if you get a > > certificate from me, it must match in the following manner") or mandatory > > ("I offer certificates that match in the following form, if you are > unable > > to obtain a certificate from me treat it as a hard failure"). I'm not > stuck > > on the particulars of which bit gets used or where it gets implemented, > > other than it would be nice (from my perspective) if it could be combined > > in an existing record rather than having to fetch yet another RR for just > > one bit of information. > > > > Fundamentally, the problem I'm trying to solve is the problem of > downgrade > > attacks against protocols like SMTP that advertise their STARTTLS > > capability in the clear. It seems like DANE, where one is specifying a > > policy about how to validate a TLS connection, might be a reasonable fit > > for information about whether STARTTLS (be it POP3/IMAP, FTP, XMPP, LDAP > or > > any other protocol) should be expected or not. I'm not sure if this has > > been considered or not. > > > > Thoughts welcome. > > -Ian > > The presence of the rrset prevents the downgrade attack. A validating > resolver can detect when there should be a RRset but it is not being > returned. The STARTTLS client then expects to see STARTTLS in the > EHLO response if it has a TLSA RRset. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > --089e0149c4a0c6718704e586d44f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
" The STARTTLS client then expects to see STARTTLS in= the
EHLO response if it has a TLSA RRset." - this wasn't clea= r from my reading of the RFC. Where is that specified, or well understood? = If that's a safe assumption, that certainly simplifies things, but this= was not clear from my (admittedly hurried) reading of the RFC.


On Tue,= Sep 3, 2013 at 7:25 PM, Mark Andrews <marka@isc.org> wrote:
=

In message <CAF4kx8fSVL5UouVgJubkrNj=3DBJAyV=3DXdru_KOFKRs-o1Pdnj6g@mail.gmail.com>, = =3D?UTF-8?B?SWFuIEZldHRlI
CjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=3D writes:
> --=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D5680513047430573670=3D= =3D
> Content-Type: multipart/alternative; boundary=3D047d7bd7689804b84f04e5= 84c415
>
> --047d7bd7689804b84f04e584c415
> Content-Type: text/plain; charset=3DUTF-8
>
> RFC6698 contemplates the use of DANE records with SMTP. (_25._
> tcp.mail.exa= mple.com is given as an example in the document). However, one
> of the problems with SMTP is that it's not known to the sending se= rver
> whether the receiving server supports STARTTLS a-priori. (One connects= to
> the SMTP server, issues an EHLO command and is informed whether the se= rver
> supports STARTTLS or not. This can be trivially removed by a malicious=
> MITM). Similar downgrade vulnerabilities exist for other protocols tha= t
> rely on STARTTLS-type commands.
>
> DANE lets one specify what certificate is acceptable if a certificate = is
> required, but not whether a certificate should be expected. I'm cu= rious to
> know if there's any appetite to allow this information to be conve= yed via a
> DANE record. For instance, again with SMTP as an example, one can reme= mber
> whether STARTTLS was offered on a previous connection to try to protec= t
> against downgrade attacks, but this is rather brittle, doesn't wor= k well
> for new / long-tail hosts, and it's not clear in such a scenario i= f someone
> simply disabled STARTTLS intentionally or if it's actually represe= ntative
> of an attack.
>
> One could use DANE to convey, for STARTTLS-type services, whether a cl= ient
> should treat the lack of encryption support as a fatal error or not. O= ne
> possible way to achieve this would be using the high bit of the certif= icate
> usage octet to specify whether the TLSA is advisory ("if you get = a
> certificate from me, it must match in the following manner") or m= andatory
> ("I offer certificates that match in the following form, if you a= re unable
> to obtain a certificate from me treat it as a hard failure"). I&#= 39;m not stuck
> on the particulars of which bit gets used or where it gets implemented= ,
> other than it would be nice (from my perspective) if it could be combi= ned
> in an existing record rather than having to fetch yet another RR for j= ust
> one bit of information.
>
> Fundamentally, the problem I'm trying to solve is the problem of d= owngrade
> attacks against protocols like SMTP that advertise their STARTTLS
> capability in the clear. It seems like DANE, where one is specifying a=
> policy about how to validate a TLS connection, might be a reasonable f= it
> for information about whether STARTTLS (be it POP3/IMAP, FTP, XMPP, LD= AP or
> any other protocol) should be expected or not. I'm not sure if thi= s has
> been considered or not.
>
> Thoughts welcome.
> -Ian

The presence of the rrset prevents the downgrade attack. =C2=A0= A validating
resolver can detect when there should be a RRset but it is not being
returned. =C2=A0The STARTTLS client then expects to see STARTTLS in the
EHLO response if it has a TLSA RRset.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2= 9871 4742 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 INTE= RNET: marka@isc.org

--089e0149c4a0c6718704e586d44f-- From viktor1dane@dukhovni.org Tue Sep 3 21:02:29 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1658C21F9AA9 for ; Tue, 3 Sep 2013 21:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xflr00nQlGZv for ; Tue, 3 Sep 2013 21:02:24 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 01B6121E8132 for ; Tue, 3 Sep 2013 21:02:24 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B13072AB081; Wed, 4 Sep 2013 04:02:22 +0000 (UTC) Date: Wed, 4 Sep 2013 04:02:22 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130904040222.GZ29796@mournblade.imrryr.org> References: <20130904022533.B05A239302EF@drugs.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 04:02:29 -0000 On Tue, Sep 03, 2013 at 08:59:24PM -0700, Ian Fette (????????) wrote: > " The STARTTLS client then expects to see STARTTLS in the > EHLO response if it has a TLSA RRset." - this wasn't clear from my reading > of the RFC. Where is that specified, or well understood? If that's a safe > assumption, that certainly simplifies things, but this was not clear from > my (admittedly hurried) reading of the RFC. See my earlier reply. Downgrade-resistant opportunistic TLS is out of scope for RFC 6698, this subject will be covered in various application-specific documents that specify how DANE is to be used for the protocol in question. -- Viktor. From ifette@google.com Tue Sep 3 21:13:33 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7A521E805F for ; Tue, 3 Sep 2013 21:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvAojs9eRDvH for ; Tue, 3 Sep 2013 21:13:33 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id EF71621E805D for ; Tue, 3 Sep 2013 21:13:32 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id x14so11683829ief.25 for ; Tue, 03 Sep 2013 21:13:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=xlWEaI/rSUZAecXDgo7n3Ve6klyJmJnl4y6T9iYeF1o=; b=Z5lRHjSF8/HJ2B6sbSGpKzWH51pR3j11fFeDJc657oxHqbhMnY51RkXxvrWN2ByX06 h2csug8NEmw6B+MdkIUY4RNMyvmjD4/ZX0SYVW9Si3YqZxtnp+FkSc2vkiCZD4vnSWyG R6RWY1ulbxtEbdON1InPYfhIYt2508lnIsQl74jlMzTlqdqeREXg8DrQ5kmyjHSupRLE OmriUOxQvm3sjW/dsPTShkME7L9VeGYVo2q6uZHh/WnxgnrU5Md/AItDAc4ys23Bq6T7 0P4ueBHblI6D1APx4OE5GSkQDUKHhQ7+gMZsi/40GZaPm5hGKyfhjUQaPlpzo0Jo/FuK M1aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=xlWEaI/rSUZAecXDgo7n3Ve6klyJmJnl4y6T9iYeF1o=; b=iDmCuQm6pOc7uEwsHfc14ys38F0J2VjIJbrq+AyinBmtDLUrLS+cEIHmvbNTcTgIbS Q6NkejovFTdMOoAKXMxrNinSkvjE+gCT/bpVlNJTznRXqF9ORXxSjepZ5Vef+uWtgS0T t1VihKqUUMGebgbLkx+7J8m1B/eSPSIBOAOdAujlMV6Izffpgls/kBoz2Hpp93NuQQf/ 5pbpkOpuG+hLWX9W9uMcEmndhjnniGKZolbzV0N9OF/95LGKRxpKgU43fhfqLavPQ25W nu3MyC61/DIrSIUB91SM3W20I3mmhlIJaVxsda1R7ePyTq0Ofmx22SIA39mT3UWm8amj Pv4A== X-Gm-Message-State: ALoCoQkhYK5LPF8jmNVS+2XBJSyT0l3wrGKnKprvmpDoyiyYpdd6FvpCNLFVQJiA7C18zT9o/tkbEGLOtlUd60uCHpBvNvPr8SL8X/ZhuPwm1ECDuUgmfTBWQ+K7OwYlVtZpJV7Yz3jHLKI9grEFbJzdsW7Tk7D6IubMrENTq1mHCo2V0TTlQ3kUvIpNgdDmnTyIPFwoncav MIME-Version: 1.0 X-Received: by 10.50.120.6 with SMTP id ky6mr308695igb.58.1378268012106; Tue, 03 Sep 2013 21:13:32 -0700 (PDT) Received: by 10.231.161.70 with HTTP; Tue, 3 Sep 2013 21:13:32 -0700 (PDT) In-Reply-To: <20130904040222.GZ29796@mournblade.imrryr.org> References: <20130904022533.B05A239302EF@drugs.dv.isc.org> <20130904040222.GZ29796@mournblade.imrryr.org> Date: Tue, 3 Sep 2013 21:13:32 -0700 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: dane@ietf.org Content-Type: multipart/alternative; boundary=047d7b874c9244779504e58707ad Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ifette@google.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 04:13:33 -0000 --047d7b874c9244779504e58707ad Content-Type: text/plain; charset=UTF-8 Viktor, I was just getting to your email :) Thanks for pointing out https://tools.ietf.org/html/draft-dukhovni-smtp-opportunistic-tls-01 - something like this seems quite useful in codifying the expectation of STARTTLS support for SMTP (or other protocols) given that a TLSA record exists. I'm not sure that I agree with everything in that draft, particularly the bit about not using certificate usage 0/1, as this is precisely what we would do for Gmail most likely (we operate our own CA, and for instance in Chrome and via http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08 we typically pin google.com to a set of CA certificates, not leaf certificates, as the leaf certificates can rotate more frequently based on operational needs but our CA cert changes much more rarely.) It's not clear to me why requiring PKIX validation in that case would be an unreasonable expectation. Indeed, most of the certs I see from a random inspection of servers offering STARTTLS (google, t-online, web.de etc) include a full certificate chain to a public CA. Other than that nit though, I would love to see that draft advance. -Ian On Tue, Sep 3, 2013 at 9:02 PM, Viktor Dukhovni wrote: > On Tue, Sep 03, 2013 at 08:59:24PM -0700, Ian Fette (????????) wrote: > > > " The STARTTLS client then expects to see STARTTLS in the > > EHLO response if it has a TLSA RRset." - this wasn't clear from my > reading > > of the RFC. Where is that specified, or well understood? If that's a safe > > assumption, that certainly simplifies things, but this was not clear from > > my (admittedly hurried) reading of the RFC. > > See my earlier reply. > > Downgrade-resistant opportunistic TLS is out of scope for RFC 6698, > this subject will be covered in various application-specific documents > that specify how DANE is to be used for the protocol in question. > > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --047d7b874c9244779504e58707ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Viktor,

I was just getting to your emai= l :) Thanks for pointing out https://tools.ietf.org/html/draft-dukhov= ni-smtp-opportunistic-tls-01 - something like this seems quite useful i= n codifying the expectation of STARTTLS support for SMTP (or other protocol= s) given that a TLSA record exists.

I'm not sure that I agree with everything in that d= raft, particularly the bit about not using certificate usage 0/1, as this i= s precisely what we would do for Gmail most likely (we operate our own CA, = and for instance in Chrome and via=C2=A0http://tools.ietf.org/html/draft-ietf-= websec-key-pinning-08=C2=A0we typically pin google.com to a set of CA certificates, not leaf certificates, as th= e leaf certificates can rotate more frequently based on operational needs b= ut our CA cert changes much more rarely.) It's not clear to me why requ= iring PKIX validation in that case would be an unreasonable expectation. In= deed, most of the certs I see from a random inspection of servers offering = STARTTLS (google, t-online, web.de etc) inclu= de a full certificate chain to a public CA. Other than that nit though, I w= ould love to see that draft advance.

-Ian


On Tue, Sep 3, 2013 at 9:02 PM, Viktor Dukhovni <viktor1dane@dukhovni.org> wrote:
On Tue, Sep 03, 2013 at 08= :59:24PM -0700, Ian Fette (????????) wrote:

> " The STARTTLS client then expects to see STARTTLS in the
> EHLO response if it has a TLSA RRset." - this wasn't clear fr= om my reading
> of the RFC. Where is that specified, or well understood? If that's= a safe
> assumption, that certainly simplifies things, but this was not clear f= rom
> my (admittedly hurried) reading of the RFC.

See my earlier reply.

Downgrade-resistant opportunistic TLS is out of scope for RFC 6698,
this subject will be covered in various application-specific documents
that specify how DANE is to be used for the protocol in question.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.
_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane

--047d7b874c9244779504e58707ad-- From sca@andreasschulze.de Tue Sep 3 23:33:03 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D6611E8122 for ; Tue, 3 Sep 2013 23:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoGKIAt92hjM for ; Tue, 3 Sep 2013 23:32:59 -0700 (PDT) Received: from mout.andreasschulze.de (mout.andreasschulze.de [84.201.4.158]) by ietfa.amsl.com (Postfix) with ESMTP id E689411E80C5 for ; Tue, 3 Sep 2013 23:32:58 -0700 (PDT) X-Received: line deleted by mout X-Received: line deleted by mout DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andreasschulze.de; s=GzhbMIk; t=1378276373; atpsh=sha256; atps=andreasschulze.de; r=y; bh=0EWJfFu/3toBwbi4/IHHNkkRpbHcIvdgxfUbsk8UYAg=; h=Date:From:To:Subject:References:In-Reply-To; z=Date:=20Wed,=2004=20Sep=202013=2008:32:52=20+0200|From:=20Andreas =20Schulze=20|To:=20dane@ietf.org|Subject:= 20Re:=20[dane]=20DANE=20and=20STARTTLS=20-=20indication=20of=20ava ilability=20of=0D=0A=20encryption|References:=20=0D=0A=20<20 130904032143.GY29796@mournblade.imrryr.org>|In-Reply-To:=20<201309 04032143.GY29796@mournblade.imrryr.org>; b=R8YiUDilkkE21+AgyjuET57dRj1nW4yytVzRB2Xz4+x2AGXu64zwG3T06PUZD8Aem ak9uiF/S5ozTZnO0pfIHhaML1XTeuEsivFUfeWioSoUofhQGuRtbxZMdF6Jb5DpOC5 uxI+mGfBkb7x6BUb4jwAJSGPO034tJh5Zkn9mMO7fGBf8U/RscHO81cTHkB83OdoKQ u2dGVZSZBl+hklhuMlfKNb5JYfs8OM5/1tFp1ESwCMp5GFh0xbIQEncUQ0fWtB6TYC OWhmTzVZ/uVVpvWQxoUVHtL/oPTTXchJsXKWX8phLIGoLYgAZJZCWXXY831GHMeigq yLPmHMn88bodWCw6TRRAhh8GQmG3KEFydqCimfCY91OG6igwT3dh6of5QFuhM4zBtr /BjkuCXvW7UJBYfqYnewUrYmyqoGn7IEMLnhHMi64hqO17NZuhWTbtqq/kMEqE7kgy tdMAISWnlq3dkGZaZ3x2Dna1mbQ8YPDZYO3fxQk0AQbqoEemRmSR4XVR+e80RkAYhK h1uoD0ZZVPz4SWCYQ86g62sFVThFuWm+ufsPs0Xw2QhTOO3dykPtg2BkX0XWlmWNMS fbNSaWaaqb8NxvB4jmw11zBhD+V7FWdQ424hpkQwhSCeS4JKYiT7Uvy0PUSWr1d0Wu ZVgwvUfxvFoGiZEfAtdiI0C0= X-Received: line deleted by mout Date: Wed, 04 Sep 2013 08:32:52 +0200 Message-ID: <20130904083252.Horde.ExPIQ_DwiI8iS_Lp-UFr_A1@horde.andreasschulze.de> From: Andreas Schulze To: dane@ietf.org References: <20130904032143.GY29796@mournblade.imrryr.org> In-Reply-To: <20130904032143.GY29796@mournblade.imrryr.org> User-Agent: Internet Messaging Program (IMP) H5 (6.1.4) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 06:33:03 -0000 Zitat von Viktor Dukhovni : > and not surprisingly into the Postfix DANE implementation, currently > available in the 2.11-20130825 snapshot from www.postfix.org reading this I tried to verify it. and: it works! I have an smtp server with an associated dane record. A client could establish a trusted tls session without knowing any root certificates ( empty smtp_tls_CAfile and smtp_tls_CApath ) The trust based only on dnssec and dane. If I now disable STARTTLS at the server, the client do not send the message without TLS: "TLS is required, but was not offered by host ..." That's a usable downgrade prevention. Thanks! Andreas From ondrej.sury@nic.cz Wed Sep 4 05:38:24 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD5321E80B7 for ; Wed, 4 Sep 2013 05:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tdsa2WVVj25B for ; Wed, 4 Sep 2013 05:38:23 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id E146621E80BE for ; Wed, 4 Sep 2013 05:38:04 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:7134:2aa0:fa00:7f4f] (unknown [IPv6:2001:1488:ac14:1400:7134:2aa0:fa00:7f4f]) by mail.nic.cz (Postfix) with ESMTPSA id D680713F6C1; Wed, 4 Sep 2013 14:38:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1378298281; bh=qsiUCYmRuNHuaUAi00EKKKWx4TTRoF4BjX5Md+V8bac=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=JgZSlrWixEkhM4RtBXwEvK94Sg+FcIf88S/vL8oBhSEAreRxURNJPoAO/8hU6iHij dkOg1fC9D04gKR865oj38da2wnlwQm92Omwe+eyXmqwJyacWfxeWIcUjvIe39juJQ6 lNnVnYiB+knPtKBaQRO5yJpUq6iHMQHnBoy4sJss= Content-Type: multipart/signed; boundary="Apple-Mail=_77CA8A23-9C09-4D3F-B246-76D3B7BF3B7C"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Wed, 4 Sep 2013 14:38:01 +0200 Message-Id: <35A92E9C-75BA-45A6-A458-F75E741FCA61@nic.cz> References: <20130904022533.B05A239302EF@drugs.dv.isc.org> <20130904040222.GZ29796@mournblade.imrryr.org> To: ifette@google.com X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 12:38:24 -0000 --Apple-Mail=_77CA8A23-9C09-4D3F-B246-76D3B7BF3B7C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ian, On 4. 9. 2013, at 6:13, Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3= =82=A7=E3=83=83=E3=83=86=E3=82=A3) wrote: > I'm not sure that I agree with everything in that draft, particularly = the bit about not using certificate usage 0/1, as this is precisely what = we would do for Gmail most likely (we operate our own CA, and for = instance in Chrome and via=20 You need certificate usage 2 for your own CA and the mapping 0->2, 1->3 = (see sections 2.2.1.3 and 2.2.1.4) ensures that your DANE record with = certificate usage 0 SHOULD be used even in case that you use a well = established CA. > http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08 we = typically pin google.com to a set of CA certificates, not leaf = certificates, as the leaf certificates can rotate more frequently based = on operational needs but our CA cert changes much more rarely.) It's not = clear to me why requiring PKIX validation in that case would be an = unreasonable expectation. I guess this comes from operational experiences, currently the SMTP = servers don't do any validation on the certificates and it would be a = great leap to take, so it's better to start with opportunistic TLS than = enforcing the users to do full PKIX. This might change in the future in some future draft, but Viktor's draft = would be a huge leap for SMTP encryption. > Indeed, most of the certs I see from a random inspection of servers = offering STARTTLS (google, t-online, web.de etc) include a full = certificate chain to a public CA. Other than that nit though, I would = love to see that draft advance. O. -- Ond=C5=99ej Sur=C3=BD -- Chief Science Officer ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- --Apple-Mail=_77CA8A23-9C09-4D3F-B246-76D3B7BF3B7C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlInKakACgkQYYkZMXof23x80QCfYZG/EcI78czyNMmtExl8IZDj d/oAn0V+NfY826nxX3C/6U1fLY9iBaj/ =owbq -----END PGP SIGNATURE----- --Apple-Mail=_77CA8A23-9C09-4D3F-B246-76D3B7BF3B7C-- From viktor1dane@dukhovni.org Wed Sep 4 07:46:07 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A160411E81D1 for ; Wed, 4 Sep 2013 07:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.571 X-Spam-Level: X-Spam-Status: No, score=-0.571 tagged_above=-999 required=5 tests=[AWL=-1.878, BAYES_00=-2.599, FAKE_REPLY_C=2.012, J_CHICKENPOX_32=0.6, MARKETING_PARTNERS=1.295] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmI-u8OsUUpO for ; Wed, 4 Sep 2013 07:46:03 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 9888511E81C8 for ; Wed, 4 Sep 2013 07:45:56 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E70662AABCD; Wed, 4 Sep 2013 14:45:49 +0000 (UTC) Date: Wed, 4 Sep 2013 14:45:49 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130904144549.GA29796@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <35A92E9C-75BA-45A6-A458-F75E741FCA61@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 14:46:07 -0000 On Tue, Sep 03, 2013 at 09:13:32PM -0700, Ian Fette (????????) wrote: > I'm not sure that I agree with everything in that draft, particularly the > bit about not using certificate usage 0/1, as this is precisely what we > would do for Gmail most likely (we operate our own CA, and for instance in > Chrome and via http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08 we > typically pin google.com to a set of CA certificates, not leaf > certificates, as the leaf certificates can rotate more frequently based on > operational needs but our CA cert changes much more rarely.) Do not confuse non-support of 0/1 with not supporting CA-anchored certificate chains. In my SMTP draft the latter are fully supported via usage 2. The difference is that the SMTP client is *not expected* to have any prior knowledge of a set of CAs trusted collectively to authenticate the entire Internet. Any such set of CAs is either incomplete (mail delivery to some sites fails) or contains CAs one should generally trust (one can't be sure exactly which ones those are). Think of this as a variant of Goedel's incompleteness theorem to trusted CAs as a set of axioms for Internet security. :-) Furthermore, since sites are allowed to publish self-issued certificate associations (e.g. to a 3 1 1 leaf public key, or to a 2 1 1 domain issued CA), any attacker who compromises a domain's DNS can substitute any TLSA records that require PKIX (usage 0 or 1) with records that don't (2 or 3). In fact since you observed the trivial downgrade attacks on SMTP without DANE, if such an attacker can also MITM the client, he can simply suppress the TLSA records, an not send STARTTLS. The client then sends mail in the clear. Most MTAs do not ship with a complete (inconsistent) set of CAs. Since unlike a browser there is no interactive user to click "OK" when PKIX verification fails, requiring PKIX would lead to degradation in reliability of service. Some MTAs are configured with a short of lists CAs the administrator actually trusts (incomplete), they use this for manually configured PKIX validated delivery to selected partner sites, but this does not scale to the Internet, and is not dependent on DANE. Non-support of certificate usages 0/1 in the SMTP incarnation of DANE is key to the interoperability of the protocol with existing systems and flows naturally out of a thoughtful security analysis of the protocol. If you publish usage 0, you will not interoperate with Postfix, which accounts for a large fraction of the MTAs on the Internet. Google is of course free to configure its own SMTP clients with prior knowledge of Google's CA, so that mail delivery internal to Google is protected by additional client-side security policy. Nothing in my draft precludes this, but no such prior configuration scales to the Internet at large. You should perhaps have a chat with Warren Kumari (one of the chairs of the DANE working group, and a Google employee I believe). If you want to include me in the conversation, let me know and I may be able to join you in a conference call. > It's not clear > to me why requiring PKIX validation in that case would be an unreasonable > expectation. Indeed, most of the certs I see from a random inspection of > servers offering STARTTLS (google, t-online, web.de etc) include a full > certificate chain to a public CA. Other than that nit though, I would love > to see that draft advance. You've only looked at the major providers. The majority of domains that offer SMTP STARTTLS have self-signed certificates. In any case SMTP clients (even at large Fortune 500 companies that pay for certs issued by public CAs) almost never check the CAs of other SMTP servers except by bilateral prior arrangement. When I worked for Morgan Stanley, we were pretty much the only company that actually went beyond enforcing mandatory use of TLS and configured verification of the peer certificate. Most of our business partners were content to require "encryption" without any authentication. Doing PKIX with SMTP is hard in any case because MX indirection (sans DNSSEC) makes it impossible to robustly determine what names are acceptable in the peer's certificate. So bottom line, my draft is carefully thought out, and the requirement to NOT publish usage 0/1 is very unlikely to change. This is not a draft built in a vacuum, hoping for eventual adoption by some implementor. Rather this is a draft that adheres to an actual implementation in Postfix, and soon (when the relevant Exim developer is able to take time to make it happen) also in Exim. The draft documents a basis for interoperability with *existing* implementations, and the core features should not be changed without compelling reasons to do so. On Wed, Sep 04, 2013 at 02:38:01PM +0200, Ond?ej Sur? wrote: > > > I'm not sure that I agree with everything in that draft, > > particularly the bit about not using certificate usage 0/1, as this > > is precisely what we would do for Gmail most likely (we operate > > our own CA, and for instance in Chrome and via > > You need certificate usage 2 for your own CA and the mapping > 0->2, 1->3 (see sections 2.2.1.3 and 2.2.1.4) ensures that your > DANE record with certificate usage 0 SHOULD be used even in case > that you use a well established CA. The Postfix mapping of usage 0 to 2 is necessarily incomplete! In particular "0 x [12]" are unsupported, and "0 0 0" is too large to fit into DNS without fragmentation. Even "0 1 0" is too large with 2048-bit RSA keys. Only ECDSA keys make "0 1 0" usable, but most clients don't support EC. So in effect only the downgrade of 1->3 works. Usage "0" is essentially not supported at all (best effort support leaves most of it unusable). > > http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08 we > > typically pin google.com to a set of CA certificates, not leaf > > certificates, as the leaf certificates can rotate more frequently > > based on operational needs but our CA cert changes much more rarely.) > > It's not clear to me why requiring PKIX validation in that case > > would be an unreasonable expectation. > > I guess this comes from operational experiences, currently the > SMTP servers don't do any validation on the certificates and it > would be a great leap to take, so it's better to start with > opportunistic TLS than enforcing the users to do full PKIX. > > This might change in the future in some future draft, but Viktor's > draft would be a huge leap for SMTP encryption. This is very unlikely to change. I can't subject Postfix users to the consequences of requiring PKIX (reduced service availability when CA lists are incomplete, or mandating trust in CAs they've never heard of). Adding CA trust in SMTP with DANE adds no security, the protocol is critically dependent on DNSSEC. So PKIX for SMTP (internet scale with no prior bilateral agreement, ... see the draft) only gives us additional failure modes with no security benefit. There will be no PKIX support in the Postfix DANE implementation. Servers publishing usage 0 will find that clients simply enforce mandatory TLS and skip authentication. The right thing to do is to choose between publishing "2 1 1" or "3 1 1". The remaining 22 combinations of DANE parameters can be ignored for SMTP. -- Viktor. From ifette@google.com Wed Sep 4 08:13:40 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD6E21F99F4 for ; Wed, 4 Sep 2013 08:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooOl7uyGNM7R for ; Wed, 4 Sep 2013 08:13:39 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id D0BD321F99E9 for ; Wed, 4 Sep 2013 08:13:31 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id x14so880267ief.39 for ; Wed, 04 Sep 2013 08:13:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ACRrojdJK4FDNDNzQgikGh4ME/kHzvJ3YF2qX5SoIAQ=; b=XILDuFO7TPALBjF4Mkb9OWomNWMnP7VLFA9hTjJTZt6DCMsBBHBpdN3gPZ2E6iWQg7 21azjrtUFpAZT97ttZrDHvSC/O4sP9KVDmfM2QJnIwoqLQ9HsiVmXXpcaDgL2h97OuZt b3Bf2hnLi6p+O9xcphWipvQQ024Xtq+GuS3PEEvSPp+0DN0vDXkp8uUB2MijAnjarvhE O/uY91+7aBvSoeCjYi+ryQU4fHsX+N7EnXi0Pt5UqlrmS/aTx7xc4r43hxdmtgcskay3 lLZhP0dCRIlvkfB7annr4RDEeR+lvMUlh16W/CPgI1Tf6AeeCjuiPB7FLHhTC8D7f5Fw dU/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ACRrojdJK4FDNDNzQgikGh4ME/kHzvJ3YF2qX5SoIAQ=; b=cC8s1/oWJ+vikGDPhQ+xKUB4MEZ1OciQxT2l3+17+yKJ2tjCzzUrl9mSI7Ad2uEPmm IlAAobHxH5kymLHp2Ca/Ld5GiGRAvyPtvE5F3j5pg9QtGG9dhXJPQAy3luT3pQifxOdY 1RasF+nneAiQwmZ1Zj+Dj05+Nlnla2GE2Mh7BxnZ3gM9R8RG6wW6pNYmHtt/4/k6UpUd vtq6eVlnJrioPQ9QYlVZe8o2wbryzdbIE0yDGP18aDsnzllm6velMvYSv6EDZSNlsJeH pRarzhPPkIsVqNWOpdHRAg20LgpD++HzrvSx0//L+kllILrkOjMxm/Z+PQMDc/9qBu0R 82KA== X-Gm-Message-State: ALoCoQk1JvbpGaHsA9paK+qEU64Xt81/8yJsEDEwyQLdchykcqxTgiRWiSvo85FQhQiCBJxogEy6M56P/xwqNyp46Aw2nebrPg3r/5/6CTm0jA2pt9Mu9+erpncHQGd1Oqe9otiNfZDBmfxzsPGb14eood/jFWtpLFCYTTjkJdIwfrJ9E6nQDXECOin8O/ojSexqD3O2ZMfm MIME-Version: 1.0 X-Received: by 10.42.11.211 with SMTP id v19mr1969635icv.29.1378307611021; Wed, 04 Sep 2013 08:13:31 -0700 (PDT) Received: by 10.231.161.70 with HTTP; Wed, 4 Sep 2013 08:13:30 -0700 (PDT) In-Reply-To: <35A92E9C-75BA-45A6-A458-F75E741FCA61@nic.cz> References: <20130904022533.B05A239302EF@drugs.dv.isc.org> <20130904040222.GZ29796@mournblade.imrryr.org> <35A92E9C-75BA-45A6-A458-F75E741FCA61@nic.cz> Date: Wed, 4 Sep 2013 08:13:30 -0700 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= Content-Type: multipart/alternative; boundary=20cf301d3e608c2ce304e5903f7b Cc: dane@ietf.org Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ifette@google.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 15:13:40 -0000 --20cf301d3e608c2ce304e5903f7b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ond=C5=99ej, I might be getting it wrong, but since our CA is cross-signed = by another CA, the chain that most clients will build will be rooted in something else. You can see this if you go to https://mail.google.com - GeoTrust shows as the root, which signs Google Internet Authority G2, which signs a cert for mail.google.com. If someone is using openssl and it follows AIA chaining or otherwise constructs a trust chain up to GlobalSign and we had specified "2" with the intermediate, would that break or still work? (Sorry, this is probably the most confusing part of the spec) On Wed, Sep 4, 2013 at 5:38 AM, Ond=C5=99ej Sur=C3=BD = wrote: > Ian, > > > On 4. 9. 2013, at 6:13, Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95= =E3=82=A7=E3=83=83=E3=83=86=E3=82=A3) wrote: > > I'm not sure that I agree with everything in that draft, particularly > the bit about not using certificate usage 0/1, as this is precisely what = we > would do for Gmail most likely (we operate our own CA, and for instance i= n > Chrome and via > > You need certificate usage 2 for your own CA and the mapping 0->2, 1->3 > (see sections 2.2.1.3 and 2.2.1.4) ensures that your DANE record with > certificate usage 0 SHOULD be used even in case that you use a well > established CA. > > > http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08 we > typically pin google.com to a set of CA certificates, not leaf > certificates, as the leaf certificates can rotate more frequently based o= n > operational needs but our CA cert changes much more rarely.) It's not cle= ar > to me why requiring PKIX validation in that case would be an unreasonable > expectation. > > I guess this comes from operational experiences, currently the SMTP > servers don't do any validation on the certificates and it would be a gre= at > leap to take, so it's better to start with opportunistic TLS than enforci= ng > the users to do full PKIX. > > This might change in the future in some future draft, but Viktor's draft > would be a huge leap for SMTP encryption. > > > Indeed, most of the certs I see from a random inspection of servers > offering STARTTLS (google, t-online, web.de etc) include a full > certificate chain to a public CA. Other than that nit though, I would lov= e > to see that draft advance. > > > O. > -- > Ond=C5=99ej Sur=C3=BD -- Chief Science Officer > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > > --20cf301d3e608c2ce304e5903f7b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ond=C5=99ej, I might be getting it wrong, but since our CA is cross-signe= d by another CA, the chain that most clients will build will be rooted in s= omething else. You can see this if you go to https://mail.google.com - GeoTrust shows as the root, which signs= Google Internet Authority G2, which signs a cert for mail.google.com. If someone is using openssl and it follo= ws AIA chaining or otherwise constructs a trust chain up to GlobalSign and = we had specified "2" with the intermediate, would that break or s= till work? (Sorry, this is probably the most confusing part of the spec)


On Wed, Sep 4= , 2013 at 5:38 AM, Ond=C5=99ej Sur=C3=BD <ondrej.sury@nic.cz> wrote:
Ian,


On 4. 9. 2013, at 6:13, Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3= =82=A7=E3=83=83=E3=83=86=E3=82=A3) <ifette@google.com> wrote:
> I'm not sure that I agree with everything in that draft, particula= rly the bit about not using certificate usage 0/1, as this is precisely wha= t we would do for Gmail most likely (we operate our own CA, and for instanc= e in Chrome and via

You need certificate usage 2 for your own CA and the mapping 0->2,= 1->3 (see sections 2.2.1.3 and 2.2.1.4) ensures that your DANE record w= ith certificate usage 0 SHOULD be used even in case that you use a well est= ablished CA.

> http://tools.ietf.org/html/draft-ietf-websec-key-pinnin= g-08 we typically pin g= oogle.com to a set of CA certificates, not leaf certificates, as the le= af certificates can rotate more frequently based on operational needs but o= ur CA cert changes much more rarely.) It's not clear to me why requirin= g PKIX validation in that case would be an unreasonable expectation.

I guess this comes from operational experiences, currently the SMTP s= ervers don't do any validation on the certificates and it would be a gr= eat leap to take, so it's better to start with opportunistic TLS than e= nforcing the users to do full PKIX.

This might change in the future in some future draft, but Viktor's draf= t would be a huge leap for SMTP encryption.

> Indeed, most of the certs I see from a random inspection of servers of= fering STARTTLS (google, t-online, web.de etc) include a full certificate chain to a public CA. Other = than that nit though, I would love to see that draft advance.


O.
--
=C2=A0Ond=C5=99ej Sur=C3=BD -- Chief Science Officer
=C2=A0-------------------------------------------
=C2=A0CZ.NIC, z.s.p.o. =C2=A0 =C2=A0-- =C2=A0 =C2=A0Laborato=C5=99e CZ.NIC<= br> =C2=A0Americka 23, 120 00 Praha 2, Czech Republic
=C2=A0mailto:ondrej.sury@nic.cz = =C2=A0 =C2=A0http://nic.cz/
=C2=A0tel:+420.222= 745110 =C2=A0 =C2=A0 =C2=A0 fax:+420.222745112
=C2=A0-------------------------------------------


--20cf301d3e608c2ce304e5903f7b-- From viktor1dane@dukhovni.org Wed Sep 4 08:20:28 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B83421F9E63 for ; Wed, 4 Sep 2013 08:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6JVoH0HQaZB for ; Wed, 4 Sep 2013 08:20:24 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id D08EC21F9E52 for ; Wed, 4 Sep 2013 08:20:23 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5EBBE2AABCD; Wed, 4 Sep 2013 15:20:20 +0000 (UTC) Date: Wed, 4 Sep 2013 15:20:20 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130904152020.GD29796@mournblade.imrryr.org> References: <20130904022533.B05A239302EF@drugs.dv.isc.org> <20130904040222.GZ29796@mournblade.imrryr.org> <35A92E9C-75BA-45A6-A458-F75E741FCA61@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 15:20:28 -0000 On Wed, Sep 04, 2013 at 08:13:30AM -0700, Ian Fette (????????) wrote: > Ond?ej, I might be getting it wrong, but since our CA is cross-signed by > another CA, the chain that most clients will build will be rooted in > something else. You can see this if you go to https://mail.google.com - > GeoTrust shows as the root, which signs Google Internet Authority G2, which > signs a cert for mail.google.com. If someone is using openssl and it > follows AIA chaining or otherwise constructs a trust chain up to GlobalSign > and we had specified "2" with the intermediate, would that break or still > work? (Sorry, this is probably the most confusing part of the spec) Usage 2 chains work just like PKIX chains with the additional freedom that the trust-anchor need not be a root CA previously known to the client. If you also read https://tools.ietf.org/html/draft-dukhovni-dane-ops-01 you'll see that since the client will typically not have the associated CA certificate on hand, the server's certificate chain (sent in the TLS handshake) must include the trust anchor certificate. If the trust-anchor in a TLSA "2 1 1" record is an intermediate CA, the above will typically already be the case. When the "2 1 1" trust-anchor is actually a root CA (I encourage you to use a CA as close as possible to the leaf server that is stable enough to publish in your TLSA RRs) you now need to make sure that it is sent in the TLS handshake since unlike the PKIX case, the client won't have it on hand. -- Viktor. From ondrej.sury@nic.cz Wed Sep 4 08:23:28 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED5721F9FBF for ; Wed, 4 Sep 2013 08:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J33hS1a5-ceE for ; Wed, 4 Sep 2013 08:23:27 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF7C21E80DC for ; Wed, 4 Sep 2013 08:23:26 -0700 (PDT) Received: from mail.nic.cz (localhost [127.0.0.1]) by mail.nic.cz (Postfix) with ESMTP id 352DB13F63D; Wed, 4 Sep 2013 17:23:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1378308205; bh=EtACEoBtN9ZKEadqe4liKi3TF5DFqQKWH2wqNoXvmDw=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Date:From:To: Cc:Subject:In-Reply-To:References:Message-ID; b=GskliYjc+1mcyQW2TK5YSZwLZY7tiYfukyNiLkp8r1XIQQLOCbuncS+NepCfASfIu QUMLi04AHpfQbeUErN8MugmoeO0rVREpG+PjRjSn5HjLNQ9RvEGdrLbwPm6cDFIV3v MATGgrPVSkRrDhrnvmNP49t8hZCJL6fu8r/zVoX4= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Date: Wed, 04 Sep 2013 17:23:25 +0200 From: ondrej.sury@nic.cz To: ifette@google.com In-Reply-To: References: <20130904022533.B05A239302EF@drugs.dv.isc.org> <20130904040222.GZ29796@mournblade.imrryr.org> <35A92E9C-75BA-45A6-A458-F75E741FCA61@nic.cz> Message-ID: X-Sender: ondrej.sury@nic.cz User-Agent: mail X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: dane@ietf.org Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 15:23:28 -0000 On 2013-09-04 17:13, Ian Fette wrote: > Ond=C5=99ej, I might be getting it wrong, but since our CA is cross-signe= d > by another CA, the chain that most clients will build will be rooted > in something else. The usual problem is that the CA store in SMTP servers is empty by=20 default and people usually (somebody should probably do some survey) use=20 self-signed certs/CAs for their SMTP service. > You can see this if you go to > https://mail.google.com [7] - GeoTrust shows as the root, which signs > Google Internet Authority G2, which signs a cert for mail.google.com > [8]. If someone is using openssl and it follows AIA chaining or > otherwise constructs a trust chain up to GlobalSign and we had > specified "2" with the intermediate, would that break or still work? It would still work if you send whole chain in the TLS up to the=20 certificate specified in TLSA record. O. > (Sorry, this is probably the most confusing part of the spec) >=20 > On Wed, Sep 4, 2013 at 5:38 AM, Ond=C5=99ej Sur=C3=BD > wrote: >=20 >> Ian, >>=20 >> On 4. 9. 2013, at 6:13, Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95= =E3=82=A7=E3=83=83=E3=83=86=E3=82=A3) >> wrote: >>> I'm not sure that I agree with everything in that draft, >> particularly the bit about not using certificate usage 0/1, as this >> is precisely what we would do for Gmail most likely (we operate our >> own CA, and for instance in Chrome and via >>=20 >> You need certificate usage 2 for your own CA and the mapping 0->2, >> 1->3 (see sections 2.2.1.3 and 2.2.1.4) ensures that your DANE >> record with certificate usage 0 SHOULD be used even in case that you >> use a well established CA. >>=20 >>> http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08 [1] >> we typically pin google.com [2] to a set of CA certificates, not >> leaf certificates, as the leaf certificates can rotate more >> frequently based on operational needs but our CA cert changes much >> more rarely.) It's not clear to me why requiring PKIX validation in >> that case would be an unreasonable expectation. >>=20 >> I guess this comes from operational experiences, currently the SMTP >> servers don't do any validation on the certificates and it would be >> a great leap to take, so it's better to start with opportunistic TLS >> than enforcing the users to do full PKIX. >>=20 >> This might change in the future in some future draft, but Viktor's >> draft would be a huge leap for SMTP encryption. >>=20 >>> Indeed, most of the certs I see from a random inspection of >> servers offering STARTTLS (google, t-online, web.de [3] etc) include >> a full certificate chain to a public CA. Other than that nit though, >> I would love to see that draft advance. >>=20 >> O. >> -- >> =C2=A0Ond=C5=99ej Sur=C3=BD -- Chief Science Officer >> =C2=A0------------------------------------------- >> =C2=A0CZ.NIC, z.s.p.o. =C2=A0 =C2=A0-- =C2=A0 =C2=A0Laborato=C5=99e CZ= =2ENIC >> =C2=A0Americka 23, 120 00 Praha 2, Czech Republic >> =C2=A0mailto:ondrej.sury@nic.cz =C2=A0 =C2=A0http://nic.cz/ [4] >> =C2=A0tel:+420.222745110 [5] =C2=A0 =C2=A0 =C2=A0 fax:+420.222745112 [6] >> =C2=A0------------------------------------------- >=20 >=20 >=20 > Links: > ------ > [1] http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08 > [2] http://google.com > [3] http://web.de > [4] http://nic.cz/ > [5] tel:%2B420.222745110 > [6] tel:%2B420.222745112 > [7] https://mail.google.com > [8] http://mail.google.com From ifette@google.com Wed Sep 4 08:25:59 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4EF21E8149 for ; Wed, 4 Sep 2013 08:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAS3Jg5r1kUs for ; Wed, 4 Sep 2013 08:25:58 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEA321E814B for ; Wed, 4 Sep 2013 08:25:57 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id a14so883201iee.26 for ; Wed, 04 Sep 2013 08:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=rVkd87oDYbZpj9lsb2VYySGvZcFaqxZwmhS125DRK5o=; b=FmhSAPF5j5M03jo/aKOpG2seRxFe1I51wSx/Ns9vbqjrwMwCC+vv6IbI/Se//oTYsn UTA86+GAXk38FkhHsGtcvzep+OTwyaKbwp/grcdykNG+ZbChqyXYtOn/ktNCvkugJqS1 NengPwqbitfha1bIOlogOREcNQ8LXO4DHL0fu8mG4Y4EXD7ZFc/zCz0ZbYNznoZfXiBC t3qfh0mXWn3YzeKCWh8dVo1dry4HEgf/Z0O3hQfGMUTciZU9JtADNm745YBiPjR9wIoQ tVn5HcAAkakw6vx5FI8n53n8Zh3LgSatRHEBB3tGeMYOw4d67IqZXsgOcQqxZaiKAGCv 0lUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=rVkd87oDYbZpj9lsb2VYySGvZcFaqxZwmhS125DRK5o=; b=dMKS6hPR/ZTDK12h3bmKhGExrRD6HipAsc/tyS4FNDHnPNi4JD2xwAIeKDIImzLadZ qFRRu1QaW0AB6h6UeZ80fU2ZDHPmk8mQbt0R1lq00obgBYsJRBwWEP5AaALSPhYRRqjJ 8ho+8fZUrXj82aNZWutzG1INUKt0psvI5QiMRCbo8mF+8mGTLkMPmF2oimrwx8lk/+74 +RKOnJkC4+68NnMUVgmH8XYIvjUilUxbjhve/N8l1+y9+0kNOqPxtaYyati6cNFE707E MBpe/evdr/wz6oXNaBGY2TDT2Jqj+0nJs58YKXH3B92tj2pggVeHSkTXyskqvqfHrEUq 6PLA== X-Gm-Message-State: ALoCoQlYv5qFPbDwLxgVNRnWktXZYONAmACUky2O2k1Ne+BSBm/urT89YB9GsTfERb5iQaBnplBZRltosvzEuuN6OrVweOnvvxNtmkot5a9LLYZbrSGOsNAx+2OCa+rfITReWbL2pNYeRxkvXwGJw9VKOFFS7xvH3/n23Ei589gN6Qt7SWomEbHX/+ujjxWHoucr4G3qyMhp MIME-Version: 1.0 X-Received: by 10.42.79.4 with SMTP id p4mr2128785ick.21.1378308356485; Wed, 04 Sep 2013 08:25:56 -0700 (PDT) Received: by 10.231.161.70 with HTTP; Wed, 4 Sep 2013 08:25:56 -0700 (PDT) In-Reply-To: <20130904152020.GD29796@mournblade.imrryr.org> References: <20130904022533.B05A239302EF@drugs.dv.isc.org> <20130904040222.GZ29796@mournblade.imrryr.org> <35A92E9C-75BA-45A6-A458-F75E741FCA61@nic.cz> <20130904152020.GD29796@mournblade.imrryr.org> Date: Wed, 4 Sep 2013 08:25:56 -0700 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: dane@ietf.org Content-Type: multipart/alternative; boundary=20cf3010ec25fad93704e5906b0c Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ifette@google.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 15:25:59 -0000 --20cf3010ec25fad93704e5906b0c Content-Type: text/plain; charset=UTF-8 Viktor, Thanks for the continued considered replies. I don't mean to ignore you, it's just that I typically reply in chronological order and hadn't yet finished writing a response to your email :) Much of this probably stems from my confusion around 0/2 in the DANE spec. 0 says the cert MUST be found in the path - it doesn't say the cert has to be the root. 2 implies that the cert has to be the root. For us, the thing we want to pin to (our intermediate CA) would be in the middle of the chain, so I had read that to imply that only 0 would be available. What I hear you saying is that it would still work with pinning to that intermediate using 2, and presumably the client should use the cert in 2 as the root of the trust chain and ignore any signatures on that root from other CAs it knows about. This wasn't entirely clear to me in the spec, but if that's how it is supposed to work, then yes, I believe that would work for our use case. -Ian On Wed, Sep 4, 2013 at 8:20 AM, Viktor Dukhovni wrote: > On Wed, Sep 04, 2013 at 08:13:30AM -0700, Ian Fette (????????) wrote: > > > Ond?ej, I might be getting it wrong, but since our CA is cross-signed by > > another CA, the chain that most clients will build will be rooted in > > something else. You can see this if you go to https://mail.google.com - > > GeoTrust shows as the root, which signs Google Internet Authority G2, > which > > signs a cert for mail.google.com. If someone is using openssl and it > > follows AIA chaining or otherwise constructs a trust chain up to > GlobalSign > > and we had specified "2" with the intermediate, would that break or still > > work? (Sorry, this is probably the most confusing part of the spec) > > Usage 2 chains work just like PKIX chains with the additional > freedom that the trust-anchor need not be a root CA previously > known to the client. > > If you also read > > https://tools.ietf.org/html/draft-dukhovni-dane-ops-01 > > you'll see that since the client will typically not have the associated > CA certificate on hand, the server's certificate chain (sent in the > TLS handshake) must include the trust anchor certificate. > > If the trust-anchor in a TLSA "2 1 1" record is an intermediate > CA, the above will typically already be the case. When the "2 1 > 1" trust-anchor is actually a root CA (I encourage you to use a CA > as close as possible to the leaf server that is stable enough to > publish in your TLSA RRs) you now need to make sure that it is > sent in the TLS handshake since unlike the PKIX case, the client > won't have it on hand. > > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --20cf3010ec25fad93704e5906b0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Viktor,

Thanks for the continued consid= ered replies. I don't mean to ignore you, it's just that I typicall= y reply in chronological order and hadn't yet finished writing a respon= se to your email :)=C2=A0

Much of this probably stems from my confusion around 0/= 2 in the DANE spec. 0 says the cert MUST be found in the path - it doesn= 9;t say the cert has to be the root. 2 implies that the cert has to be the = root. For us, the thing we want to pin to (our intermediate CA) would be in= the middle of the chain, so I had read that to imply that only 0 would be = available. What I hear you saying is that it would still work with pinning = to that intermediate using 2, and presumably the client should use the cert= in 2 as the root of the trust chain and ignore any signatures on that root= from other CAs it knows about. This wasn't entirely clear to me in the= spec, but if that's how it is supposed to work, then yes, I believe th= at would work for our use case.

-Ian


On Wed, Sep 4, 2013 at 8:20 AM, Viktor Dukhovni <viktor1dane@dukhovni.org> wrote:
On Wed, Sep 04, 2013 at 08:13:30AM -0700, Ia= n Fette (????????) wrote:

> Ond?ej, I might be getting it wrong, but since our CA is cross-signed = by
> another CA, the chain that most clients will build w= ill be rooted in
> something else. You can see this if you go to https://mail.google.com -
> GeoTrust shows as the root, which signs Google Internet Authority G2, = which
> signs a cert for = mail.google.com. If someone is using openssl and it
> follows AIA chaining or otherwise constructs a trust chain up to Globa= lSign
> and we had specified "2" with the intermediate, would that b= reak or still
> work? (Sorry, this is probably the most confusing part of the spec)
Usage 2 chains work just like PKIX chains with the additional
freedom that the trust-anchor need not be a root CA previously
known to the client.

If you also read

=C2=A0 =C2=A0 https://tools.ietf.org/html/draft-dukhovni-dane-ops= -01

you'll see that since the client will typically not have the associated=
CA certificate on hand, the server's certificate chain (sent in the
TLS handshake) must include the trust anchor certificate.

If the trust-anchor in a TLSA "2 1 1" record is an intermediate CA, the above will typically already be the case. =C2=A0When the "2 1<= br> 1" trust-anchor is actually a root CA (I encourage you to use a CA
as close as possible to the leaf server that is stable enough to
publish in your TLSA RRs) you now need to make sure that it is
sent in the TLS handshake since unlike the PKIX case, the client
won't have it on hand.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.
_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane

--20cf3010ec25fad93704e5906b0c-- From viktor1dane@dukhovni.org Wed Sep 4 08:56:32 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4DB11E80DE for ; Wed, 4 Sep 2013 08:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CckO-WwY4OV5 for ; Wed, 4 Sep 2013 08:56:27 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 34A4221E80EF for ; Wed, 4 Sep 2013 08:56:27 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 540B42AB081; Wed, 4 Sep 2013 15:56:21 +0000 (UTC) Date: Wed, 4 Sep 2013 15:56:21 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130904155621.GE29796@mournblade.imrryr.org> References: <20130904022533.B05A239302EF@drugs.dv.isc.org> <20130904040222.GZ29796@mournblade.imrryr.org> <35A92E9C-75BA-45A6-A458-F75E741FCA61@nic.cz> <20130904152020.GD29796@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 15:56:33 -0000 On Wed, Sep 04, 2013 at 08:25:56AM -0700, Ian Fette (????????) wrote: > Much of this probably stems from my confusion around 0/2 in the DANE spec. Perhaps 6698 could be more clear, but this is a general issue with standards documents, they are always too concise unless one is steeped in the art. > 0 says the cert MUST be found in the path - it doesn't say the cert has to > be the root. 2 implies that the cert has to be the root. You're misreading the specification. In both cases the certificate can be anywhere in the path. With 0, the client is required to have prior trust in an additional root CA to anchor the path. With 2 the requirement is dropped. The trust-anchor in usage 2 can be an intermediate certificate or a root certificate. As far as the DANE client is concerned of course path construction can terminate at the usage 2 TA, and need not go any higher. However, the actual usage 2 TA may be an intermediate from a PKIX perspective and may be issued by some "authority", ... > For us, the thing > we want to pin to (our intermediate CA) would be in the middle of the > chain, so I had read that to imply that only 0 would be available. You're misreading the specification. Go ahead and pin the intermediate with usage 2, this just works. Best practice for your case is to publish a "2 1 1" association that is a SHA256 digest of the intermediate CA's public key. > What I hear you saying is that it would still work with pinning to that > intermediate using 2, and presumably the client should use the cert in 2 as > the root of the trust chain and ignore any signatures on that root from > other CAs it knows about. This wasn't entirely clear to me in the spec, but > if that's how it is supposed to work, then yes, I believe that would work > for our use case. Yes, that's how it is meant to work. A thorough and careful reading of 6698 should make this clear, even if it is not obvious at first glance. -- Viktor. From cloos@jhcloos.com Wed Sep 4 14:35:28 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E034411E80ED for ; Wed, 4 Sep 2013 14:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.407 X-Spam-Level: X-Spam-Status: No, score=-1.407 tagged_above=-999 required=5 tests=[AWL=0.891, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D437UCqeRQ2P for ; Wed, 4 Sep 2013 14:35:23 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) by ietfa.amsl.com (Postfix) with ESMTP id 2858F11E8126 for ; Wed, 4 Sep 2013 14:35:22 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id B01361DFC2; Wed, 4 Sep 2013 21:34:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1378330501; bh=pZrSwTCW7Es4alGSomIUnGMgTgfwRnlJD7aYDZyk2fo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=HUjN9VHifQJZp/zqfxGI3SszKoAUNzP9hY6VJ4On+JO4PoVBQ9ZoIt/z+SljwvuMr htxYtt4cPHOnK9aBNJG+99XXjG3n6sG9TUb2HYJ1Dze/+H4MhJxzTeiM7CVK4l6PfE hcJEftXRvqCunrYb4rNSxyPf/aBKaDdpaZdvD1OJ4Bw== Received: by carbon.jhcloos.org (Postfix, from userid 500) id 25DCB6001D; Wed, 4 Sep 2013 21:33:16 +0000 (UTC) From: James Cloos To: =?utf-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= In-Reply-To: ("Ian Fette =?utf-8?B?KOOCpOOCouODs+ODleOCp+ODg+ODhuOCoykiJ3M=?= message of "Wed, 4 Sep 2013 08:13:30 -0700") References: <20130904022533.B05A239302EF@drugs.dv.isc.org> <20130904040222.GZ29796@mournblade.imrryr.org> <35A92E9C-75BA-45A6-A458-F75E741FCA61@nic.cz> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Wed, 04 Sep 2013 17:33:16 -0400 Message-ID: Lines: 66 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Hashcash: 1:28:130904:ondrej.sury@nic.cz::3/1BRMNkD7pUu1aw:0000000000000000000000000000000000000000001KEHK X-Hashcash: 1:28:130904:dane@ietf.org::RYokv2YTH/QXxX5s:000IlG00 Cc: dane@ietf.org Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 21:35:28 -0000 >>>>> "IF(" == Ian Fette (イアンフェッティ) writes: IF(> Ondřej, I might be getting it wrong, but since our CA is cross-signed by IF(> another CA, the chain that most clients will build will be rooted in IF(> something else. 2 can point at any cert in the full chain other than the ee cert. The client is expected to verify from the ee to the cert specified in the 2, and then verify that /that/ cert matches the tlsa. You can also do that with a 0. If you use 0, then clients are typically expected to do the above, but *also* verify the full chain just as they would w/o DANE. Pointing at the google ca with type 0s would be fine for everything you serve at a fixed port over tls or dtls, given that you have a corp CA which has been signed by a well-known root CA. But only if clients which do not know the typical ca-certificates.crt choose to pretend that the type 0 were a type 2, as Victor’s draft recommends. And as his postfix code does. Some suggest using a CNAME to point at a single TLSA RR to improve caching (the CNAME RRs require fewer bits than the TLSA, so a lot of CNAME RRs pointing at one TLSA probably is better than a lot of TLSA RRs with identical content. (Hint to self.) Most smtp client admins do not bother to configure the list of CAs, so most could not do full type 0 or type 1 verification. Some of us do, however, configure it, do check the offerred certs when sending mail, but cannot, yet, require that they pass. There are too many MXs which can only to untrusted tls. Since I point my outgoing postfix at: smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt I get logs like: Trusted TLS connection established to gmail-smtp-in.l.google.com[2607:f8b0:4002:c04::1b]:25: TLSv1.2 with cipher ECDHE-RSA-RC4-SHA (128/128 bits) (Interesting that the MXs still prefer rc4; the other goog TLS services recently switched to negotiating TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256.) But cannot demand Trusted, due to sites like: Untrusted TLS connection established to mail.ZZZZZZ.org[NNN.NNN.NNN.NNN]:25: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits) or: Untrusted TLS connection established to mx.ZZZ.org[NNN.NN.NN.NN]:25: TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits) (names elided to protect the untrusted :). The inability to demand Trusted is likely why most do not bother to configure the CAfile. In fact it is only in that last year or so that most of my outgoing mail has been to MXs which even offer starttls. DANE should help that. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From cloos@jhcloos.com Wed Sep 4 16:47:20 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A6511E8146 for ; Wed, 4 Sep 2013 16:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.507 X-Spam-Level: X-Spam-Status: No, score=-1.507 tagged_above=-999 required=5 tests=[AWL=1.093, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yv38SO92xaBv for ; Wed, 4 Sep 2013 16:47:19 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) by ietfa.amsl.com (Postfix) with ESMTP id C2FBA11E81F9 for ; Wed, 4 Sep 2013 16:47:19 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 1B2621DFC9; Wed, 4 Sep 2013 23:46:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1378338422; bh=WCwDqwZEN4BypGehKh0WBmB6HN6ER1P5xKDpl9acjcI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=LRGZDiNJwx2fS4Jr4cqyMR3FOxKqhi4A5H8ES4G1mHoDBBYPJL+Dyj0bXX+bjVOI1 9eLkTYxjq1a3OicPFeZzyZNzL2QTsK4ugG6hPtEaP+4hEVMWSM2j1FDgINM0/Envje kCglINx649TNaI07Cv2Oox1J9pfNyTMoEnm4a7SAvSw== Received: by carbon.jhcloos.org (Postfix, from userid 500) id 7C5356001D; Wed, 4 Sep 2013 23:43:20 +0000 (UTC) From: James Cloos To: Viktor Dukhovni In-Reply-To: <20130904144549.GA29796@mournblade.imrryr.org> (Viktor Dukhovni's message of "Wed, 4 Sep 2013 14:45:49 +0000") References: <20130904144549.GA29796@mournblade.imrryr.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Wed, 04 Sep 2013 19:43:20 -0400 Message-ID: Lines: 18 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:130904:viktor1dane@dukhovni.org::Hk63QnfL0Qwj1HFM:000000000000000000000000000000000000BvKaj X-Hashcash: 1:28:130904:dane@ietf.org::N9nW0Wp5NbQku8Bk:000cRLoq Cc: dane@ietf.org Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 23:47:20 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> If you publish usage 0, you will not interoperate with Postfix, VD> which accounts for a large fraction of the MTAs on the Internet. I thought that you previously wrote that, in the absense of of CAfile setting, postfix would treat 0/1 like 2/3? Or did I miss a change? Ian: Given the above, my earlier post suggesting type 0 would do should be amended to suggest a type 2 for _25._tcp. I still would choose 2 rather than 3 in your case, since you can issue new ee certs signed by that CA at will. Saving the hassle of updating the DNS every time that occurs is a good plan. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From viktor1dane@dukhovni.org Wed Sep 4 18:09:34 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964F811E8225 for ; Wed, 4 Sep 2013 18:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hL6HusuOIfKO for ; Wed, 4 Sep 2013 18:09:29 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 7973711E821C for ; Wed, 4 Sep 2013 18:09:29 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 67C0D2AABCD; Thu, 5 Sep 2013 01:09:24 +0000 (UTC) Date: Thu, 5 Sep 2013 01:09:24 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130905010924.GM29796@mournblade.imrryr.org> References: <20130904144549.GA29796@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 01:09:34 -0000 On Wed, Sep 04, 2013 at 07:43:20PM -0400, James Cloos wrote: > VD> If you publish usage 0, you will not interoperate with Postfix, > VD> which accounts for a large fraction of the MTAs on the Internet. > > I thought that you previously wrote that, in the absense of of CAfile > setting, postfix would treat 0/1 like 2/3? Or did I miss a change? The mapping from 0/1 to 2/3 is best effort. With 1 it just works, with 0 it fails with matching type != 0. Also Wes convinced me that we should not promise this behaviour in the draft. Therefore, while Postfix may map 0/1 to 2/3 as best it can the draft behaviour for these is undefined and SMTP servers SHOULD NOT publish these usages. -- Viktor. From ifette@google.com Thu Sep 5 14:17:42 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0EF11E8106 for ; Thu, 5 Sep 2013 14:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09N+xoLzZ1kY for ; Thu, 5 Sep 2013 14:17:41 -0700 (PDT) Received: from mail-qe0-x229.google.com (mail-qe0-x229.google.com [IPv6:2607:f8b0:400d:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id A0BAE11E81BB for ; Thu, 5 Sep 2013 14:17:40 -0700 (PDT) Received: by mail-qe0-f41.google.com with SMTP id ff1so1280286qeb.0 for ; Thu, 05 Sep 2013 14:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=ECidAlID0f2JkqMv/OmBWYsyCJ37cXqWqf6b1WTyI2I=; b=GK3thEwiJDoW08OKHUr9lWiswghhJYvT4VN/wpTxjpVsc9Yhim45HWVoyU3vqfUyel vTS9JMBhMoLenY3Xvv+qzbputs0I2UdOeYSe3PlBMsJbArpzwC6ReouP0rd+BivOpuCT qKPi1ejsHgDzy7YHp+bAz1pHOXuXkxR0g1VJLRenGtK2zePXvttBgtaK3YfL+QfEJnGu X+IXzbTz1TbZ77dSa1aMtTzyFzhWNPp6a5c4NzdE0CgCpSawhKaX43YYHBMxv3tyeZNB VvbxoG4Mv3mg8pn1I4cXDQuuaqxMtYMcjFSTcJeyUwDxfZo/76L+PfbdFIoFxH1n8sjZ ROxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=ECidAlID0f2JkqMv/OmBWYsyCJ37cXqWqf6b1WTyI2I=; b=OgSYpanpEXW8X3X8DPZC6Op6EbyAN64VWX9Hyfd3t7TaDbb/KVVq0rXlQtLagqBF67 lGZ8nNYXAY9i5nk1krl3TE976iM7o9MpI2kZFRDzfDJQii/6wSTa6c/y6TeF5FT65V9j 1dTpnYbithcd1oYJrk6wseDnj/R44IdSNYQQRrQ0eg6hpqLh+i/SVdN5A6+v8taQoHgH AfHTmLHFMl6LfjLbs2tNtO18lLFXGb8VY/j99+bBXIJD0/RrDUSfnY0GsmYnu96NfTnd 3hT9GN6q4CRqNnI0mnCb/u5NRsbVBlR+QTW/Yqxtn5jp+a7jcFHId8Hs4t//JqjClcl+ EzIA== X-Gm-Message-State: ALoCoQlqn/+3ZQVWa7A/1gkjfP9GJ3VYBjtAns1b0zQGRBETgj5ybu6Oa3IzB7fn/clepLtAwu9A4mEA0sZu7bygHRRjESEIL05gA9z5hII5e475zlJGEEEr2ROZKurKfnbfsuUn1rY/Xt0uwz2Tfhq00cUU3lKM0i4P7xOk8q+xn3BsrCEPksUwLMYPlPVN7S7gPvGj1Qos MIME-Version: 1.0 X-Received: by 10.224.24.138 with SMTP id v10mr84888qab.65.1378415859789; Thu, 05 Sep 2013 14:17:39 -0700 (PDT) Received: by 10.229.62.132 with HTTP; Thu, 5 Sep 2013 14:17:39 -0700 (PDT) In-Reply-To: <20130905010924.GM29796@mournblade.imrryr.org> References: <20130904144549.GA29796@mournblade.imrryr.org> <20130905010924.GM29796@mournblade.imrryr.org> Date: Thu, 5 Sep 2013 14:17:39 -0700 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: dane@ietf.org Content-Type: multipart/alternative; boundary=001a11c24576ad09d204e5a973a9 Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ifette@google.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 21:17:42 -0000 --001a11c24576ad09d204e5a973a9 Content-Type: text/plain; charset=UTF-8 One other question about this proposal. My reading of DANE says that if a TLSA record is not verified by DNSSEC, you should basically ignore it. Precious few people have yet deployed DNSSEC (Paypal is the only company that comes to mind). If a zone hasn't deployed DNSSEC, I certainly understand not treating a TLSA record on _443._ tcp.bank.com as a valid SSL certificate for https://www.bank.com. But what about the case of SMTP? On SMTP, today you're going to connect on port 25, and you're going to either not see STARTTLS in which case you presumably will send mail unencrypted, or you will see STARTTLS and as we discussed earlier in this thread, probably just take whatever certificate you get and hope for the best. Now, let's assume you have a TLSA record for _ 25.tcp.gmail-smtp-in.l.google.com, which specifies 2 1 1 and our certificate. Let's assume also for the moment that it's not secured via DNSSEC, and that DNSSEC deployment for google.com isn't going to happen overnight. Now, you've got an option. You can use that (admittedly insecure) information and do one of three things: 1. Ignore it and do what you would have done had you not seen the TLSA record (per the DANE spec) 2. Ignore the fact that it's lacking DNSSEC and treat it as "I should only send mail over TLS and expect the following cert" I'm curious what Postfix will do in that case, and what guidance we might be able to put into the draft in that case. For better or worse, there's probably others who are capable of publishing a TLSA record before they are capable of fully deploying DNSSEC. In the case of someone being able to spoof your DNS, they could just direct the MX records elsewhere, and not bother with spoofing TLSA (maybe they offer STARTTLS, maybe they don't). It doesn't seem like trusting the TLSA record opens you up to any new vulnerabilities here. In the case of HTTP, it does open you up to vulnerabilities as you presumably send secure cookies to a certificate you otherwise wouldn't have trusted. In the case of SMTP, you basically either bounce the mail or you deliver it; someone who can publish a fake TLSA record to mess with you could just as easily publish fake MX records to accomplish the same result, so it's not clear to me that a TLSA record for MX need to depend strongly on DNSSEC. Thoughts? On Wed, Sep 4, 2013 at 6:09 PM, Viktor Dukhovni wrote: > On Wed, Sep 04, 2013 at 07:43:20PM -0400, James Cloos wrote: > > > VD> If you publish usage 0, you will not interoperate with Postfix, > > VD> which accounts for a large fraction of the MTAs on the Internet. > > > > I thought that you previously wrote that, in the absense of of CAfile > > setting, postfix would treat 0/1 like 2/3? Or did I miss a change? > > The mapping from 0/1 to 2/3 is best effort. With 1 it just works, > with 0 it fails with matching type != 0. > > Also Wes convinced me that we should not promise this behaviour in > the draft. Therefore, while Postfix may map 0/1 to 2/3 as best it > can the draft behaviour for these is undefined and SMTP servers > SHOULD NOT publish these usages. > > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --001a11c24576ad09d204e5a973a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One other question about this proposal.

My reading of DANE says that if a TLSA record is not verified by DNSSEC, y= ou should basically ignore it. Precious few people have yet deployed DNSSEC= (Paypal is the only company that comes to mind). If a zone hasn't depl= oyed DNSSEC, I certainly understand not treating a TLSA record on _443._tcp.bank.com as a valid SSL certificate fo= r https://www.bank.com. But what about= the case of SMTP? On SMTP, today you're going to connect on port 25, a= nd you're going to either not see STARTTLS in which case you presumably= will send mail unencrypted, or you will see STARTTLS and as we discussed e= arlier in this thread, probably just take whatever certificate you get and = hope for the best.

Now, let's assume you have a TLSA record for _25.tcp.gmail-smtp-in.l.goog= le.com, which specifies 2 1 1 and our certificate. Let's assume als= o for the moment that it's not secured via DNSSEC, and that DNSSEC depl= oyment for google.com isn't going to = happen overnight. Now, you've got an option. You can use that (admitted= ly insecure) information and do one of three things:

1. Ignore it and do what you would have done had you no= t seen the TLSA record (per the DANE spec)
2. Ignore the fact tha= t it's lacking DNSSEC and treat it as "I should only send mail ove= r TLS and expect the following cert"

I'm curious what Postfix will do in that case, and = what guidance we might be able to put into the draft in that case. For bett= er or worse, there's probably others who are capable of publishing a TL= SA record before they are capable of fully deploying DNSSEC.

In the case of someone being able to spoof your DNS, th= ey could just direct the MX records elsewhere, and not bother with spoofing= TLSA (maybe they offer STARTTLS, maybe they don't). It doesn't see= m like trusting the TLSA record opens you up to any new vulnerabilities her= e. In the case of HTTP, it does open you up to vulnerabilities as you presu= mably send secure cookies to a certificate you otherwise wouldn't have = trusted. In the case of SMTP, you basically either bounce the mail or you d= eliver it; someone who can publish a fake TLSA record to mess with you coul= d just as easily publish fake MX records to accomplish the same result, so = it's not clear to me that a TLSA record for MX need to depend strongly = on DNSSEC.

Thoughts?

On Wed, Sep 4, 2013 at 6:09 PM, Viktor Dukhovni= <viktor1dane@dukhovni.org> wrote:
On Wed, Sep 04, 2013 at 07= :43:20PM -0400, James Cloos wrote:

> VD> If you publish usage 0, you will not interoperate with Postfix,=
> VD> which accounts for a large fraction of the MTAs on the Internet= .
>
> I thought that you previously wrote that, in the absense of of CAfile<= br> > setting, postfix would treat 0/1 like 2/3? =C2=A0Or did I miss a chang= e?

The mapping from 0/1 to 2/3 is best effort. =C2=A0With 1 it just work= s,
with 0 it fails with matching type !=3D 0.

Also Wes convinced me that we should not promise this behaviour in
the draft. =C2=A0Therefore, while Postfix may map 0/1 to 2/3 as best it
can the draft behaviour for these is undefined and SMTP servers
SHOULD NOT publish these usages.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.
_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane

--001a11c24576ad09d204e5a973a9-- From ajs@anvilwalrusden.com Thu Sep 5 14:29:26 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7DBA21E811E for ; Thu, 5 Sep 2013 14:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.835 X-Spam-Level: X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeXj3IBeLnP9 for ; Thu, 5 Sep 2013 14:29:20 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 689FA21E8109 for ; Thu, 5 Sep 2013 14:29:18 -0700 (PDT) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id C57598A031 for ; Thu, 5 Sep 2013 21:29:16 +0000 (UTC) Date: Thu, 5 Sep 2013 17:29:33 -0400 From: Andrew Sullivan To: dane@ietf.org Message-ID: <20130905212933.GI61351@mx1.yitter.info> References: <20130904144549.GA29796@mournblade.imrryr.org> <20130905010924.GM29796@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 21:29:26 -0000 On Thu, Sep 05, 2013 at 02:17:39PM -0700, Ian Fette (イアンフェッティ) wrote: > 1. Ignore it and do what you would have done had you not seen the TLSA > record (per the DANE spec) > 2. Ignore the fact that it's lacking DNSSEC and treat it as "I should only > send mail over TLS and expect the following cert" Why do you think (2) provides any advantage over (1)? If someone is actually in a position to MITM your SMTP connections, surely spoofing the odd TLSA record is going to be pretty easy, no? The only protection you have in that case is DNSSEC, I think? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From viktor1dane@dukhovni.org Thu Sep 5 14:56:59 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB07D21E8144 for ; Thu, 5 Sep 2013 14:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CnSkHV4g7ri for ; Thu, 5 Sep 2013 14:56:55 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 7481B21E8137 for ; Thu, 5 Sep 2013 14:56:55 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D02A32AB085; Thu, 5 Sep 2013 21:56:48 +0000 (UTC) Date: Thu, 5 Sep 2013 21:56:48 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130905215648.GT29796@mournblade.imrryr.org> References: <20130904144549.GA29796@mournblade.imrryr.org> <20130905010924.GM29796@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 21:57:00 -0000 On Thu, Sep 05, 2013 at 02:17:39PM -0700, Ian Fette (????????) wrote: > My reading of DANE says that if a TLSA record is not verified by DNSSEC, > you should basically ignore it. Correct. RFC 6698 specifies that TLSA RRs are only valid in "secure" zones. > On SMTP, today you're going to connect on port 25, and you're going > to either not see STARTTLS in which case you presumably will send > mail unencrypted, or you will see STARTTLS and as we discussed > earlier in this thread, probably just take whatever certificate > you get and hope for the best. If all you want is protection against passive eavesdropping, opportunistic TLS (without DANE) is sufficient. The attacker cannot suppress STARTTLS (after all the attacker is *passive* by hypothesis). If you have an active attack (man in the middle), where STARTTLS can be supress, it is trivial to also supress insecure DNS responses. In fact, for many adversaries, it is likely easier to forge DNS replies than to interpose themselves into the middle of a network connection. So I don't think there's much point in processing insecure TLSA responses. Postfix typically does not even bother with the query. TLSA RRs are queried for each MX host only when the MX RRset was secure. When the MX host names can't be trusted, no TLSA query is issued. So bottom-line, no support for insecure TLSA RRs in Postfix at this time. Postfix also has a "dane-only" security mode which can be enabled for selected destinations. This requires successful DANE authentication of the destination's SMTP servers, the code for that use-case definitely must not honour insecure TLSA RRs, and it would complicate the implementation to handle DNS lookups for "opportunistic" and "mandatory" DANE differently. In terms of DNSSEC adoption, aside from paypal.com, which is in a very different market segment, comcast.net and comcast.com have been secured with DNSSEC for quite some time now. They have not yet published TLSA RRs for their MX hosts, if anyone knows the email administrators at comcast well enough to nudge them in the right direction, please do so... -- Viktor. From ifette@google.com Thu Sep 5 14:57:30 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9756A21E8129 for ; Thu, 5 Sep 2013 14:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19Htam2tjvj6 for ; Thu, 5 Sep 2013 14:57:29 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 43AAB21E811E for ; Thu, 5 Sep 2013 14:57:25 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id v2so1298748qcr.34 for ; Thu, 05 Sep 2013 14:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jISqIILe2DN44uX6d7xS9XpC9CGq7bvTc2HtJEt82gY=; b=WJAFhVOWih5Z9PQdGMcookJ7lgH5kVemVBoTkyCr/lFvpdmRFt2d2h1A3Nc/hePySB tf/S+qykP0AppW2p59FsVsNOf21NuyPwxBhJwvFmu1aWpLb9HWDNLQPYb7AKkIlQnJjG g2UQ9fTykgz9tpi0n8S4YIPWxPKtt1meiV4h+OVV2DUbxm33Pjf3UbukgxE5qJxr2B96 V5Hu6CWncyP6qR+HCYUdWVl9Juz9Zuw7xH6Z/WjCvhCFGW7svYcZS0IXYcepD1T+hP9+ Pb9yxvU/KZ4SNoGJSYYJE6FVDmaU/ZmbvK4wZqanVVrTzAK7R6LNWo6WC7yHpQg4Zsr2 qguA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jISqIILe2DN44uX6d7xS9XpC9CGq7bvTc2HtJEt82gY=; b=QOKMNFSlD817vZSbMgQUOln+CjffJUQ0AkAvhYsqG9727sWnajoolkrCCBhtROB7ZH 9ORp1vQ7miu4Tc74UG1ViS0Q4sMBpRpFlpTuEvUaBkErLUNRW20ikCQT30f9QCifv8TK Yv4jhJqmMmP6FHUgumxiPzHuvCdsVyJlLRk6mrdY3Ted1pIACY1Y64ob3FXzWdHzPP4L TJQDflW7kiNndDMBBK0os/7MN/8WwK2au9+nqvtwQ7vOxurcPwOrkoDTRmjnGtA47o4K saS2xYlTmL1sTtC+6wNKMxR7NTbATn8jXFn5MXeVKRLYg8U4PWz8mAx+TVN4BR4Fclw1 eAOw== X-Gm-Message-State: ALoCoQmTwJTc3LtNiWA3OFoqRT7aehkiU23xOccbedd9ZyNrVD7fy1Aynhn//d0aw/OHem0gN3GBflMHbTu4+hmFMWVyObx6RO5IJswnxdxMfzkUItjFhRyxDyoBb6J0HuevmcGGjlaa4eAHm9dlVZ4W94WLiA1G8k4E8AwrUL/HmHTIz2N+/9wamr9OBKZ06U/gV2jz6fUW MIME-Version: 1.0 X-Received: by 10.224.44.10 with SMTP id y10mr354451qae.88.1378418244603; Thu, 05 Sep 2013 14:57:24 -0700 (PDT) Received: by 10.229.62.132 with HTTP; Thu, 5 Sep 2013 14:57:24 -0700 (PDT) In-Reply-To: <20130905212933.GI61351@mx1.yitter.info> References: <20130904144549.GA29796@mournblade.imrryr.org> <20130905010924.GM29796@mournblade.imrryr.org> <20130905212933.GI61351@mx1.yitter.info> Date: Thu, 5 Sep 2013 14:57:24 -0700 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: Andrew Sullivan Content-Type: multipart/alternative; boundary=047d7bdc885cd26f3404e5aa013f Cc: dane@ietf.org Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ifette@google.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 21:57:30 -0000 --047d7bdc885cd26f3404e5aa013f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Let's say that you want to know a-priori if an email will be sent over TLS. Three german companies are doing this already ("Email made in germany" campaign between web.de, gmx, and t-online) where they show their users distinguishing UI if the mail is being sent "securely". It's an interesting to see how that would work out, and personally I find it a very difficult UI challenge to communicate something meaningful that won't be misinterpreted, but anyhow... (2) gives you a signal that you could potentially pass on to a user, and then the user can potentially make a decision about whether or not they want to send the email. I think it needs a bit more thinking and UX studies as to whether or not this is a good idea, but having a signal like that does enable such use cases. It also provides a signal that services can potentially cache as to whether the recipient believes their STARTTLS support is reliable or not. E.g. if we see such a record and don't see STARTTLS, we may decide to bounce (or hold) the message until we see STARTTLS again. If we've seen that record and it disappears as well as STARTTLS support disappearing, that might be a stronger signal that there's a potential MITM attack or strangeness than simply seeing STARTTLS disappear alone. Basically, it's extra information, which opens up a few possibilities, and although it doesn't itself prevent an active MITM who is capable of DNS cache poisoning, it does provide extra information for use in heuristics and doesn't "hurt". On Thu, Sep 5, 2013 at 2:29 PM, Andrew Sullivan wro= te: > On Thu, Sep 05, 2013 at 02:17:39PM -0700, Ian Fette (=E3=82=A4=E3=82=A2= =E3=83=B3=E3=83=95=E3=82=A7=E3=83=83=E3=83=86=E3=82=A3) wrote: > > > 1. Ignore it and do what you would have done had you not seen the TLSA > > record (per the DANE spec) > > 2. Ignore the fact that it's lacking DNSSEC and treat it as "I should > only > > send mail over TLS and expect the following cert" > > Why do you think (2) provides any advantage over (1)? If someone is > actually in a position to MITM your SMTP connections, surely spoofing > the odd TLSA record is going to be pretty easy, no? The only > protection you have in that case is DNSSEC, I think? > > Best, > > A > > > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --047d7bdc885cd26f3404e5aa013f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Let's say that you want to know a-priori if an email w= ill be sent over TLS. Three german companies are doing this already ("= Email made in germany" campaign between web.= de, gmx, and t-online) where they show their users distinguishing UI if= the mail is being sent "securely". It's an interesting to se= e how that would work out, and personally I find it a very difficult UI cha= llenge to communicate something meaningful that won't be misinterpreted= , but anyhow... (2) gives you a signal that you could potentially pass on t= o a user, and then the user can potentially make a decision about whether o= r not they want to send the email. I think it needs a bit more thinking and= UX studies as to whether or not this is a good idea, but having a signal l= ike that does enable such use cases.

It also provides a signal that services can potentially cach= e as to whether the recipient believes their STARTTLS support is reliable o= r not. E.g. if we see such a record and don't see STARTTLS, we may deci= de to bounce (or hold) the message until we see STARTTLS again. If we'v= e seen that record and it disappears as well as STARTTLS support disappeari= ng, that might be a stronger signal that there's a potential MITM attac= k or strangeness than simply seeing STARTTLS disappear alone.=C2=A0

Basically, it's extra information, which opens up a= few possibilities, and although it doesn't itself prevent an active MI= TM who is capable of DNS cache poisoning, it does provide extra information= for use in heuristics and doesn't "hurt".


On Thu,= Sep 5, 2013 at 2:29 PM, Andrew Sullivan <ajs@anvilwalrusden.com&= gt; wrote:
On Thu, Sep 05, 2013 at 02= :17:39PM -0700, Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3= =83=83=E3=83=86=E3=82=A3) wrote:

> 1. Ignore it and do what you would have done had you not seen the TLSA=
> record (per the DANE spec)
> 2. Ignore the fact that it's lacking DNSSEC and treat it as "= I should only
> send mail over TLS and expect the following cert"

Why do you think (2) provides any advantage over (1)? =C2=A0If someon= e is
actually in a position to MITM your SMTP connections, surely spoofing
the odd TLSA record is going to be pretty easy, no? =C2=A0The only
protection you have in that case is DNSSEC, I think?

Best,

A



--
Andrew Sullivan
ajs@anvilwalrusden.com
_____________________= __________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane

--047d7bdc885cd26f3404e5aa013f-- From ifette@google.com Thu Sep 5 15:12:09 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7992321E8155 for ; Thu, 5 Sep 2013 15:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.591 X-Spam-Level: X-Spam-Status: No, score=-1.591 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtXYwoLF7mCW for ; Thu, 5 Sep 2013 15:12:08 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E23F721E816A for ; Thu, 5 Sep 2013 15:12:05 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id u16so5208233iet.34 for ; Thu, 05 Sep 2013 15:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=aZLAqWQA1MbOf86cdzKjRR6+vNGyVi7UoaFfJlXejOM=; b=KMqjnpfFZrudjq/zKRLHSoQo773FtKiSZQkiNHVeUdUJAlxtX/5EXbzENz7BQvK6vF 4gOsjaUg+Ci/ft8+yny9vDem/XbyJmqn2mUS6G7MfHSI1Rgw2vHRNciBq9uvZWQVxxHv /8hr4ZOUVfa6xHK5M5sCY+mRW7IATHUH4m5C1aWgq8qaT19t7f2ne7anxuiJ+RUHF92F 67deKuSe52amExKfSSUX0GJUiBCad8hk4X9g865yx88b9lCM6s3noQQte6d3S5JvwODi qmqDFkBzX3m7se9v/QQyBZLxd6OppvwtacCV/rSlY1TqMOTKlyyiW8oKt2gTG5d93Ek3 Pk/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=aZLAqWQA1MbOf86cdzKjRR6+vNGyVi7UoaFfJlXejOM=; b=Ng2tbOEYXLcDnibmRSMNZyfAlVv8L+XEgM2AqPhsl1FSwJyuK7ULh4PPxPdgRVct/5 kr6aVi4Uh9N/0P6o2JP/AuoPkpmQOUQLndmhojIak+hafiRB+DRaDt7jCd2L553t/DVH CejN2WpL+DZlZ5n3PrHE6GoGIjjXcmI0yKmxfp/SXG+qJENOIgWa5cdUvFvlsW3TSel1 se2697mBm+4T3D3xKPnsL3hTL8Nv+maHZ6QWW0I2dFHhw72pwf1SUgcBSyZkjeOmumNc uaOlObO14nDIq/bolypIxGTqjJbb/Fn4iwDczvOyS3WbRolvG4cGUyR75+CMvpdthkeZ zGYA== X-Gm-Message-State: ALoCoQmCPYz1uQYDBZd+sSUV+ZfPK/Wn95no5X8IIepCg/NREKyRDsIBGQJMlrMFg0uOSCP+BunCESzxHU4EQQ4SPnoC9XfAr4bgfKMTH0YcSgUgXPYNqMBNLoA2PtSpuClBTnNg6/kCMQarjtj2giwxo+Yf3Un69tMkP4ycMd6xnS4MaVEWwhQTQvCoQP+NSMxY+nu7zEln MIME-Version: 1.0 X-Received: by 10.50.25.39 with SMTP id z7mr7584592igf.59.1378419125334; Thu, 05 Sep 2013 15:12:05 -0700 (PDT) Received: by 10.231.161.70 with HTTP; Thu, 5 Sep 2013 15:12:05 -0700 (PDT) In-Reply-To: <20130905215648.GT29796@mournblade.imrryr.org> References: <20130904144549.GA29796@mournblade.imrryr.org> <20130905010924.GM29796@mournblade.imrryr.org> <20130905215648.GT29796@mournblade.imrryr.org> Date: Thu, 5 Sep 2013 15:12:05 -0700 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: dane@ietf.org Content-Type: multipart/alternative; boundary=047d7bd76898516bc504e5aa369a Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ifette@google.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 22:12:09 -0000 --047d7bd76898516bc504e5aa369a Content-Type: text/plain; charset=UTF-8 You mention that you only bother if the MX RRset was secure. In the Gmail case, we've got a lot of customers using "google apps for your domains". We tell them to point their MX records to e.g. ASPMX.L.GOOGLE.COM Let's say hypothetically ianfette.com has an MX record for ASPMX.L.GOOGLE.COM but the administrator of ianfette.com can't be bothered to set up DNSSEC. That implies that even if google.com had deployed DNSSEC and _25._tcp.ASPMX.L.GOOGLE.COM existed that would be ignored? On Thu, Sep 5, 2013 at 2:56 PM, Viktor Dukhovni wrote: > On Thu, Sep 05, 2013 at 02:17:39PM -0700, Ian Fette (????????) wrote: > > > My reading of DANE says that if a TLSA record is not verified by DNSSEC, > > you should basically ignore it. > > Correct. RFC 6698 specifies that TLSA RRs are only valid in "secure" > zones. > > > On SMTP, today you're going to connect on port 25, and you're going > > to either not see STARTTLS in which case you presumably will send > > mail unencrypted, or you will see STARTTLS and as we discussed > > earlier in this thread, probably just take whatever certificate > > you get and hope for the best. > > If all you want is protection against passive eavesdropping, > opportunistic TLS (without DANE) is sufficient. The attacker cannot > suppress STARTTLS (after all the attacker is *passive* by hypothesis). > > If you have an active attack (man in the middle), where STARTTLS > can be supress, it is trivial to also supress insecure DNS responses. > In fact, for many adversaries, it is likely easier to forge DNS > replies than to interpose themselves into the middle of a network > connection. > > So I don't think there's much point in processing insecure TLSA > responses. Postfix typically does not even bother with the query. > TLSA RRs are queried for each MX host only when the MX RRset was > secure. When the MX host names can't be trusted, no TLSA query is > issued. So bottom-line, no support for insecure TLSA RRs in Postfix > at this time. > > Postfix also has a "dane-only" security mode which can be enabled > for selected destinations. This requires successful DANE authentication > of the destination's SMTP servers, the code for that use-case > definitely must not honour insecure TLSA RRs, and it would complicate > the implementation to handle DNS lookups for "opportunistic" and > "mandatory" DANE differently. > > In terms of DNSSEC adoption, aside from paypal.com, which is in a > very different market segment, comcast.net and comcast.com have > been secured with DNSSEC for quite some time now. They have not > yet published TLSA RRs for their MX hosts, if anyone knows the > email administrators at comcast well enough to nudge them in > the right direction, please do so... > > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --047d7bd76898516bc504e5aa369a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You mention that you only bother if the MX RRset was secur= e.

In the Gmail case, we've got a lot of customers u= sing "google apps for your domains". We tell them to point their = MX records to e.g.=C2=A0ASPMX.L.GOOGLE.COM

Let's say hypothetically ianfette.com has an MX record for=C2=A0ASPMX.L.GOO= GLE.COM but the administrator of ianfet= te.com can't be bothered to set up DNSSEC. That implies that even i= f google.com had deployed DNSSEC and _25.= _tcp.ASPMX.L.GOOGLE.COM existed that would be ignored?


On Thu,= Sep 5, 2013 at 2:56 PM, Viktor Dukhovni <viktor1dane@dukhovni.org<= /a>> wrote:
On Thu, Sep 05, 2013 at 02= :17:39PM -0700, Ian Fette (????????) wrote:

> My reading of DANE says that if a TLSA record is not verified by DNSSE= C,
> you should basically ignore it.

Correct. =C2=A0RFC 6698 specifies that TLSA RRs are only valid in &qu= ot;secure" zones.

> On SMTP, today you're going to connect on port 25, and you're = going
> to either not see STARTTLS in which case you presumably will send
> mail unencrypted, or you will see STARTTLS and as we discussed
> earlier in this thread, probably just take whatever certificate
> you get and hope for the best.

If all you want is protection against passive eavesdropping,
opportunistic TLS (without DANE) is sufficient. =C2=A0The attacker cannot suppress STARTTLS (after all the attacker is *passive* by hypothesis).

If you have an active attack (man in the middle), where STARTTLS
can be supress, it is trivial to also supress insecure DNS responses.
In fact, for many adversaries, it is likely easier to forge DNS
replies than to interpose themselves into the middle of a network
connection.

So I don't think there's much point in processing insecure TLSA
responses. =C2=A0Postfix typically does not even bother with the query.
TLSA RRs are queried for each MX host only when the MX RRset was
secure. =C2=A0When the MX host names can't be trusted, no TLSA query is=
issued. =C2=A0So bottom-line, no support for insecure TLSA RRs in Postfix at this time.

Postfix also has a "dane-only" security mode which can be enabled=
for selected destinations. =C2=A0This requires successful DANE authenticati= on
of the destination's SMTP servers, the code for that use-case
definitely must not honour insecure TLSA RRs, and it would complicate
the implementation to handle DNS lookups for "opportunistic" and<= br> "mandatory" DANE differently.

In terms of DNSSEC adoption, aside from paypal.com, which is in a
very different market segment, comcast.net and c= omcast.com have
been secured with DNSSEC for quite some time now. =C2=A0They have not
yet published TLSA RRs for their MX hosts, if anyone knows the
email administrators at comcast well enough to nudge them in
the right direction, please do so...

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.
_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane

--047d7bd76898516bc504e5aa369a-- From viktor1dane@dukhovni.org Thu Sep 5 15:24:20 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA1221E8162 for ; Thu, 5 Sep 2013 15:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.315 X-Spam-Level: X-Spam-Status: No, score=-2.315 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XsAfgXY2PkY for ; Thu, 5 Sep 2013 15:24:12 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7ED21E8155 for ; Thu, 5 Sep 2013 15:24:12 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CBCB72AB085; Thu, 5 Sep 2013 22:24:10 +0000 (UTC) Date: Thu, 5 Sep 2013 22:24:10 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130905222410.GU29796@mournblade.imrryr.org> References: <20130904144549.GA29796@mournblade.imrryr.org> <20130905010924.GM29796@mournblade.imrryr.org> <20130905215648.GT29796@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 22:24:20 -0000 On Thu, Sep 05, 2013 at 03:12:05PM -0700, Ian Fette (????????) wrote: > You mention that you only bother if the MX RRset was secure. Correct. > In the Gmail case, we've got a lot of customers using "google apps for your > domains". We tell them to point their MX records to e.g. ASPMX.L.GOOGLE.COM Yes, I've seen such domains. > Let's say hypothetically ianfette.com has an MX record for > ASPMX.L.GOOGLE.COM but the administrator of ianfette.com can't be bothered > to set up DNSSEC. That implies that even if google.com had deployed DNSSEC > and _25._tcp.ASPMX.L.GOOGLE.COM existed that would be ignored? Correct. A chain is only as strong as its weakest link. When the original MX RRset is insecure, the base domain for the TLSA RR is subject to compromise. There is then no point in making TLSA lookups even if the MX host domain is DNSSEC validated. A domain only benefits from DANE, when *it* adopts DNSSEC. If it out-source MX service, the hosting domain also needs adopt DNSSEC. ; client record in signed zone ; example.com. IN MX 0 mx.example.net. ; provider record in signed zone. ; mx.example.net. IN A 192.0.2.1 _25._tcp.mx.example.net. IN TLSA 3 1 1 ... If either zone is insecure, TLSA records are ignored. I think this should not dissuade you from implementing DANE, there are plenty of users to protect in gmail.com itself. If client domains have more reason to implement DNSSEC, that's for the better. -- Viktor. From ifette@google.com Thu Sep 5 15:34:32 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDCA21E8177 for ; Thu, 5 Sep 2013 15:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fx0XRFVFNkDf for ; Thu, 5 Sep 2013 15:34:31 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 42C6021E8127 for ; Thu, 5 Sep 2013 15:34:31 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id a14so5062289iee.40 for ; Thu, 05 Sep 2013 15:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=rlPS1vXwka4q8fbrX06xOjr2I5/3TQEuJ2ioFrJ5YjI=; b=WPew7Wjaze5KWRal/vDlz+hDHzcS510tRmdYTiJMFjKO9SBIvDBErzfgWJF5shkkdi nodNkbkz4sgTgELE4hcAmDXd9K0k1T56/rSL4Ugk5nH2W7w7l4/8qm2GU1l0s4WwLQWS 13cN4qaosB9Q7kyxo4xY4vrhAA+tb4XMB7UpBtOl/W8oDktRw5VSxTTj1MMOqas29ShZ rzQFBW0dwUHfIWs+ko0510jV9o+DcPKqbL6u0lpjbfFEO56DLW5RIxHjb1bKmGMrqxm8 /qQ/jSMfel3hPuKgEb0LgR+YPdkHBQYus5NViNT9uMfhCHRX1SFPRayP67KM4zi2dgQm bW9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=rlPS1vXwka4q8fbrX06xOjr2I5/3TQEuJ2ioFrJ5YjI=; b=ZkrZE9haoVL6qMFvBN5C3EFQVBTzeKMz3Z93gZa3J0ZMpLY8wER+TfxtrxTUoUJvLH a4Q9hasAguGxZewxsjlEmfGi4bBS4vRAPa5gm7Ea5fREiZsb5ByG9x7zWABmHBFX2vYG vCHOmg2lOKOeYZOlRhOySID340oLTI/WKMJo4Uzy1KMhHMUxEMV6K1X1Q42nyh9UneAd xWkpDDoOg+cu20f3LpwDFBpy/piJ6zqyyW1NGB3pZWhTd8pOTb5ZocV6VhstE0Y3gZ1p K1EPsPMykPBk2gANnoxHENnhZkV4LEZyTJxmaVbm7UdWAP8iBLwCIeMk+hcjIM88vqG6 OjHA== X-Gm-Message-State: ALoCoQkhKAXgJiyF5awyYLT0wxe0RKEUG6uSL6pW4T7rGqA/LvH62FjULCQX0zj5DlYvH9/9u6Jjz6NPDC4tjI7Db+q6LSbzkHxgHN/F26L8jw2ZBM2dOgdbdaIMgnAlQGQ+xohA1LqXO1eAFOohTl0x/PDzyeL+6fyeBEBDKxLopZMxILa2Yq5s/CMmImjO+T/RP2UIdZcv MIME-Version: 1.0 X-Received: by 10.50.30.9 with SMTP id o9mr7965800igh.0.1378420470682; Thu, 05 Sep 2013 15:34:30 -0700 (PDT) Received: by 10.231.161.70 with HTTP; Thu, 5 Sep 2013 15:34:30 -0700 (PDT) In-Reply-To: <20130905222410.GU29796@mournblade.imrryr.org> References: <20130904144549.GA29796@mournblade.imrryr.org> <20130905010924.GM29796@mournblade.imrryr.org> <20130905215648.GT29796@mournblade.imrryr.org> <20130905222410.GU29796@mournblade.imrryr.org> Date: Thu, 5 Sep 2013 15:34:30 -0700 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: dane@ietf.org Content-Type: multipart/alternative; boundary=047d7bd76aea81bb2e04e5aa862f Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ifette@google.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2013 22:34:32 -0000 --047d7bd76aea81bb2e04e5aa862f Content-Type: text/plain; charset=UTF-8 It seems like we're letting the perfect be the enemy of the good. At the end of the day, what I would like to signal is that servers should expect to talk to Google's mail servers using TLS. I would also like to know what servers expect Google to talk to them using TLS. There are a few ways I can think of accomplishing this, one being DANE, another being something similar to HSTS (RFC6797), and I'm sure we can come up with a fair number of other mechanisms as well. Each of them has their drawbacks. I would love it if I could deploy DNSSEC on google.com tomorrow, but much as I may want that it's not going to happen overnight. HSTS-style approaches don't let me know a-priori what to expect from a new domain, but given our scale that's not actually such a huge problem. As such, I'm trying to understand what incremental steps I actually _can_ take. And so here we are choosing between options that offer some additional benefit but don't solve all problems, as is often the case in the messiness of the real world, and I'm hoping that perfect need not be the enemy of the good. On Thu, Sep 5, 2013 at 3:24 PM, Viktor Dukhovni wrote: > On Thu, Sep 05, 2013 at 03:12:05PM -0700, Ian Fette (????????) wrote: > > > You mention that you only bother if the MX RRset was secure. > > Correct. > > > In the Gmail case, we've got a lot of customers using "google apps for > your > > domains". We tell them to point their MX records to e.g. > ASPMX.L.GOOGLE.COM > > Yes, I've seen such domains. > > > Let's say hypothetically ianfette.com has an MX record for > > ASPMX.L.GOOGLE.COM but the administrator of ianfette.com can't be > bothered > > to set up DNSSEC. That implies that even if google.com had deployed > DNSSEC > > and _25._tcp.ASPMX.L.GOOGLE.COM existed that would be ignored? > > Correct. A chain is only as strong as its weakest link. When the > original MX RRset is insecure, the base domain for the TLSA RR is > subject to compromise. There is then no point in making TLSA > lookups even if the MX host domain is DNSSEC validated. > > A domain only benefits from DANE, when *it* adopts DNSSEC. If it > out-source MX service, the hosting domain also needs adopt DNSSEC. > > ; client record in signed zone > ; > example.com. IN MX 0 mx.example.net. > > ; provider record in signed zone. > ; > mx.example.net. IN A 192.0.2.1 > _25._tcp.mx.example.net. IN TLSA 3 1 1 ... > > If either zone is insecure, TLSA records are ignored. > > I think this should not dissuade you from implementing DANE, there > are plenty of users to protect in gmail.com itself. If client > domains have more reason to implement DNSSEC, that's for the better. > > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --047d7bd76aea81bb2e04e5aa862f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It seems like we're letting the perfect be the enemy o= f the good. At the end of the day, what I would like to signal is that serv= ers should expect to talk to Google's mail servers using TLS. I would a= lso like to know what servers expect Google to talk to them using TLS. Ther= e are a few ways I can think of accomplishing this, one being DANE, another= being something similar to HSTS (RFC6797), and I'm sure we can come up= with a fair number of other mechanisms as well. Each of them has their dra= wbacks. I would love it if I could deploy DNSSEC on google.com tomorrow, but much as I may want that it's not go= ing to happen overnight. HSTS-style approaches don't let me know a-prio= ri what to expect from a new domain, but given our scale that's not act= ually such a huge problem. As such, I'm trying to understand what incre= mental steps I actually _can_ take. And so here we are choosing between opt= ions that offer some additional benefit but don't solve all problems, a= s is often the case in the messiness of the real world, and I'm hoping = that perfect need not be the enemy of the good.




On Thu, Sep 5, 2013 at 3:24 PM, Viktor Dukhovni <= viktor1dane@dukhovni.org> wrote:
On Thu, Sep 05, 2013 at 03= :12:05PM -0700, Ian Fette (????????) wrote:

> You mention that you only bother if the MX RRset was secure.

Correct.

> In the Gmail case, we've got a lot of customers using "google= apps for your
> domains". We tell them to point their MX records to e.g. ASPMX.L.GOOGLE.COM

Yes, I've seen such domains.

> Let's say hypothetically ianfette.com has an MX record for
> ASPMX.L.GOOGLE= .COM but the administrator of ianfette.com can't be bothered
> to set up DNSSEC. That implies that even if google.com had deployed DNSSEC
> and _25._t= cp.ASPMX.L.GOOGLE.COM existed that would be ignored?

Correct. =C2=A0A chain is only as strong as its weakest link. =C2=A0W= hen the
original MX RRset is insecure, the base domain for the TLSA RR is
subject to compromise. =C2=A0There is then no point in making TLSA
lookups even if the MX host domain is DNSSEC validated.

A domain only benefits from DANE, when *it* adopts DNSSEC. =C2=A0If it
out-source MX service, the hosting domain also needs adopt DNSSEC.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ; client record in signed zone
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 example.com. =C2=A0 =C2=A0IN MX 0 mx.example.net.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ; provider record in signed zone.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mx.example.net. IN A 192.0.2.1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 _25._tcp.mx.example.net. IN TLSA 3 1 1 ...

If either zone is insecure, TLSA records are ignored.

I think this should not dissuade you from implementing DANE, there
are plenty of users to protect in gmail.com itself. =C2=A0If client
domains have more reason to implement DNSSEC, that's for the better.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.
_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane

--047d7bd76aea81bb2e04e5aa862f-- From viktor1dane@dukhovni.org Thu Sep 5 17:23:59 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCC021E8051 for ; Thu, 5 Sep 2013 17:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0v-7WUYtzCoq for ; Thu, 5 Sep 2013 17:23:49 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id B70B211E8209 for ; Thu, 5 Sep 2013 17:23:49 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 33B662AB086; Fri, 6 Sep 2013 00:23:44 +0000 (UTC) Date: Fri, 6 Sep 2013 00:23:44 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130906002344.GV29796@mournblade.imrryr.org> References: <20130904144549.GA29796@mournblade.imrryr.org> <20130905010924.GM29796@mournblade.imrryr.org> <20130905215648.GT29796@mournblade.imrryr.org> <20130905222410.GU29796@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 00:23:59 -0000 On Thu, Sep 05, 2013 at 03:34:30PM -0700, Ian Fette (????????) wrote: > It seems like we're letting the perfect be the enemy of the good. Not really. Rather, one should resist the urge to draw overly close analogies between the security models of SMTP and HTTP. 1. With HTTP the security properties of the channel are encoded in the destination address (URL) and connections are *direct* to the selected destination. With SMTP there is no security indication in the email address, and deliveries are indirect via MX records. 2. With HTTP there is typically an interactive user to click OK, with MTA to MTA SMTP there is not. 3. With HTTP the user is often found at WiFi hotspots and other high risk for MITM environments. With MTA to MTA SMTP, the networks are generally over fixed wiring in more physically secure locations. 4. With HTTPS the application protocol inside SSL/TLS, the client needs prior knowledge of whether to connect over SSL. With MTA to MTA SMTP TLS is negotiated over SMTP, there is no need for prior configuration. > At the > end of the day, what I would like to signal is that servers should expect > to talk to Google's mail servers using TLS. STARTTLS already does this, with each and every SMTP connection. An MITM attacker can simply redirect the SMTP client to a different set of MX hosts. > I would also like to know what servers expect Google to talk to > them using TLS. Those would be the ones that respond with STARTTLS. With DANE, this response becomes downgrade resistant, and provides certificate associations that make it possible to authenticate the peer MTA even when it is (as most are) self-issued. I strongly encourage you to consider implementing DANE in the Google SMTP client. This does not require Google to sign their own domains, just query a DNSSEC-aware resolver (akin to the ones offering the public DNS service on 8.8.8.8). > There are a few ways I can > think of accomplishing this, one being DANE, another being something > similar to HSTS (RFC6797). HSTS is not terribly useful for SMTP. Given MX indirection, and relatively short MX TTLs, the attacker need only wait for the next MX query, and HSTS is defeated. Caching MX RRs beyond the advertised TTL is not a viable option. > I would love it if I could deploy DNSSEC on google.com tomorrow, but > much as I may want that it's not going to happen overnight. Yes, but perhaps between you, Warren, perhaps Ben and others, the immovable object might budge after all. > HSTS-style approaches don't let me > know a-priori what to expect from a new domain, but given our scale that's > not actually such a huge problem. As such, I'm trying to understand what > incremental steps I actually _can_ take. As an initial step it is enough to support STARTTLS in both the SMTP client and server roles. To harden this against active MITM attacks, sadly you need to harden DNS, as the SMTP destination is determined indirectly via DNS MX lookups. SMTP security is not possible without DNS security. > And so here we are choosing > between options that offer some additional benefit but don't solve all > problems, as is often the case in the messiness of the real world, and I'm > hoping that perfect need not be the enemy of the good. DANE is definitely not perfect, but it fits the requirements of downgrade resistant opportunistic TLS for SMTP. It is tempting to apply lessons learned in browser security to SMTP, but many don't carry over. -- Viktor. From ifette@google.com Thu Sep 5 18:18:01 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F34F21E8193 for ; Thu, 5 Sep 2013 18:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpOZ5tuLJLUI for ; Thu, 5 Sep 2013 18:17:59 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id B05FB21E8179 for ; Thu, 5 Sep 2013 18:17:59 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id y16so288468ieg.12 for ; Thu, 05 Sep 2013 18:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=SUsezr5hyzT2mwadHEpQEpnGYYBA3r9TW66zwt8VSdM=; b=Y5xO8AA3CEk46UYHNpNLBa9I788uHTqIYKegPi/p5c6g9QX+Als8nwjOrOuD9S8kVb rvMeZl7pDO0Y9oQNyWxRROrewwNOD9KY/d/S8LNgqbFGwFLHm6xoHp0SUL18k8bk2JSb TzghLJv6ADETIvHiBvJ5aQGHZxmQw6Pyw5PlsnJSKEBZ87dS/YX96mJP/CCZ6THJehic +Ra1g+wAc8JdavynEC6VuCw2fuykdNvuLq6422hgXyxTDh4aSi26n4i6F1XwbW0MdjT/ bqHiJNzjVIcYxHNeDMFmZICx1IUX4cvb6cPZmjTYKJ0wXQhZ1xBLsEszzBbEx4JbkIFZ kJVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=SUsezr5hyzT2mwadHEpQEpnGYYBA3r9TW66zwt8VSdM=; b=TiVGDChQuc9jlg4u8AabZmUV7KkYCBXPNgUs9/j7KOF/cpKtiG8MIw/EJANlRqtbDC tkaPSSCNiUiC60ffXCpW4W9PBpW5chOcriVZoXmGCeM3N5Tn1ZgdwqDbhdAl4vzTL7r9 Q2J8zs7efqgeJmnxLYIQoRyjOeqd6Bed1b50+KZX9lpemoXyUgWaKBfsC0ecD8nM4Cf+ rkYKesc22wdmkwkoQYktXVBizOhnxJ+O0uv/Q/h50rIYz54AFXYKVOqt5kdLqvjHt/Ad lCvIW9CC5Rciio5mYXqattHcoLVuBDJa3/2NBnkeNFESYTXnbP8qOlAjOVw0LwopKAix yiYA== X-Gm-Message-State: ALoCoQntnHUYHwW+OvUnRrPk+Lx6XudIS0H3FQeMCpL9kw5biG8qlje35FE7ToypOC/XMipzlo0/tBrLTfIc8nE3RPZ7Pu9/VKgRG/ArjEHvZiXkjG2hVHlv0GgkKVSvW6EVhBUlxtPKwq2rMRoTBjIqQ5ORrTvyGI3cpkCgECc/g89qcnjGptl/1zhmKpQJJVADqDYw+TX5 MIME-Version: 1.0 X-Received: by 10.50.25.39 with SMTP id z7mr8061885igf.59.1378430276325; Thu, 05 Sep 2013 18:17:56 -0700 (PDT) Received: by 10.231.161.70 with HTTP; Thu, 5 Sep 2013 18:17:55 -0700 (PDT) In-Reply-To: <20130906002344.GV29796@mournblade.imrryr.org> References: <20130904144549.GA29796@mournblade.imrryr.org> <20130905010924.GM29796@mournblade.imrryr.org> <20130905215648.GT29796@mournblade.imrryr.org> <20130905222410.GU29796@mournblade.imrryr.org> <20130906002344.GV29796@mournblade.imrryr.org> Date: Thu, 5 Sep 2013 18:17:55 -0700 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: dane@ietf.org Content-Type: multipart/alternative; boundary=047d7bd76898f8087504e5acce37 Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ifette@google.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 01:18:01 -0000 --047d7bd76898f8087504e5acce37 Content-Type: text/plain; charset=UTF-8 reply inline On Thu, Sep 5, 2013 at 5:23 PM, Viktor Dukhovni wrote: > On Thu, Sep 05, 2013 at 03:34:30PM -0700, Ian Fette (????????) wrote: > > > It seems like we're letting the perfect be the enemy of the good. > > Not really. Rather, one should resist the urge to draw overly > close analogies between the security models of SMTP and HTTP. > > 1. With HTTP the security properties of the channel are encoded in > the destination address (URL) and connections are *direct* to the > selected destination. With SMTP there is no security indication > in the email address, and deliveries are indirect via MX records. > > 2. With HTTP there is typically an interactive user to click OK, with > MTA to MTA SMTP there is not. > Presumably T-Online, web.de and GMX believe that by indicating to a user a-priori whether their email will be sent over an encrypted channel, that the user will make some decision. (See http://www.e-mail-made-in-germany.de/Kennzeichnung.html) - so there is potentially an opportunity for a user decision. > > 3. With HTTP the user is often found at WiFi hotspots and other > high risk for MITM environments. With MTA to MTA SMTP, the networks > are generally over fixed wiring in more physically secure locations. > Wouldn't this argument make DNSSEC less important, if you believe that the MTA-MTA connection is less susceptible to MITM? > > 4. With HTTPS the application protocol inside SSL/TLS, the client > needs prior knowledge of whether to connect over SSL. With MTA to > MTA SMTP TLS is negotiated over SMTP, there is no need for prior > configuration. > I don't know if I would say "no need". We would like to send email only over TLS if we know the other end is TLS aware. Unfortunately, it's difficult to determine if someone is experimenting with TLS on some of their hosts (some servers seem to sporadically advertise STARTTLS and it's not clear if they expect it to be 100% or if they're experimenting), or whether they would expect us to hard fail. I'd love to be able to say to a host "If you do X, we will consider the absence of STARTTLS in your EHLO response to be a critical error and bounce the message". > > > At the > > end of the day, what I would like to signal is that servers should expect > > to talk to Google's mail servers using TLS. > > STARTTLS already does this, with each and every SMTP connection. > An MITM attacker can simply redirect the SMTP client to a different > set of MX hosts. > Yes, which is why I would like a way to signal something more permanent and noticeable than the context of a single SMTP connection. I'd be fine putting a 1 week TTL on a TLSA record; yes it's possible that someone attempts DNS cache poisoning though this is perhaps a bit more difficult with a larger TTL. > > > I would also like to know what servers expect Google to talk to > > them using TLS. > > Those would be the ones that respond with STARTTLS. With DANE, > this response becomes downgrade resistant, and provides certificate > associations that make it possible to authenticate the peer MTA > even when it is (as most are) self-issued. I strongly encourage > you to consider implementing DANE in the Google SMTP client. This > does not require Google to sign their own domains, just query a > DNSSEC-aware resolver (akin to the ones offering the public DNS > service on 8.8.8.8). > It's something we're considering among other options, though it's difficult for us to expect others to deploy this if we ourselves can't deploy it. > > > There are a few ways I can > > think of accomplishing this, one being DANE, another being something > > similar to HSTS (RFC6797). > > HSTS is not terribly useful for SMTP. Given MX indirection, and > relatively short MX TTLs, the attacker need only wait for the > next MX query, and HSTS is defeated. Caching MX RRs beyond the > advertised TTL is not a viable option. > Depends on what you tie HSTS to. In the HTTP case, the HSTS indication is "Thou shalt connect to xyz.com over HTTPS". The TTL of that indication is divorced from the TTL of the A record for xyz.com. > > > I would love it if I could deploy DNSSEC on google.com tomorrow, but > > much as I may want that it's not going to happen overnight. > > Yes, but perhaps between you, Warren, perhaps Ben and others, the > immovable object might budge after all. > I would love that, but I would also love something I could deploy sooner than Warren, Ben and others are likely to be able to deploy dnssec for google.com :) > > > HSTS-style approaches don't let me > > know a-priori what to expect from a new domain, but given our scale > that's > > not actually such a huge problem. As such, I'm trying to understand what > > incremental steps I actually _can_ take. > > As an initial step it is enough to support STARTTLS in both the > SMTP client and server roles. > We already do (and even offer a valid certificate, no less). We'd like to do more. Hence this massive email thread :) > > To harden this against active MITM attacks, sadly you need to harden > DNS, as the SMTP destination is determined indirectly via DNS MX > lookups. SMTP security is not possible without DNS security. > You say SMTP security is not possible without DNS security. One could say the same thing about HTTP security and yet that has not stopped us from making improvements in that area (be they HSTS, certificate pinning, certificate transparency, or any number of other attempts at making incremental improvements without relying on DNSSEC deployment.) > > > And so here we are choosing > > between options that offer some additional benefit but don't solve all > > problems, as is often the case in the messiness of the real world, and > I'm > > hoping that perfect need not be the enemy of the good. > > DANE is definitely not perfect, but it fits the requirements of > downgrade resistant opportunistic TLS for SMTP. > Agreed, unfortunately I can't satisfy all of its prerequisites at the present point in time. > > It is tempting to apply lessons learned in browser security to > SMTP, but many don't carry over. > > I agree. And FWIW, I also agree with most of your points here about deploying without DNSSEC leaving vulnerabilities open, some of which you have enumerated. However, I've yet to hear a good argument for why one would ignore information not protected by DNSSEC. In the case of a TLSA record for HTTPS/443 I understand, I don't understand why one would ignore that information for SMTP/25. > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --047d7bd76898f8087504e5acce37 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
reply inline


On Thu, Sep 5, 2013 at 5:23 PM, Viktor Dukhovni <= viktor1dane@dukhovni.org> wrote:
On Thu, Sep 05, 2013 at 03:34:30PM -0700= , Ian Fette (????????) wrote:

> It seems like we're letting the perfect be the enemy of the good.<= br>
Not really. =C2=A0Rather, one should resist the urge to draw overly close analogies between the security models of SMTP and HTTP.

1. =C2=A0With HTTP the security properties of the channel are encoded in the destination address (URL) and connections are *direct* to the
selected destination. =C2=A0With SMTP there is no security indication
in the email address, and deliveries are indirect via MX records.

2. =C2=A0With HTTP there is typically an interactive user to click OK, with=
MTA to MTA SMTP there is not.

Presumabl= y T-Online, web.de and GMX believe that by in= dicating to a user a-priori whether their email will be sent over an encryp= ted channel, that the user will make some decision. (See=C2=A0http://www.e-mail-ma= de-in-germany.de/Kennzeichnung.html) - so there is potentially an oppor= tunity for a user decision.
=C2=A0

3. =C2=A0With HTTP the user is often found at WiFi hotspots and other
high risk for MITM environments. =C2=A0With MTA to MTA SMTP, the networks are generally over fixed wiring in more physically secure locations.


Wouldn't this argument mak= e DNSSEC less important, if you believe that the MTA-MTA connection is less= susceptible to MITM?
=C2=A0

4. =C2=A0With HTTPS the application protocol inside SSL/TLS, the client
needs prior knowledge of whether to connect over SSL. =C2=A0With MTA to
MTA SMTP TLS is negotiated over SMTP, there is no need for prior
configuration.

I don't know if I wo= uld say "no need". We would like to send email only over TLS if w= e know the other end is TLS aware. Unfortunately, it's difficult to det= ermine if someone is experimenting with TLS on some of their hosts (some se= rvers seem to sporadically advertise STARTTLS and it's not clear if the= y expect it to be 100% or if they're experimenting), or whether they wo= uld expect us to hard fail. I'd love to be able to say to a host "= If you do X, we will consider the absence of STARTTLS in your EHLO response= to be a critical error and bounce the message".
=C2=A0

> At the
> end of the day, what I would like to signal is that servers should exp= ect
> to talk to Google's mail servers using TLS.

STARTTLS already does this, with each and every SMTP connection.
An MITM attacker can simply redirect the SMTP client to a different
set of MX hosts.

Yes, which is why I wo= uld like a way to signal something more permanent and noticeable than the c= ontext of a single SMTP connection. I'd be fine putting a 1 week TTL on= a TLSA record; yes it's possible that someone attempts DNS cache poiso= ning though this is perhaps a bit more difficult with a larger TTL.
=C2=A0

> I would also like to know what servers expect Google to talk to
> them using TLS.

Those would be the ones that respond with STARTTLS. =C2=A0With DANE,<= br> this response becomes downgrade resistant, and provides certificate
associations that make it possible to authenticate the peer MTA
even when it is (as most are) self-issued. =C2=A0I strongly encourage
you to consider implementing DANE in the Google SMTP client. =C2=A0This
does not require Google to sign their own domains, just query a
DNSSEC-aware resolver (akin to the ones offering the public DNS
service on 8.8.8.8).

It's something= we're considering among other options, though it's difficult for u= s to expect others to deploy this if we ourselves can't deploy it.=C2= =A0
=C2=A0

> There are a few ways I can
> think of accomplishing this, one being DANE, another being something
> similar to HSTS (RFC6797).

HSTS is not terribly useful for SMTP. =C2=A0Given MX indirection, and
relatively short MX TTLs, the attacker need only wait for the
next MX query, and HSTS is defeated. =C2=A0Caching MX RRs beyond the
advertised TTL is not a viable option.

= Depends on what you tie HSTS to. In the HTTP case, the HSTS indication is &= quot;Thou shalt connect to xyz.com over HTTP= S". The TTL of that indication is divorced from the TTL of the A recor= d for xyz.com.
=C2=A0

> I would love it if I could deploy DNSSEC on google.com tomorrow, but
> much as I may want that it's not going to happen overnight.

Yes, but perhaps between you, Warren, perhaps Ben and others, the
immovable object might budge after all.

I would love that, but I would also love something I could deploy sooner t= han Warren, Ben and others are likely to be able to deploy dnssec for google.com :)
=C2=A0

> HSTS-style approaches don't let me
> know a-priori what to expect from a new domain, but given our scale th= at's
> not actually such a huge problem. As such, I'm trying to understan= d what
> incremental steps I actually _can_ take.

As an initial step it is enough to support STARTTLS in both the
SMTP client and server roles.

We alread= y do (and even offer a valid certificate, no less). We'd like to do mor= e. Hence this massive email thread :)
=C2=A0

To harden this against active MITM attacks, sadly you need to harden
DNS, as the SMTP destination is determined indirectly via DNS MX
lookups. =C2=A0SMTP security is not possible without DNS security.

You say SMTP security is not possible without D= NS security. One could say the same thing about HTTP security and yet that = has not stopped us from making improvements in that area (be they HSTS, cer= tificate pinning, certificate transparency, or any number of other attempts= at making incremental improvements without relying on DNSSEC deployment.)<= /div>
=C2=A0

> And so here we are choosing
> between options that offer some additional benefit but don't solve= all
> problems, as is often the case in the messiness of the real world, and= I'm
> hoping that perfect need not be the enemy of the good.

DANE is definitely not perfect, but it fits the requirements of
downgrade resistant opportunistic TLS for SMTP.

Agreed, unfortunately I can't satisfy all of its prerequisites= at the present point in time.
=C2=A0

It is tempting to apply lessons learned in browser security to
SMTP, but many don't carry over.


I agree. And FWIW, I also agree with most of your points here about= deploying without DNSSEC leaving vulnerabilities open, some of which you h= ave enumerated. However, I've yet to hear a good argument for why one w= ould ignore information not protected by DNSSEC. In the case of a TLSA reco= rd for HTTPS/443 I understand, I don't understand why one would ignore = that information for SMTP/25.
=C2=A0
--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.
_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane

--047d7bd76898f8087504e5acce37-- From viktor1dane@dukhovni.org Thu Sep 5 18:35:40 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E4121E8197 for ; Thu, 5 Sep 2013 18:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3kPrmUwPjH7 for ; Thu, 5 Sep 2013 18:35:33 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id E1F8521E8092 for ; Thu, 5 Sep 2013 18:35:32 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 712162AB087; Fri, 6 Sep 2013 01:35:32 +0000 (UTC) Date: Fri, 6 Sep 2013 01:35:32 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130906013532.GW29796@mournblade.imrryr.org> References: <20130904144549.GA29796@mournblade.imrryr.org> <20130905010924.GM29796@mournblade.imrryr.org> <20130905215648.GT29796@mournblade.imrryr.org> <20130905222410.GU29796@mournblade.imrryr.org> <20130906002344.GV29796@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 01:35:41 -0000 On Thu, Sep 05, 2013 at 06:17:55PM -0700, Ian Fette (????????) wrote: > However, I've yet to hear a good argument for why one > would ignore information not protected by DNSSEC. In the case of a TLSA > record for HTTPS/443 I understand, I don't understand why one would ignore > that information for SMTP/25. As an MTA developer, I can't think of anything useful I can do with an unauthenticated TLSA record, that I don't already get with STARTTLS. Recall that TLSA records for SMTP are published for the MX hosts only, not the domain. Some of the MX hosts for a domain may support DANE TLSA, others might not. SMTP is very different from HTTP. So even if see long TTL TLSA RRs for a domain's MX hosts one day, a different MX RRset the next day (e.g. cutting over to an MX provider) gives no reason to expect TLS on the new MX hosts. HTTP security is *not* dependent on DNS in the same way, if you trust the public CA PKI, the DNS just provides IP addresses, which must land on a TCP service with the right certificate. This is simply not the case with SMTP. If I am conveying his views correctly, of the things Ben Laurie likes about HTTP with certificate transparency, is that it is in fact largely immune to attacks on DNS. With SMTP, once DNS is compromised there's not much one can do. Sure, companies with known high value business partners can configure static policy enforcing TLS for those destinations, and the current Postfix TLS policy engine is in large part in support of that model. The DANE support in Postfix aims to get beyond that scale, to the Internet at large. Predicated on the assumption that DNSSEC is not a dead-end, and will over the next few years see broad adoption, as management tools and client to registry/registrar interfaces mature. -- Viktor. From andrewgwilson@gmail.com Thu Sep 5 19:00:58 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D5521E8192 for ; Thu, 5 Sep 2013 19:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRNW8UZHwXlO for ; Thu, 5 Sep 2013 19:00:57 -0700 (PDT) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE9A11E8217 for ; Thu, 5 Sep 2013 19:00:56 -0700 (PDT) Received: by mail-bk0-f51.google.com with SMTP id mx10so1061368bkb.24 for ; Thu, 05 Sep 2013 19:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=PNWqxlCbOYF2ztk9wAitx42v/5TBffJia2ekTo4lb2M=; b=uiD/on1Qm7MdxP1WDOkDKyoWtkQtzRlQmPrWiyZWLhHUrsJG9bOFhRWRzwhfHm008r aNYNBG5iohIVzrlskKXuaYuH3f6SiSaILbwLLQKNMGIFlq6nr4U4c6FwfizhIlgJvISv oRway/vEG+P/h6MT4PJCJ88Dzb+ez9C+tMgAspPcy2DuWapBPP2agJ9ToDzJV4XAiOyy m/2Pf+sCE7RuoBPNvNqGD5afG1WAhuLsrWStMpDjOTtin0jXAf5sIzD2OeZ6h5hYnkjU gkzOyFaYkwmgqZpIS1jdscgKpPgZ/mnOWqXUsLKOMAsYiPuGvHupV8sMaXMf6TGvVJgS iRJQ== MIME-Version: 1.0 X-Received: by 10.204.103.5 with SMTP id i5mr8547bko.176.1378432855484; Thu, 05 Sep 2013 19:00:55 -0700 (PDT) Received: by 10.205.18.193 with HTTP; Thu, 5 Sep 2013 19:00:55 -0700 (PDT) In-Reply-To: <20130906013532.GW29796@mournblade.imrryr.org> References: <20130904144549.GA29796@mournblade.imrryr.org> <20130905010924.GM29796@mournblade.imrryr.org> <20130905215648.GT29796@mournblade.imrryr.org> <20130905222410.GU29796@mournblade.imrryr.org> <20130906002344.GV29796@mournblade.imrryr.org> <20130906013532.GW29796@mournblade.imrryr.org> Date: Fri, 6 Sep 2013 14:00:55 +1200 Message-ID: From: Andy Wilson To: dane@ietf.org Content-Type: multipart/alternative; boundary=001a11333bceb2dad304e5ad6868 Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 02:00:58 -0000 --001a11333bceb2dad304e5ad6868 Content-Type: text/plain; charset=UTF-8 These are very interesting discussions! Last year I started thinking about email encryption policies and started writing a RFC; DTSP - Domain-based TLS SMTP Policy. My thinking was to have a policy record (similar to DMARC) which specified encryption types for sending and receiving domains; enforcing STARTTLS basically. If anyone is interested I can share what I was working on. On 6 September 2013 13:35, Viktor Dukhovni wrote: > On Thu, Sep 05, 2013 at 06:17:55PM -0700, Ian Fette (????????) wrote: > > > However, I've yet to hear a good argument for why one > > would ignore information not protected by DNSSEC. In the case of a TLSA > > record for HTTPS/443 I understand, I don't understand why one would > ignore > > that information for SMTP/25. > > As an MTA developer, I can't think of anything useful I can do with > an unauthenticated TLSA record, that I don't already get with > STARTTLS. > > Recall that TLSA records for SMTP are published for the MX hosts > only, not the domain. Some of the MX hosts for a domain may support > DANE TLSA, others might not. SMTP is very different from HTTP. > > So even if see long TTL TLSA RRs for a domain's MX hosts one day, > a different MX RRset the next day (e.g. cutting over to an MX > provider) gives no reason to expect TLS on the new MX hosts. > > HTTP security is *not* dependent on DNS in the same way, if you > trust the public CA PKI, the DNS just provides IP addresses, which > must land on a TCP service with the right certificate. This is > simply not the case with SMTP. > > If I am conveying his views correctly, of the things Ben Laurie > likes about HTTP with certificate transparency, is that it is in > fact largely immune to attacks on DNS. With SMTP, once DNS is > compromised there's not much one can do. > > Sure, companies with known high value business partners can configure > static policy enforcing TLS for those destinations, and the current > Postfix TLS policy engine is in large part in support of that model. > > The DANE support in Postfix aims to get beyond that scale, to the > Internet at large. Predicated on the assumption that DNSSEC is > not a dead-end, and will over the next few years see broad adoption, > as management tools and client to registry/registrar interfaces > mature. > > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > -- Regards Andy --001a11333bceb2dad304e5ad6868 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
These are very interesting discussions!
Last year I st= arted thinking about email encryption policies and started writing a RFC; D= TSP - Domain-based TLS SMTP Policy.

My thinking wa= s to have a policy record (similar to DMARC) which specified encryption typ= es for sending and receiving domains; enforcing STARTTLS basically.

If anyone is interested I can share what I was working = on.


On 6 September 2013 13:35, Viktor Dukhovni <viktor1dane@dukhovni= .org> wrote:
On Thu, Sep 05, 2013 at 06= :17:55PM -0700, Ian Fette (????????) wrote:

> However, I've yet to hear a good argument for why one
> would ignore information not protected by DNSSEC. In the case of a TLS= A
> record for HTTPS/443 I understand, I don't understand why one woul= d ignore
> that information for SMTP/25.

As an MTA developer, I can't think of anything useful I can do wi= th
an unauthenticated TLSA record, that I don't already get with
STARTTLS.

Recall that TLSA records for SMTP are published for the MX hosts
only, not the domain. =C2=A0Some of the MX hosts for a domain may support DANE TLSA, others might not. =C2=A0SMTP is very different from HTTP.

So even if see long TTL TLSA RRs for a domain's MX hosts one day,
a different MX RRset the next day (e.g. cutting over to an MX
provider) gives no reason to expect TLS on the new MX hosts.

HTTP security is *not* dependent on DNS in the same way, =C2=A0if you
trust the public CA PKI, the DNS just provides IP addresses, which
must land on a TCP service with the right certificate. =C2=A0This is
simply not the case with SMTP.

If I am conveying his views correctly, of the things Ben Laurie
likes about HTTP with certificate transparency, is that it is in
fact largely immune to attacks on DNS. =C2=A0With SMTP, once DNS is
compromised there's not much one can do.

Sure, companies with known high value business partners can configure
static policy enforcing TLS for those destinations, and the current
Postfix TLS policy engine is in large part in support of that model.

The DANE support in Postfix aims to get beyond that scale, to the
Internet at large. =C2=A0Predicated on the assumption that DNSSEC is
not a dead-end, and will over the next few years see broad adoption,
as management tools and client to registry/registrar interfaces
mature.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.
_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane



--
= Regards

Andy
--001a11333bceb2dad304e5ad6868-- From cloos@jhcloos.com Fri Sep 6 06:22:30 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968A411E8145 for ; Fri, 6 Sep 2013 06:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.211 X-Spam-Level: X-Spam-Status: No, score=-1.211 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCeAQcvmHuXF for ; Fri, 6 Sep 2013 06:22:26 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) by ietfa.amsl.com (Postfix) with ESMTP id 30CBD11E8196 for ; Fri, 6 Sep 2013 06:22:26 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id C7D5E1DFC3; Fri, 6 Sep 2013 13:21:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1378473706; bh=/6JpV19a0ne4ZytMGvagfCBUPLOJreeWhgwt157/IpI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=WoDlhfPu9VuLKjbaejBIMPhBtiPYF9C7raOlGBh/XgWeSA+Z3nBQPQ0VAd4Ea4RS4 XUSJYTB4qacVBTLpkQ4DhgpzTbOnM7uLXqXusPo3QSi87EYpfkd1Gl2oBgR2w8lmBc /+SKuT5lYTbG9TSmzOYeEuVKVtWQ7g3cmPdTuKiAGzw== Received: by carbon.jhcloos.org (Postfix, from userid 500) id ABAE26001D; Fri, 6 Sep 2013 13:17:20 +0000 (UTC) From: James Cloos To: =?utf-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= In-Reply-To: ("Ian Fette =?utf-8?B?KOOCpOOCouODs+ODleOCp+ODg+ODhuOCoykiJ3M=?= message of "Thu, 5 Sep 2013 14:57:24 -0700") References: <20130904144549.GA29796@mournblade.imrryr.org> <20130905010924.GM29796@mournblade.imrryr.org> <20130905212933.GI61351@mx1.yitter.info> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 06 Sep 2013 09:17:20 -0400 Message-ID: Lines: 34 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Hashcash: 1:28:130906:ajs@anvilwalrusden.com::fKDLrPWAlW/gF259:00000000000000000000000000000000000000uGwIR X-Hashcash: 1:28:130906:dane@ietf.org::v84o9Xdiw53+n+6t:0004GFo1 Cc: dane@ietf.org Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 13:22:30 -0000 >>>>> "IF" == Ian Fette (イアンフェッティ) writes: IF> Let's say that you want to know a-priori if an email will be sent over TLS. IF> (2) gives you a signal that you could potentially pass on to a user, IF> and then the user can potentially make a decision about whether or IF> not they want to send the email. The idea of using the existence of an unsecured tlsa rr as a hint that tls must be used was, IIRC, discussed in the early days of this wg. There wasn't consensus to include that -- or anything dealing with unsecured rr sets -- in the rfc due (again, IIRC) to the ease with which a mitm also can mitm the dns. Doing MX+TLSA queries as soon as the destination(s) are known so as to indicate the possibility of TLS (Trusted, Untrusted or Verified) can be a good idea. There is a risk of leaking information when the client is not the same system which will do the outgoing smtp, though, so the lookups may need securely to be proxied, depending on how the mail is to be submitted. But it tlsa existance is to be the key, it does seem best to demand that it be secured. But please do publish the tlsa sooner rather than later. Even though they likely will not get used in practice until the zones are signed, tests can still be done to ensure accuracy, and there won't have to be any delays post-signing. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From ogud@ogud.com Fri Sep 6 07:42:19 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2535221F87BB for ; Fri, 6 Sep 2013 07:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3c6AWriIb8z for ; Fri, 6 Sep 2013 07:42:13 -0700 (PDT) Received: from smtp116.ord1c.emailsrvr.com (smtp116.ord1c.emailsrvr.com [108.166.43.116]) by ietfa.amsl.com (Postfix) with ESMTP id F366A21F873C for ; Fri, 6 Sep 2013 07:42:12 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp7.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 5697D1B9BE5; Fri, 6 Sep 2013 10:42:10 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp7.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id B620C1B9C7A; Fri, 6 Sep 2013 10:42:09 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Olafur Gudmundsson In-Reply-To: <20130810021008.GA22978@odin.ulthar.us> Date: Fri, 6 Sep 2013 10:42:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130809141725.3702.71639.idtracker@ietfa.amsl.com> <20130810021008.GA22978@odin.ulthar.us> To: Scott Schmit X-Mailer: Apple Mail (2.1508) Cc: dane@ietf.org Subject: Re: [dane] New Version Notification for draft-dane-registry-acronym-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 14:42:19 -0000 Sorry for the delay in responding.=20 On Aug 9, 2013, at 10:10 PM, Scott Schmit wrote: > On Fri, Aug 09, 2013 at 10:19:25AM -0400, Olafur Gudmundsson wrote: >>> Abstract: >>> Experience has show that people get confused using the three = numeric >>> fields the TLSA record. This document specifies descriptive = acronyms >>> for the three numeric fields in the TLSA records. >=20 > I do find myself a little puzzled that we feel this is necessary -- > nobody is calling for this for DNSKEY, RRSIG, or DS records? >=20 > Anyway, we aren't generating acronyms for the numbers -- we're > identifying enumeration values. >=20 > In Table 2, "Hash" should be "SPKI", "Full" should probably be "Cert". > In Table 3, "NoHash" should be "Full". These are excellent suggestions and I have applied in the upcoming = (hopefully final) version.=20 >=20 > I'm not convinced that Priv* will see enough use to be worth making an > enumeration value for them. If you're going to have them, "PrivHash" > needs to be "PrivMatch". agree >=20 > Otherwise you'll end up with weird things like: > * PKIX-CA Hash NoHash > * DANE-EE Full SHA2-256 > * DANE-TA Full NoHash >=20 > instead of: > * PKIX-CA SPKI Full > * DANE-EE Cert SHA2-256 > * DANE-TA Cert Full >=20 > Other questions not addressed in the draft: > * Case sensitive or not? Not=20 > * Probably should show some examples of use? Will do > * Can I mix enumerations with the numbers? Why not > * What if the enumerations are used out of order? Same as when numbers are out of order except with textual use this might = be easer to detect.=20 thanks a lot for the good suggestions.=20 >=20 > --=20 > Scott Schmit > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From ogud@ogud.com Fri Sep 6 07:56:26 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6967111E82C5 for ; Fri, 6 Sep 2013 07:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5B7MQtxYV1Z for ; Fri, 6 Sep 2013 07:56:21 -0700 (PDT) Received: from smtp76.ord1c.emailsrvr.com (smtp76.ord1c.emailsrvr.com [108.166.43.76]) by ietfa.amsl.com (Postfix) with ESMTP id C94CE11E8196 for ; Fri, 6 Sep 2013 07:56:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 507A31E8104 for ; Fri, 6 Sep 2013 10:56:20 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp2.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 963611E813A for ; Fri, 6 Sep 2013 10:56:13 -0400 (EDT) From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_F0FD4F2B-D7DF-4326-B221-B94A193A7C04" Date: Fri, 6 Sep 2013 10:56:08 -0400 References: <20130906145353.32165.91900.idtracker@ietfa.amsl.com> To: "dane@ietf.org list" Message-Id: <4AE68D21-BBD0-47AB-A566-F4E0EBD379D5@ogud.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [dane] Request for WGLC X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 14:56:26 -0000 --Apple-Mail=_F0FD4F2B-D7DF-4326-B221-B94A193A7C04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Chairs,=20 I updated the acronym document based on WG feedback.=20 Can you please start a WGLC as from my viewpoint the document is = complete. Olafur Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-dane-registry-acronym-01.txt > Date: September 6, 2013 10:53:53 AM EDT > To: Olafur Gudmundsson >=20 >=20 > A new version of I-D, draft-dane-registry-acronym-01.txt > has been successfully submitted by Olafur Gudmundsson and posted to = the > IETF repository. >=20 > Filename: draft-dane-registry-acronym > Revision: 01 > Title: Adding acronyms to simplify DANE conversations > Creation date: 2013-09-06 > Group: Individual Submission > Number of pages: 5 > URL: = http://www.ietf.org/internet-drafts/draft-dane-registry-acronym-01.txt > Status: = http://datatracker.ietf.org/doc/draft-dane-registry-acronym > Htmlized: = http://tools.ietf.org/html/draft-dane-registry-acronym-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-dane-registry-acronym-01 >=20 > Abstract: > Experience has show that people get confused using the three numeric > fields the TLSA record. This document specifies descriptive = acronyms > for the three numeric fields in the TLSA records. --Apple-Mail=_F0FD4F2B-D7DF-4326-B221-B94A193A7C04 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii = Olafur

Begin forwarded = message:

Subject: New Version Notification for = draft-dane-registry-acronym-01.txt
Date: September 6, 2013 = 10:53:53 AM EDT
To: Olafur Gudmundsson <ogud@ogud.com>


A new version of I-D, draft-dane-registry-acronym-01.txt
has = been successfully submitted by Olafur Gudmundsson and posted to = the
IETF repository.

Filename: = draft-dane-registry-acronym
Revision: 01
Title: Adding = acronyms to simplify DANE conversations
Creation date: = 2013-09-06
Group: Individual Submission
Number = of pages: 5
URL: =             http://www.ietf.org/internet-drafts/draft-dane-registry-acronym-01.t= xt
Status: =          http:= //datatracker.ietf.org/doc/draft-dane-registry-acronym
Htmlized: =        http://= tools.ietf.org/html/draft-dane-registry-acronym-01
Diff: =            http://www.ietf.org/rfcdiff?url2=3Ddraft-dane-registry-acronym-01
=
Abstract:
  Experience has show that people get = confused using the three numeric
  fields the TLSA record. =  This document specifies descriptive acronyms
  for = the three numeric fields in the TLSA = records.

= --Apple-Mail=_F0FD4F2B-D7DF-4326-B221-B94A193A7C04-- From viktor1dane@dukhovni.org Fri Sep 6 08:12:00 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D1C11E8198 for ; Fri, 6 Sep 2013 08:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKvzz6lNvGyg for ; Fri, 6 Sep 2013 08:11:55 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 0927911E818B for ; Fri, 6 Sep 2013 08:11:55 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 45FF82AB082; Fri, 6 Sep 2013 15:11:54 +0000 (UTC) Date: Fri, 6 Sep 2013 15:11:54 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130906151154.GX29796@mournblade.imrryr.org> References: <20130809141725.3702.71639.idtracker@ietfa.amsl.com> <20130810021008.GA22978@odin.ulthar.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] New Version Notification for draft-dane-registry-acronym-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 15:12:00 -0000 On Fri, Sep 06, 2013 at 10:42:10AM -0400, Olafur Gudmundsson wrote: > Sorry for the delay in responding. > > These are excellent suggestions and I have applied in the upcoming (hopefully final) version. One more correction, in the text: Sides example: "In the case of FOO for practical cases you can treat PKIX-CA == DANE-TE" (see talk at IETF-87 on DANE for email) replace DANE-TE with DANE-TA. Also I have no idea wha "Sides example" means. Also since in SMTP the mapping from usage 0 to usage 2 will be incomplete, a better example would be "PKIX-EE == DANE-EE". The final DANE for SMTP spec will likely say that PKIX usages are simply unsupported, and SHOULD NOT published, so perhaps it is best to not use this example at all. FWIW, while when speaking of an individual TLSA RR elements, I find acronyms helpful, when reading a complete TLSA RRset, I find mail.example.com. IN TLSA 3 1 1 ... much easier to quickly parse at a glance than mail.example.com. IN TLSA DANE-EE SPKI SHA2-256 ... which requires a lot more cognitive effort. -- Viktor. From viktor1dane@dukhovni.org Fri Sep 6 08:50:27 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567E611E81A5 for ; Fri, 6 Sep 2013 08:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+IVuegSnDhx for ; Fri, 6 Sep 2013 08:50:22 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 8325811E8122 for ; Fri, 6 Sep 2013 08:50:21 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 68E2B2AA9FC; Fri, 6 Sep 2013 15:50:16 +0000 (UTC) Date: Fri, 6 Sep 2013 15:50:16 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130906155016.GY29796@mournblade.imrryr.org> References: <20130904144549.GA29796@mournblade.imrryr.org> <20130905010924.GM29796@mournblade.imrryr.org> <20130905212933.GI61351@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 15:50:27 -0000 On Fri, Sep 06, 2013 at 09:17:20AM -0400, James Cloos wrote: > The idea of using the existence of an unsecured tlsa rr as a hint that > tls must be used was, IIRC, discussed in the early days of this wg. This is largely impractical for SMTP. SMTP TLSA RRs are of course tied to MX hosts (transport destinations), not email domains. An MITM can bypass any such cached RRs by sending malicious MX replies. The TTLs on MX records are often relatively short (gmail.com is 1H) so attacks don't require the attacker to wait long and for smaller destination domains which don't receive a steady stream of traffic from all senders, or when intercepting a low-volume sender, the target MX RRset is often already expired from the cache due to infrequent mail transmission. Also any insecure data with a remotely specified TTL is a golden opportunity for cache poisoning attacks. Just set a very long TTL with a bogus certificate association and the MITM attacker is set for a long time. In the mean time log entries show happily authenticated connections, nobody is any the wiser unless they are logging the underlying digests and looking for malicious changes. I understand that it would be convenient if security could be obtained more easily. Sadly, there is a lower bound on the cost. > Doing MX+TLSA queries as soon as the destination(s) are known so as to > indicate the possibility of TLS (Trusted, Untrusted or Verified) can be > a good idea. What should an MTA do differently when insecure TLSA records are found for one or more MX hosts, and why? > But it tlsa existance is to be the key, it does seem best to demand that > it be secured. On this we agree. > But please do publish the tlsa sooner rather than later. Even though > they likely will not get used in practice until the zones are signed, > tests can still be done to ensure accuracy, and there won't have to be > any delays post-signing. A better test is to use non-production MX hosts in a signed zone. dane-test.gmail.com. IN MX 0 mx.dane-test.gmail.com. mx.date-test.gmail.com. IN A 192.0.2.1 mx.date-test.gmail.com. IN TLSA 2 1 1 {sha256 pubkey hash} then one can test verified connections to dane-test.gmail.com before publishing TLSA RRs for the production zone. -- Viktor. From ifette@google.com Fri Sep 6 09:12:10 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B929A21E81C8 for ; Fri, 6 Sep 2013 09:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.317 X-Spam-Level: X-Spam-Status: No, score=-1.317 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbzyHuo0Thp7 for ; Fri, 6 Sep 2013 09:12:10 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8321521E8136 for ; Fri, 6 Sep 2013 09:12:09 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id e14so7272005iej.36 for ; Fri, 06 Sep 2013 09:12:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=G1YwrNaTIoCMvdELSTDxSqdo6F5ynzOkNiynL1j49SY=; b=LtcwY2h0jWicg3dSYeUV9ScWz0htwKJASlq+jZDIZNiyzLiTBbVbW4WOrvvqAwoHyv M6aUm/z1UFLxwViYsVNpHc7m20jujSM880veCrZmkkajaCzpVi/HvuyAeXvDV4sFWs97 sLPknGT2uwVzOiJburZEDygema4Dyk6IbQz9JbthTJP8u7ECNxwKAwuj6t/DjawS6IOC IyZxY+js6kA6A1IfuLhl8g67Elt0a7vwp687qhQ3KCBpEJd0RhGsr3e9T9xHNVEtLQpZ AqHZ7HFGrMZUPZ8WhruEOeUcLVYg/YtTzBur12/sZfUt5og4fXwdKy2/4Gek1Tr9Hjrd HlzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=G1YwrNaTIoCMvdELSTDxSqdo6F5ynzOkNiynL1j49SY=; b=h1UhcHWqVHddMI/rYIf1qHcF5RS1wFn3qXDqFl/vKjGupmV0IA8XU2ou0KdqrR75cR aInEyc8HY2WqDZOtzu2HD7Cb6IuiW4MweFHxJgZDVVe7BAtood1BjVTIKuuTaLvZ1wcr yJFFbC52h2CQ1UdNPhyaQPKddDA/VcsA7AQxnGFi9Loa3ZhXMy1E4YeV7x+eZi6bnVzI YvU/HDzXCYgUlx8O2H+xQdPzY1atDMTcycaxdo8Qm2JKmwbJmghSyBoIUTq4DRT8NwP9 PFf/yt+S0V6+2xCdCMRL9iNLRq3xvhOJbs8wk6+ezAAInlHuTKo0y9oueKrgO0+Wxpym 237w== X-Gm-Message-State: ALoCoQloOvj5lWfLwTnIy0QGpUPIrCL242Ma04jdAtwiciS68r35FK5e1sZtljWDyKwJCkNik575mAhyvpQXlWTxHve7O2/OUW9vqLU6tOKaHg0N6/CaMqcirfWE2FIqd0k3xI5B6Ykg2IJ87fmdmltC6UYmRHrR5bh1AOH7uvg5nOLfl8JIW9qsVbaKpTRnGRCYNduayZYD MIME-Version: 1.0 X-Received: by 10.42.119.141 with SMTP id b13mr2051841icr.0.1378483928923; Fri, 06 Sep 2013 09:12:08 -0700 (PDT) Received: by 10.231.161.70 with HTTP; Fri, 6 Sep 2013 09:12:08 -0700 (PDT) Received: by 10.231.161.70 with HTTP; Fri, 6 Sep 2013 09:12:08 -0700 (PDT) In-Reply-To: <20130906155016.GY29796@mournblade.imrryr.org> References: <20130904144549.GA29796@mournblade.imrryr.org> <20130905010924.GM29796@mournblade.imrryr.org> <20130905212933.GI61351@mx1.yitter.info> <20130906155016.GY29796@mournblade.imrryr.org> Date: Fri, 6 Sep 2013 09:12:08 -0700 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: dane@ietf.org Content-Type: multipart/alternative; boundary=90e6ba61492ae9cb7704e5b94c58 Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ifette@google.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 16:12:10 -0000 --90e6ba61492ae9cb7704e5b94c58 Content-Type: text/plain; charset=UTF-8 That would assume deploying dnssec on Gmail.com is somehow easier than on Google.com :-) On Sep 6, 2013 8:50 AM, "Viktor Dukhovni" wrote: > On Fri, Sep 06, 2013 at 09:17:20AM -0400, James Cloos wrote: > > > The idea of using the existence of an unsecured tlsa rr as a hint that > > tls must be used was, IIRC, discussed in the early days of this wg. > > This is largely impractical for SMTP. SMTP TLSA RRs are of course > tied to MX hosts (transport destinations), not email domains. An > MITM can bypass any such cached RRs by sending malicious MX replies. > > The TTLs on MX records are often relatively short (gmail.com is 1H) > so attacks don't require the attacker to wait long and for smaller > destination domains which don't receive a steady stream of traffic > from all senders, or when intercepting a low-volume sender, the > target MX RRset is often already expired from the cache due to > infrequent mail transmission. > > Also any insecure data with a remotely specified TTL is a golden > opportunity for cache poisoning attacks. Just set a very long TTL > with a bogus certificate association and the MITM attacker is set > for a long time. In the mean time log entries show happily > authenticated connections, nobody is any the wiser unless they are > logging the underlying digests and looking for malicious changes. > > I understand that it would be convenient if security could be > obtained more easily. Sadly, there is a lower bound on the cost. > > > Doing MX+TLSA queries as soon as the destination(s) are known so as to > > indicate the possibility of TLS (Trusted, Untrusted or Verified) can be > > a good idea. > > What should an MTA do differently when insecure TLSA records are > found for one or more MX hosts, and why? > > > But it tlsa existance is to be the key, it does seem best to demand that > > it be secured. > > On this we agree. > > > But please do publish the tlsa sooner rather than later. Even though > > they likely will not get used in practice until the zones are signed, > > tests can still be done to ensure accuracy, and there won't have to be > > any delays post-signing. > > A better test is to use non-production MX hosts in a signed zone. > > dane-test.gmail.com. IN MX 0 mx.dane-test.gmail.com. > mx.date-test.gmail.com. IN A 192.0.2.1 > mx.date-test.gmail.com. IN TLSA 2 1 1 {sha256 pubkey hash} > > then one can test verified connections to dane-test.gmail.com before > publishing TLSA RRs for the production zone. > > -- > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > --90e6ba61492ae9cb7704e5b94c58 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

That would assume deploying dnssec on Gmail.com is somehow e= asier than on Google.com :-)

On Sep 6, 2013 8:50 AM, "Viktor Dukhovni&qu= ot; <viktor1dane@dukhovni.or= g> wrote:
On Fri, Sep 06, 2013 at 09:17:20AM -0400, James Cloos wrote:

> The idea of using the existence of an unsecured tlsa rr as a hint that=
> tls must be used was, IIRC, discussed in the early days of this wg.
This is largely impractical for SMTP. =C2=A0SMTP TLSA RRs are of course
tied to MX hosts (transport destinations), not email domains. =C2=A0An
MITM can bypass any such cached RRs by sending malicious MX replies.

The TTLs on MX records are often relatively short (gmail.com is 1H)
so attacks don't require the attacker to wait long and for smaller
destination domains which don't receive a steady stream of traffic
from all senders, or when intercepting a low-volume sender, the
target MX RRset is often already expired from the cache due to
infrequent mail transmission.

Also any insecure data with a remotely specified TTL is a golden
opportunity for cache poisoning attacks. =C2=A0Just set a very long TTL
with a bogus certificate association and the MITM attacker is set
for a long time. =C2=A0In the mean time log entries show happily
authenticated connections, nobody is any the wiser unless they are
logging the underlying digests and looking for malicious changes.

I understand that it would be convenient if security could be
obtained more easily. =C2=A0Sadly, there is a lower bound on the cost.

> Doing MX+TLSA queries as soon as the destination(s) are known so as to=
> indicate the possibility of TLS (Trusted, Untrusted or Verified) can b= e
> a good idea.

What should an MTA do differently when insecure TLSA records are
found for one or more MX hosts, and why?

> But it tlsa existance is to be the key, it does seem best to demand th= at
> it be secured.

On this we agree.

> But please do publish the tlsa sooner rather than later. =C2=A0Even th= ough
> they likely will not get used in practice until the zones are signed,<= br> > tests can still be done to ensure accuracy, and there won't have t= o be
> any delays post-signing.

A better test is to use non-production MX hosts in a signed zone.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 dane-test.gmail.com. IN MX 0 mx.dane-test.gmail.com.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mx.date-test.gmail.com. IN A 192.0.2.1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mx.date-test.gmail.com. IN TLSA 2 1 1 {sha256 pubkey hash}=

then one can test verified connections to dane-test.gmail.com before
publishing TLSA RRs for the production zone.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.
_______________________________________________
dane mailing list
dane@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dane
--90e6ba61492ae9cb7704e5b94c58-- From viktor1dane@dukhovni.org Fri Sep 6 10:39:30 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E75311E80F7 for ; Fri, 6 Sep 2013 10:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34tu5AUZAHnA for ; Fri, 6 Sep 2013 10:39:25 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 518C011E80DE for ; Fri, 6 Sep 2013 10:39:25 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BC33F2AA9FC; Fri, 6 Sep 2013 17:39:19 +0000 (UTC) Date: Fri, 6 Sep 2013 17:39:19 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130906173919.GZ29796@mournblade.imrryr.org> References: <20130904144549.GA29796@mournblade.imrryr.org> <20130905010924.GM29796@mournblade.imrryr.org> <20130905212933.GI61351@mx1.yitter.info> <20130906155016.GY29796@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 17:39:30 -0000 On Fri, Sep 06, 2013 at 09:12:08AM -0700, Ian Fette (????????) wrote: > That would assume deploying dnssec on Gmail.com is somehow easier than on > Google.com :-) Sorry if I was unclear. My example was about testing TLSA in a signed zone on non-production TLS endpoints before publishing for the first time on production endpoints. No intent to imply that any particular domain is an easier place to do DNSSEC. In the specific case of gmail.com, you'd need DNSSEC on both gmail.com and google.com: $ dig +short -t mx gmail.com | sort -n 5 gmail-smtp-in.l.google.com. 10 alt1.gmail-smtp-in.l.google.com. 20 alt2.gmail-smtp-in.l.google.com. 30 alt3.gmail-smtp-in.l.google.com. 40 alt4.gmail-smtp-in.l.google.com. since not only the gmail.com MX RRset needs to be secure, but also the zone containing the actual MX hosts, since these are the TLSA base domains. I am guessing that one the major obstacles to DNSSEC for Google is all the interaction with DNS geo load-balancing gear. I don't know whether there is gear of that ilk that supports DNSSEC, or whether beyond the hardware there are architectural obstacles to DNSSEC in combination with highly dynamic DNS responses. It may take some time for Google to publish TLSA RRs in a signed zone, but it is I hope worth the effort to figure out what the obstacles are and what it would take to address them. In the mean time Google can easily add client-side DANE TLSA support, this just requires a DNSSEC aware resolver. -- Viktor. From viktor1dane@dukhovni.org Fri Sep 6 11:36:49 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B040D11E81AB for ; Fri, 6 Sep 2013 11:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bD7ZKLlF4q1e for ; Fri, 6 Sep 2013 11:36:44 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 71AFD11E81A9 for ; Fri, 6 Sep 2013 11:36:44 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CA1CC2AB081; Fri, 6 Sep 2013 18:36:41 +0000 (UTC) Date: Fri, 6 Sep 2013 18:36:41 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130906183641.GA29796@mournblade.imrryr.org> References: <20130904144549.GA29796@mournblade.imrryr.org> <20130905010924.GM29796@mournblade.imrryr.org> <20130905212933.GI61351@mx1.yitter.info> <20130906155016.GY29796@mournblade.imrryr.org> <20130906173919.GZ29796@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130906173919.GZ29796@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 18:36:49 -0000 On Fri, Sep 06, 2013 at 05:39:19PM +0000, Viktor Dukhovni wrote: > In the mean time Google can easily add client-side DANE TLSA support, > this just requires a DNSSEC aware resolver. Plus of course very carefully written DANE-aware peer-chain verification code in the SMTP client. Some implementations forget to properly check the validity of usage "2" chains (that each element is unexpired, signed by its parent, ...). -- Viktor. From stpeter@stpeter.im Fri Sep 6 15:31:46 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E89911E8178 for ; Fri, 6 Sep 2013 15:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIJJLAqdapoq for ; Fri, 6 Sep 2013 15:31:39 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B6E7311E8135 for ; Fri, 6 Sep 2013 15:31:39 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 297D8414D0; Fri, 6 Sep 2013 16:35:52 -0600 (MDT) Message-ID: <522A57C8.8040702@stpeter.im> Date: Fri, 06 Sep 2013 16:31:36 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "dane@ietf.org list" X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dane] draft-ietf-dane-srv X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 22:31:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It seems that draft-ietf-dane-srv has expired. Does the document editor (and, more important, the WG) still have an interest in moving this forward? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSKlfIAAoJEOoGpJErxa2pRp8P/1tDBZiV7q40WXEcpw9BIJ0B WGk5gUwcnh1i8YXxizoMothZ0JWu5vB8/3GliEyo2LyJvRpPDqKEMchkYkHPAmNV GSGaG500w7P/dGqQnp+AfRQbeyJD6g0r7B/Z9TKFO8qyka1jgR+ry/VjKStYBYN3 sjergCVBcymz1WdbP/JSwaTdmM95yynsf0n+Bbin5NcQzZN89iWN1kQvkuPgwIQo S7xnZHp17gYkCstwBZdM0AL/4Qj/iogFRIewI0KIS7iyM5MBPhlvRFfZF4pipQIo k8/rJ97qGp4M3k9iyoWX25iE8pMW8mS06gnGOqbSpkhnKJ3kr9YLQtO4UWrtv8EL 6ExkmAmIpPOyEuhZyEWKnzwh5PSCdxyU0bOmivi6OR15EfeSk0lZvAoRzm/9oTQl vnrhpc8fvg/7SaLrwZ2mpIhOP1f4fm4CMz2SdgG7d4i9RIKhq9j15AXzqR+yy6DW XINfQzLKPLHCGTCquQULczNq7ZhIHG4qqbB6u8mTgmZS3R6hl0pNPiNJSR8w7TY8 k3UpbT+M2vrIhTxH8WJe9gnrBwvRZu/dZU6NomxRMvn4x4OLCF69bQORg9CAYHb9 gfzFpeoUPlF/ZiTCupTh8z2S9B05/Yv063vuok/mH3KCEqFpRX6tFAmc3VjXJfxF FEfLlmJTyr9x2axHtshS =zbMy -----END PGP SIGNATURE----- From cloos@jhcloos.com Fri Sep 6 19:15:57 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B1421F9BF1 for ; Fri, 6 Sep 2013 19:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.715 X-Spam-Level: X-Spam-Status: No, score=-1.715 tagged_above=-999 required=5 tests=[AWL=0.884, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxw527Mvq5ww for ; Fri, 6 Sep 2013 19:15:53 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) by ietfa.amsl.com (Postfix) with ESMTP id AB22921F9C0D for ; Fri, 6 Sep 2013 19:15:52 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 9DB411DFCD; Sat, 7 Sep 2013 02:14:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1378520122; bh=+fj3omk5Xn5b+b3nHuCaEHF3SHB3HNn5JoKwyd1orZA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=RQTczK5ZcFFaqnRAF5ha7qC1EliK2NBUske0jEFxeSPyAIpm0BBBCSRuHSh23GcKq Gjh1oXpEvP+/CS+uIRsV3/KMuO8Hj35UgKx8fAa9TkoZIXlXzDH/lBy97iYYtYT+vF 1NHlnP37N4EypXeSOfNc2pg4zF9fph9UC9b7SUVQrFg== Received: by carbon.jhcloos.org (Postfix, from userid 500) id 62F0E6001D; Sat, 7 Sep 2013 02:12:38 +0000 (UTC) From: James Cloos To: Viktor Dukhovni In-Reply-To: <20130906155016.GY29796@mournblade.imrryr.org> (Viktor Dukhovni's message of "Fri, 6 Sep 2013 15:50:16 +0000") References: <20130904144549.GA29796@mournblade.imrryr.org> <20130905010924.GM29796@mournblade.imrryr.org> <20130905212933.GI61351@mx1.yitter.info> <20130906155016.GY29796@mournblade.imrryr.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 06 Sep 2013 22:12:38 -0400 Message-ID: Lines: 20 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:130907:viktor1dane@dukhovni.org::7YJdZB1vTutTDCYc:0000000000000000000000000000000000004C3Od X-Hashcash: 1:28:130907:dane@ietf.org::n3x0vWP3GcmRNu3t:000Vm0VM Cc: dane@ietf.org Subject: Re: [dane] DANE and STARTTLS - indication of availability of encryption X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 02:15:57 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> On Fri, Sep 06, 2013 at 09:17:20AM -0400, James Cloos wrote: >> The idea of using the existence of an unsecured tlsa rr as a hint that >> tls must be used was, IIRC, discussed in the early days of this wg. VD> This is largely impractical for SMTP. SMTP TLSA RRs are of course VD> tied to MX hosts (transport destinations), not email domains. An VD> MITM can bypass any such cached RRs by sending malicious MX replies. I was noting history above, not advocating. I also wrote the the wg consensus was against using unsecured TLSA (or other new RRs) for anything. I always preferred dnssec-for-everything-dane. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From paul@cypherpunks.ca Mon Sep 9 08:01:19 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0876F21F9F1B for ; Mon, 9 Sep 2013 08:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juQBtBOqixD9 for ; Mon, 9 Sep 2013 08:01:05 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id C5AFB11E81EC for ; Mon, 9 Sep 2013 07:52:36 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cYXQz0kcnz3mk; Mon, 9 Sep 2013 10:52:27 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id NQm41VupFA0d; Mon, 9 Sep 2013 10:52:26 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Mon, 9 Sep 2013 10:52:26 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 6E50E848E5; Mon, 9 Sep 2013 10:52:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 62964811F6; Mon, 9 Sep 2013 10:52:26 -0400 (EDT) Date: Mon, 9 Sep 2013 10:52:26 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: dane WG list Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Paul Hoffman Subject: [dane] case sensitivity and draft-ietf-dane-smime / draft-wouters-dane-openpgp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 15:01:19 -0000 It was brought to my attention by Matthias Wimmer that we overlooked an important issue with respect to the base32 generation of the base32 encoded left hand side of the email address. Mail servers and mail clients do not treat email addresses as case-insensitive. When encoding an LHS with base32, the case matters. Using the wrong case will cause you to not find the SMIMEA / OPENPGPKEY record. paul@bofh:$ python Python 2.7.3 (default, Aug 9 2012, 17:23:57) [GCC 4.7.1 20120720 (Red Hat 4.7.1-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import base64 >>> base64.b32encode("paul") 'OBQXK3A=' >>> base64.b32encode("Paul") 'KBQXK3A=' >>> We should probably add a section explaining this, and perhaps suggest to lowercase before base32'ing the LHS for the lookup. Paul From viktor1dane@dukhovni.org Mon Sep 9 08:33:04 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B9311E8246 for ; Mon, 9 Sep 2013 08:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uo2Xm1trFfS for ; Mon, 9 Sep 2013 08:32:52 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 8541121F893B for ; Mon, 9 Sep 2013 08:16:47 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C6FAC2AB076; Mon, 9 Sep 2013 15:16:46 +0000 (UTC) Date: Mon, 9 Sep 2013 15:16:46 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130909151646.GM29796@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] case sensitivity and draft-ietf-dane-smime / draft-wouters-dane-openpgp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 15:33:05 -0000 On Mon, Sep 09, 2013 at 10:52:26AM -0400, Paul Wouters wrote: > Mail servers and mail clients do not treat email addresses as > case-insensitive. When encoding an LHS with base32, the case matters. > Using the wrong case will cause you to not find the SMIMEA / OPENPGPKEY > record. This is not accurate. While domain part of an email address is case-insensitive, the case-sensitivity of the local-part is a local matter. SMTP relays MUST NOT change the case of the local part of envelope addresses. On arrival at the destination domain, that domain's mail system may choose to treat local-parts case insensitively, but remote systems must not rely on this. Therefore, and are a-priori distinct addresses except perhaps in the hands of the MTAs that handle example.com mail. [ The fact that most systems are in practice case-insensitive is not sufficient to invalidate the right of some to be case sensitive as they see fit. ] -- Viktor. From Francis.Dupont@fdupont.fr Mon Sep 9 08:35:29 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68EF11E80D5 for ; Mon, 9 Sep 2013 08:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKgruuU5JV3n for ; Mon, 9 Sep 2013 08:35:16 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5B621E808E for ; Mon, 9 Sep 2013 08:19:11 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id r89FIk3a038720; Mon, 9 Sep 2013 17:18:46 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201309091518.r89FIk3a038720@givry.fdupont.fr> From: Francis Dupont To: Paul Wouters In-reply-to: Your message of Mon, 09 Sep 2013 10:52:26 EDT. Date: Mon, 09 Sep 2013 17:18:46 +0200 Sender: Francis.Dupont@fdupont.fr Cc: Paul Hoffman , dane WG list Subject: Re: [dane] case sensitivity and draft-ietf-dane-smime / draft-wouters-dane-openpgp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 15:35:29 -0000 In your previous mail you wrote: > Mail servers and mail clients do not treat email addresses as > case-insensitive. => in fact the specs said they are case-sensitive (so Dupont and dupont are not the same) at the exception of postmaster (or Postmaster or PosTMAstEr or ...) so all implementations make them case-insensitive (or with other words implementers didn't read the specs: another proof is the space in left part of email addresses, allowed or not? :-). > We should probably add a section explaining this, => I assume that "should probably" is a style effect... Regards Francis.Dupont@fdupont.fr From jakob@kirei.se Mon Sep 9 08:42:45 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D531721E808F for ; Mon, 9 Sep 2013 08:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbYX4efOzcUg for ; Mon, 9 Sep 2013 08:42:33 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6B211E8212 for ; Mon, 9 Sep 2013 08:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=zF6/+LFB/ywruA0EMROvPyDj4MWjgeHClKJzpAd1APQ=; b=wKrlTYC+Mb8187mkjlUn2qB5YXmFyacQhnFmFqeMuVz/O3ucgDgbjiQfXEUincT6YHTOQgTGEq6xh gwxDqUX0CSWxrD7O96aEl7QbmRA7s16p5Xxs6fZowGb2S7deZNutfy0m+AI/KRwUCtSyY55vbSCe0T FhfjOyTTZnRmXp08= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Mon, 9 Sep 2013 17:27:00 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jakob Schlyter In-Reply-To: Date: Mon, 9 Sep 2013 17:26:48 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: Paul Wouters X-Mailer: Apple Mail (2.1508) Cc: Paul Hoffman , dane WG list Subject: Re: [dane] case sensitivity and draft-ietf-dane-smime / draft-wouters-dane-openpgp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 15:42:46 -0000 On 9 sep 2013, at 16:52, Paul Wouters wrote: > We should probably add a section explaining this, and perhaps suggest to > lowercase before base32'ing the LHS for the lookup. Yes, this would be the reasonable thing to do. jakob From paul@cypherpunks.ca Mon Sep 9 09:16:40 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD4E021F9FAB for ; Mon, 9 Sep 2013 09:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kE5AB1Kh4Rv for ; Mon, 9 Sep 2013 09:16:35 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id CE96B21F999D for ; Mon, 9 Sep 2013 08:50:01 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cYYjM470Bz3nL for ; Mon, 9 Sep 2013 11:49:59 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 64DG3eLc50wD for ; Mon, 9 Sep 2013 11:49:58 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP for ; Mon, 9 Sep 2013 11:49:58 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id B127E848E5; Mon, 9 Sep 2013 11:49:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A57EC811F6 for ; Mon, 9 Sep 2013 11:49:57 -0400 (EDT) Date: Mon, 9 Sep 2013 11:49:57 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: dane WG list In-Reply-To: <20130909151646.GM29796@mournblade.imrryr.org> Message-ID: References: <20130909151646.GM29796@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [dane] case sensitivity and draft-ietf-dane-smime / draft-wouters-dane-openpgp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 16:16:40 -0000 On Mon, 9 Sep 2013, Viktor Dukhovni wrote: > On Mon, Sep 09, 2013 at 10:52:26AM -0400, Paul Wouters wrote: > >> Mail servers and mail clients do not treat email addresses as >> case-insensitive. When encoding an LHS with base32, the case matters. >> Using the wrong case will cause you to not find the SMIMEA / OPENPGPKEY >> record. > > This is not accurate. While domain part of an email address is > case-insensitive, the case-sensitivity of the local-part is a > local matter. SMTP relays MUST NOT change the case of the local > part of envelope addresses. On arrival at the destination domain, > that domain's mail system may choose to treat local-parts case > insensitively, but remote systems must not rely on this. > > Therefore, and are a-priori > distinct addresses except perhaps in the hands of the MTAs that > handle example.com mail. > > [ The fact that most systems are in practice case-insensitive is not > sufficient to invalidate the right of some to be case sensitive as > they see fit. ] The _last_ thing I want to do is having an email client not encrypt a message because someone mailed Paul@example.com instead of paul@example.com. So I think our choices are: 1) do a lookup for the case "as is" and a lookup for lowercased (serial or parallel) 2) lowercase and lookup once. What I do _not_ think is a valid choice is "only do the as is case lookup". Paul From stpeter@stpeter.im Mon Sep 9 09:22:43 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F86121E8202 for ; Mon, 9 Sep 2013 09:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KWkFrjHwSBX for ; Mon, 9 Sep 2013 09:22:39 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B897221E820C for ; Mon, 9 Sep 2013 09:05:36 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 465AA414CF; Mon, 9 Sep 2013 10:09:50 -0600 (MDT) Message-ID: <522DF1C5.20801@stpeter.im> Date: Mon, 09 Sep 2013 10:05:25 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jakob Schlyter References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , dane WG list Subject: Re: [dane] case sensitivity and draft-ietf-dane-smime / draft-wouters-dane-openpgp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 16:22:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/9/13 9:26 AM, Jakob Schlyter wrote: > On 9 sep 2013, at 16:52, Paul Wouters wrote: > >> We should probably add a section explaining this, and perhaps >> suggest to lowercase before base32'ing the LHS for the lookup. > > Yes, this would be the reasonable thing to do. And let's not forget that "lowercase" can mean something less intuitive outside the ASCII range... http://datatracker.ietf.org/doc/rfc6530/ Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSLfHEAAoJEOoGpJErxa2psIoP/0oZRDnFLlpoQgxBWv2QdsPc y31HLD9Iu3rStrNieZLuHTejQKYih70YpgDawYsKhe9gq7/d088yiiKunMNzBuwv NaqEV8xu1hBLhQ2MXek0bbQiWXs6KveAqFMcWA94IYBTaC27SxWOX07xzN5w2a+k WXtkDZIJPGkHZsBDn2KNHe17fLO8SPH7lZgwYC8ldHdSOiuk8gcuwvHBXZCwvx/0 VcW+dFQucDGa5oN3XdxEHSnEQlLVI88/VB9TfpeDnYsqbYqYdQAOdDRiHbeIedq2 QJvIQVVML+vGoo2vTgqUrDlKoGIPAlP2tnEMooF9jpsEcAXHQuhje+HB2trStRGy nsiU7yzb52MY1P8EvEyG1ObqefGaH9LrKAsMSm2y3JvdtYO4eIjPbNii1XL+aAFX Hn7gvnP3GpA+U5IYt/6P8D6ek1qoaFOwrMlU4bSP45zoUnKDy+2+uZ7wO/rsoUhn ELTPZTYC+ZzyLfAup8ygzqphu7CD9SFEPwNcjvZZf5RGA1FN9Ofme0xhYSoj5CD6 7G7TraEjgvykDR8SnYEzQoU5DvlIc1OwCuo8t0YJsbynxB9uFGW1SJ4fIJtWTeUv 7t4HVxKvA6dJs1DUGv/3buYSszCW2dEwptHX3Qs8i7V0H1agKJ/INyR9mJqSCgiW d5ba2a484URW1guwNk78 =rRZN -----END PGP SIGNATURE----- From oej@edvina.net Mon Sep 9 11:43:17 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECDC11E812C for ; Mon, 9 Sep 2013 11:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NM8moVJszNlO for ; Mon, 9 Sep 2013 11:43:16 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 6748011E80E6 for ; Mon, 9 Sep 2013 11:43:15 -0700 (PDT) Received: from [192.168.40.56] (h87-96-134-126.dynamic.se.alltele.net [87.96.134.126]) by smtp7.webway.se (Postfix) with ESMTPA id 629BA93C2A1; Mon, 9 Sep 2013 18:43:13 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Olle E. Johansson" In-Reply-To: <20130909151646.GM29796@mournblade.imrryr.org> Date: Mon, 9 Sep 2013 20:43:11 +0200 Content-Transfer-Encoding: 7bit Message-Id: <61F83EE1-808D-467E-A6D4-8360A6B9460E@edvina.net> References: <20130909151646.GM29796@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1508) Subject: Re: [dane] case sensitivity and draft-ietf-dane-smime / draft-wouters-dane-openpgp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 18:43:17 -0000 9 sep 2013 kl. 17:16 skrev Viktor Dukhovni : > On Mon, Sep 09, 2013 at 10:52:26AM -0400, Paul Wouters wrote: > >> Mail servers and mail clients do not treat email addresses as >> case-insensitive. When encoding an LHS with base32, the case matters. >> Using the wrong case will cause you to not find the SMIMEA / OPENPGPKEY >> record. > > This is not accurate. While domain part of an email address is > case-insensitive, the case-sensitivity of the local-part is a > local matter. SMTP relays MUST NOT change the case of the local > part of envelope addresses. On arrival at the destination domain, > that domain's mail system may choose to treat local-parts case > insensitively, but remote systems must not rely on this. > > Therefore, and are a-priori > distinct addresses except perhaps in the hands of the MTAs that > handle example.com mail. > > [ The fact that most systems are in practice case-insensitive is not > sufficient to invalidate the right of some to be case sensitive as > they see fit. ] Just for the record - in SIP the username part is case-sensitive. /O From paul.hoffman@vpnc.org Tue Sep 10 10:50:39 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BAB21F90A7 for ; Tue, 10 Sep 2013 10:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXm0cC8pzjo5 for ; Tue, 10 Sep 2013 10:50:36 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AD28E21F90AC for ; Tue, 10 Sep 2013 10:50:36 -0700 (PDT) Received: from [10.88.40.112] ([70.42.157.27]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8AHoM7j009713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Sep 2013 10:50:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host [70.42.157.27] claimed to be [10.88.40.112] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Tue, 10 Sep 2013 13:50:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8A7BC0FC-62F8-4883-8FDD-948AAF9DAB78@vpnc.org> References: To: Paul Wouters X-Mailer: Apple Mail (2.1508) Cc: dane WG list Subject: Re: [dane] case sensitivity and draft-ietf-dane-smime / draft-wouters-dane-openpgp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 17:50:39 -0000 On Sep 9, 2013, at 10:52 AM, Paul Wouters wrote: > It was brought to my attention by Matthias Wimmer that we overlooked > an important issue with respect to the base32 generation of the base32 > encoded left hand side of the email address. "We" did not overlook that: as author, I made that decision completely = purposefully. > Mail servers and mail clients do not treat email addresses as > case-insensitive. That is sometimes-true statement. > When encoding an LHS with base32, the case matters. Yes, exactly. And so does internationalization. > Using the wrong case will cause you to not find the SMIMEA / = OPENPGPKEY > record. Yep. And will cause you to sometimes send mail to the wrong recipient. > We should probably add a section explaining this, and perhaps suggest = to > lowercase before base32'ing the LHS for the lookup. Yes; no. --Paul Hoffman= From paul@cypherpunks.ca Tue Sep 10 13:09:17 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16AD21E80AE for ; Tue, 10 Sep 2013 13:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aVh5gOlA11R for ; Tue, 10 Sep 2013 13:09:11 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id BFC7021E80B8 for ; Tue, 10 Sep 2013 13:09:10 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cZHPv5HN7z51L; Tue, 10 Sep 2013 16:09:07 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id nW7gwxBQH1b8; Tue, 10 Sep 2013 16:09:06 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Tue, 10 Sep 2013 16:09:05 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id ADE8E848E5; Tue, 10 Sep 2013 16:09:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A4F5E811F6; Tue, 10 Sep 2013 16:09:06 -0400 (EDT) Date: Tue, 10 Sep 2013 16:09:06 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Paul Hoffman In-Reply-To: <8A7BC0FC-62F8-4883-8FDD-948AAF9DAB78@vpnc.org> Message-ID: References: <8A7BC0FC-62F8-4883-8FDD-948AAF9DAB78@vpnc.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dane WG list Subject: Re: [dane] case sensitivity and draft-ietf-dane-smime / draft-wouters-dane-openpgp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 20:09:17 -0000 On Tue, 10 Sep 2013, Paul Hoffman wrote: > On Sep 9, 2013, at 10:52 AM, Paul Wouters wrote: > >> It was brought to my attention by Matthias Wimmer that we overlooked >> an important issue with respect to the base32 generation of the base32 >> encoded left hand side of the email address. > > "We" did not overlook that: as author, I made that decision completely purposefully. Perhaps documentation of that decision belonged in the Security Section of that document? :) >> Mail servers and mail clients do not treat email addresses as >> case-insensitive. > > That is sometimes-true statement. > >> When encoding an LHS with base32, the case matters. > > Yes, exactly. And so does internationalization. > >> Using the wrong case will cause you to not find the SMIMEA / OPENPGPKEY >> record. > > Yep. And will cause you to sometimes send mail to the wrong recipient. I'm really not okay with a protocol where I encrypt to the wrong key based on the case of the email address. >> We should probably add a section explaining this, and perhaps suggest to >> lowercase before base32'ing the LHS for the lookup. > > Yes; no. [citation needed] Paul From bdickson@verisign.com Tue Sep 10 14:14:03 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F27521F9D33 for ; Tue, 10 Sep 2013 14:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1f6+Esda+lh for ; Tue, 10 Sep 2013 14:13:58 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id 659C521F9D2E for ; Tue, 10 Sep 2013 14:13:50 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKUi+LianbHMaSk5BzoUM1PSjhwgdGVNIZ@postini.com; Tue, 10 Sep 2013 14:13:55 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r8ALDeST009084 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Sep 2013 17:13:40 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 10 Sep 2013 17:13:39 -0400 From: "Dickson, Brian" To: Paul Wouters , dane WG list Thread-Topic: [dane] case sensitivity and draft-ietf-dane-smime / draft-wouters-dane-openpgp Thread-Index: AQHOrW1wzENLlclRTEGSy2w5EcElEpm/emEA Date: Tue, 10 Sep 2013 21:13:39 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Paul Hoffman Subject: Re: [dane] case sensitivity and draft-ietf-dane-smime / draft-wouters-dane-openpgp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 21:14:03 -0000 Jumping in a bit late, but hopefully without having missed any of the fun. The smime draft is silent on the whole MTA thing, probably because it presumes that both processing received signed messages, and sending/signing messages, is being done by the MUA. As such, (finding the key and encrypting on its basis) is not a "protocol" issue (case mismatch on input by the user), but an application thing. Selecting the recipient through any UI interaction, rather than explicit entry of the RFC 822-style address, is not a protocol issue. If the UI and/or the user makes an error, that is not a protocol thing. BTW - in case it isn't clear, my opinion of the inclusion of the letters "M", "T", and "A" together in the PGP draft, is that it does not belong. Encrypting contents falls clearly in the MUA space, and does NOT belong in the MTA space. DANE has excellent use cases in the MTA space, but only on use of TLS for transport, not for message content. That's my opinion, at least, and I'd be surprised if that doesn't reflect consensus. Brian On 9/9/13 10:52 AM, "Paul Wouters" wrote: > >It was brought to my attention by Matthias Wimmer that we overlooked >an important issue with respect to the base32 generation of the base32 >encoded left hand side of the email address. > >Mail servers and mail clients do not treat email addresses as >case-insensitive. When encoding an LHS with base32, the case matters. >Using the wrong case will cause you to not find the SMIMEA / OPENPGPKEY >record. > >paul@bofh:$ python >Python 2.7.3 (default, Aug 9 2012, 17:23:57) >[GCC 4.7.1 20120720 (Red Hat 4.7.1-5)] on linux2 >Type "help", "copyright", "credits" or "license" for more information. >>>> import base64 >>>> base64.b32encode("paul") >'OBQXK3A=3D' >>>> base64.b32encode("Paul") >'KBQXK3A=3D' >>>> > >We should probably add a section explaining this, and perhaps suggest to >lowercase before base32'ing the LHS for the lookup. > >Paul >_______________________________________________ >dane mailing list >dane@ietf.org >https://www.ietf.org/mailman/listinfo/dane From paul.hoffman@vpnc.org Tue Sep 10 14:17:06 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB5D21F9DC9 for ; Tue, 10 Sep 2013 14:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnlrpG3XCgiB for ; Tue, 10 Sep 2013 14:17:06 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 24B8921F9DC6 for ; Tue, 10 Sep 2013 14:17:06 -0700 (PDT) Received: from [10.10.11.217] ([207.238.187.242]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8ALGmwT016338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Sep 2013 14:16:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host [207.238.187.242] claimed to be [10.10.11.217] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Tue, 10 Sep 2013 17:16:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <01FC2C8C-984C-48A9-B7C3-1A1C1469E084@vpnc.org> References: <8A7BC0FC-62F8-4883-8FDD-948AAF9DAB78@vpnc.org> To: Paul Wouters X-Mailer: Apple Mail (2.1508) Cc: dane WG list Subject: Re: [dane] case sensitivity and draft-ietf-dane-smime / draft-wouters-dane-openpgp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 21:17:06 -0000 On Sep 10, 2013, at 4:09 PM, Paul Wouters wrote: > On Tue, 10 Sep 2013, Paul Hoffman wrote: >=20 >> On Sep 9, 2013, at 10:52 AM, Paul Wouters = wrote: >>=20 >>> It was brought to my attention by Matthias Wimmer that we overlooked >>> an important issue with respect to the base32 generation of the = base32 >>> encoded left hand side of the email address. >>=20 >> "We" did not overlook that: as author, I made that decision = completely purposefully. >=20 > Perhaps documentation of that decision belonged in the Security = Section > of that document? :) I'm not clear what the security consideration of this is for DANE = outside of what it is for all RFC 821(+bis)(+bis)(+bis) email has been. >>> Mail servers and mail clients do not treat email addresses as >>> case-insensitive. >>=20 >> That is sometimes-true statement. >>=20 >>> When encoding an LHS with base32, the case matters. >>=20 >> Yes, exactly. And so does internationalization. >>=20 >>> Using the wrong case will cause you to not find the SMIMEA / = OPENPGPKEY >>> record. >>=20 >> Yep. And will cause you to sometimes send mail to the wrong = recipient. >=20 > I'm really not okay with a protocol where I encrypt to the wrong key > based on the case of the email address. Errr, then maybe you should not send mail with PGP or S/MIME? Seriously: = this issue precedes DANE by well over a decade. >>> We should probably add a section explaining this, and perhaps = suggest to >>> lowercase before base32'ing the LHS for the lookup. >>=20 >> Yes; no. > [citation needed] We should add a note that case is preserved and that might be = surprising; we should not suggest breaking RFC 821(+bis)(+bis)(+bis) in = this protocol. --Paul Hoffman= From mrex@sap.com Tue Sep 17 11:26:54 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F1F11E8134 for ; Tue, 17 Sep 2013 11:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.181 X-Spam-Level: X-Spam-Status: No, score=-10.181 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sWC5+kEY-AC for ; Tue, 17 Sep 2013 11:26:39 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8B33711E82E6 for ; Tue, 17 Sep 2013 11:26:39 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8HIQLw6021066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Sep 2013 20:26:21 +0200 (MEST) In-Reply-To: To: Paul Wouters Date: Tue, 17 Sep 2013 20:26:21 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130917182621.495791A974@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: dane WG list Subject: Re: [dane] case sensitivity and draft-ietf-dane-smime / draft-wouters-dane-openpgp X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 18:26:54 -0000 Paul Wouters wrote: > On Mon, 9 Sep 2013, Viktor Dukhovni wrote: > > > > Therefore, and are a-priori > > distinct addresses except perhaps in the hands of the MTAs that > > handle example.com mail. > > > > [ The fact that most systems are in practice case-insensitive is not > > sufficient to invalidate the right of some to be case sensitive as > > they see fit. ] > > The _last_ thing I want to do is having an email client not encrypt a > message because someone mailed Paul@example.com instead of > paul@example.com. I do not think that anyone proposed that a MUA should silently fail to encrypt (and send in the clear instead) if lookup of "Paul@example.com" does not provide a result. > > So I think our choices are: > > 1) do a lookup for the case "as is" and a lookup for lowercased (serial > or parallel) > > 2) lowercase and lookup once. I definitely prefer (1), an would want the MUA to tell the user if the lookup result for "as is" differs from the lookup result for the lowercased Email address (this is both, for lookup failure for "as is" and for different EMail address result between "as is" and "all lowercase". > > What I do _not_ think is a valid choice is "only do the as is case > lookup". While it is technically a valid implementation choice (and the only option when there is no user present to confirm), it would not be very user friendly, and alternative, much more user friendly behaviour seems obvious and easy to implement. -Martin From dan-ietf@danyork.org Wed Sep 18 05:57:36 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B019111E82A8 for ; Wed, 18 Sep 2013 05:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.139 X-Spam-Level: X-Spam-Status: No, score=-1.139 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tkLaVYQ-7WI for ; Wed, 18 Sep 2013 05:57:23 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id E079A11E8292 for ; Wed, 18 Sep 2013 05:57:22 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id c3so4451154qcv.18 for ; Wed, 18 Sep 2013 05:57:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:date:message-id:to :mime-version; bh=se5aEVzx/sIGbVtWWvC5MOApWgtl9xL6eCUgAAIjqAo=; b=WLNK3hSwKcWfXbLF3MtHuQXhImoFbAia6AVn6LZeI+JgMONxxZsw5uQrRX0tEFEMSx 2hutUsj1hMrgtE3OsAHVsy1pNV7b/dhfi+L6jGb4ENBsK3vnZ51RV1IP1s04tUO6jNrT ZKkiuvpnXNpr5n6vHLlB7FXRgw5Wd8JdrBs/z8+Temo+EWwkC6rldtV2BrNhBtR/p+uX Q4pIhRvMAodaaYziSbNQcQV+aDXwvfsq8/pISQlrEkWGFKuFgsssL+AKTAsPXRe+GMK0 Qu9oOBxCkxBCbNHD/U4OhNGb33bxrtqxNObFQJwCIPDqFpLVaMgDkpMbo1NoMnx72TDQ ZX2g== X-Gm-Message-State: ALoCoQm4w+AN62k39s2XbZBEa2Bw8XpgeOQDFklZTkgl7fhMpaZQbNf9OyygbSroDMt4GbY4Q0/L X-Received: by 10.224.70.81 with SMTP id c17mr13977926qaj.12.1379509041545; Wed, 18 Sep 2013 05:57:21 -0700 (PDT) Received: from ?IPv6:2001:470:1f07:309:dddd:7bdf:fcff:ffbb? ([2001:470:1f07:309:dddd:7bdf:fcff:ffbb]) by mx.google.com with ESMTPSA id fy7sm2045846qeb.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Sep 2013 05:57:21 -0700 (PDT) From: Dan York Content-Type: multipart/alternative; boundary="Apple-Mail=_688F08D5-97BE-46E4-AFE3-422438AE1013" Date: Wed, 18 Sep 2013 08:57:19 -0400 Message-Id: <88C64E02-9A8F-4940-AAB0-13C7FEAB2B75@danyork.org> To: dane WG list Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [dane] FYI - Call for DANE-related speakers for ICANN 48 DNSSEC Workshop in Buenos Aires in November X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 12:57:36 -0000 --Apple-Mail=_688F08D5-97BE-46E4-AFE3-422438AE1013 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii DANE list members, If any of you (or people you know) will be attending the ICANN 48 = meeting in November in Buenos Aires, Argentina, there will be the usual = DNSSEC Workshop on Wednesday, November 20th. We have a segment of the session where we are planning to focus on DANE = and other applications of DNSSEC and we'd welcome any proposal from = speakers who want to talk about DANE and new tools/services/activities = using DANE. Right now I'm going to be giving a basic intro to DANE and = talk about some of the new developments, but we'd definitely welcome = others who would like to go into detail on anything DANE-related. =20 More info and the full call for speakers can be found at: http://www.internetsociety.org/deploy360/?p=3D16578=20 If you have an idea and will be there at ICANN 48, just send a quick = email to dnssec-buenosaires@shinkuro.com=20 I'd love to see some more DANE topics being presented. The sessions = will be streamed live and also recorded for later viewing. Thanks, Dan --=20 Dan York dyork@lodestar2.com http://www.danyork.me/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork --Apple-Mail=_688F08D5-97BE-46E4-AFE3-422438AE1013 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii DANE = list members,

If any of you (or people you know) will = be attending the ICANN 48 meeting in November in Buenos Aires, = Argentina, there will be the usual DNSSEC Workshop on Wednesday, = November 20th.

We  have a segment of the = session where we are planning to focus on DANE and other applications of = DNSSEC and we'd welcome any proposal from speakers who want to talk = about DANE and new tools/services/activities using DANE. Right now I'm = going to be giving a basic intro to DANE and talk about some of the new = developments, but we'd definitely welcome others who would like to go = into detail on anything DANE-related. =  

More info and the full call for speakers = can be found at:


= If you have an idea and will be there at ICANN 48, just send a quick = email to  dnssec-buenosaires@shinkuro.com 

I'd love to see some more = DANE topics being presented.  The sessions will be streamed live = and also recorded for later = viewing.

Thanks,
Dan

dyork@lodestar2.com
http://www.danyork.me/  &nb= sp;skype:danyork
Phone: = +1-802-735-1624
Twitter - http://twitter.com/danyork



= --Apple-Mail=_688F08D5-97BE-46E4-AFE3-422438AE1013-- From fanf2@hermes.cam.ac.uk Thu Sep 19 10:31:02 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE8A21F9433 for ; Thu, 19 Sep 2013 10:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.079 X-Spam-Level: X-Spam-Status: No, score=-3.079 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-w46WJWqcLs for ; Thu, 19 Sep 2013 10:31:01 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f32]) by ietfa.amsl.com (Postfix) with ESMTP id 8136D21F93F3 for ; Thu, 19 Sep 2013 10:31:01 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:48636) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1VMi4B-0005AS-1M (Exim 4.80_167-5a66dd3) (return-path ); Thu, 19 Sep 2013 18:30:59 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1VMi4B-0001B6-C9 (Exim 4.72) (return-path ); Thu, 19 Sep 2013 18:30:59 +0100 Date: Thu, 19 Sep 2013 18:30:59 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Peter Saint-Andre In-Reply-To: <522A57C8.8040702@stpeter.im> Message-ID: References: <522A57C8.8040702@stpeter.im> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: "dane@ietf.org list" Subject: Re: [dane] draft-ietf-dane-srv X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 17:31:02 -0000 Peter Saint-Andre wrote: > > It seems that draft-ietf-dane-srv has expired. Does the document > editor (and, more important, the WG) still have an interest in moving > this forward? Yes I would like to. I have been busy at work recently, but I will try to find the time to put out an update. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From warren@kumari.net Thu Sep 19 12:56:33 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA5E21F844D for ; Thu, 19 Sep 2013 12:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgXDHxaL3tVK for ; Thu, 19 Sep 2013 12:56:20 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE4621F8447 for ; Thu, 19 Sep 2013 12:56:16 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.103]) by vimes.kumari.net (Postfix) with ESMTPSA id 0BBE71B401AB; Thu, 19 Sep 2013 15:56:16 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Warren Kumari In-Reply-To: <4AE68D21-BBD0-47AB-A566-F4E0EBD379D5@ogud.com> Date: Thu, 19 Sep 2013 15:56:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6FCB9D76-2BE1-4EA1-9FC1-EFF0EEDA7027@kumari.net> References: <20130906145353.32165.91900.idtracker@ietfa.amsl.com> <4AE68D21-BBD0-47AB-A566-F4E0EBD379D5@ogud.com> To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1510) Cc: "dane@ietf.org list" Subject: Re: [dane] Request for WGLC X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 19:56:33 -0000 On Sep 6, 2013, at 10:56 AM, Olafur Gudmundsson wrote: >=20 > Dear Chairs,=20 >=20 > I updated the acronym document based on WG feedback.=20 > Can you please start a WGLC as from my viewpoint the document is = complete. Apologies for the delay in responding.=20 Olafur, would you mind first submitting as a WG document? (The chairs = believe that we saw sufficient support in Berlin that we feel = comfortable just adopting it=85).=20 W >=20 > Olafur >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for = draft-dane-registry-acronym-01.txt >> Date: September 6, 2013 10:53:53 AM EDT >> To: Olafur Gudmundsson >>=20 >>=20 >> A new version of I-D, draft-dane-registry-acronym-01.txt >> has been successfully submitted by Olafur Gudmundsson and posted to = the >> IETF repository. >>=20 >> Filename: draft-dane-registry-acronym >> Revision: 01 >> Title: Adding acronyms to simplify DANE conversations >> Creation date: 2013-09-06 >> Group: Individual Submission >> Number of pages: 5 >> URL: = http://www.ietf.org/internet-drafts/draft-dane-registry-acronym-01.txt >> Status: = http://datatracker.ietf.org/doc/draft-dane-registry-acronym >> Htmlized: = http://tools.ietf.org/html/draft-dane-registry-acronym-01 >> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-dane-registry-acronym-01 >>=20 >> Abstract: >> Experience has show that people get confused using the three = numeric >> fields the TLSA record. This document specifies descriptive = acronyms >> for the three numeric fields in the TLSA records. >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --=20 With Feudalism, it's your Count that votes. From ogud@ogud.com Thu Sep 19 13:12:04 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8744021F89C3 for ; Thu, 19 Sep 2013 13:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXi9z+8UC3Tr for ; Thu, 19 Sep 2013 13:11:54 -0700 (PDT) Received: from smtp84.ord1c.emailsrvr.com (smtp84.ord1c.emailsrvr.com [108.166.43.84]) by ietfa.amsl.com (Postfix) with ESMTP id C94E621F89A5 for ; Thu, 19 Sep 2013 13:11:54 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id E2F5D5038A for ; Thu, 19 Sep 2013 16:11:52 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 1EEF2503A5 for ; Thu, 19 Sep 2013 16:11:48 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Olafur Gudmundsson In-Reply-To: <20130906151154.GX29796@mournblade.imrryr.org> Date: Thu, 19 Sep 2013 16:11:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130809141725.3702.71639.idtracker@ietfa.amsl.com> <20130810021008.GA22978@odin.ulthar.us> <20130906151154.GX29796@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1508) Subject: Re: [dane] New Version Notification for draft-dane-registry-acronym-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 20:12:04 -0000 On Sep 6, 2013, at 11:11 AM, Viktor Dukhovni = wrote: > On Fri, Sep 06, 2013 at 10:42:10AM -0400, Olafur Gudmundsson wrote: >=20 >> Sorry for the delay in responding.=20 >>=20 >> These are excellent suggestions and I have applied in the upcoming = (hopefully final) version.=20 >=20 > One more correction, in the text: >=20 > Sides example: "In the case of FOO for practical cases you can = treat > PKIX-CA =3D=3D DANE-TE" (see talk at IETF-87 on DANE for email) >=20 > replace DANE-TE with DANE-TA. Also I have no idea wha "Sides example" = means. Removed,=20 >=20 > Also since in SMTP the mapping from usage 0 to usage 2 will be > incomplete, a better example would be "PKIX-EE =3D=3D DANE-EE". The > final DANE for SMTP spec will likely say that PKIX usages are simply > unsupported, and SHOULD NOT published, so perhaps it is best to > not use this example at all. Removed.=20 >=20 > FWIW, while when speaking of an individual TLSA RR elements, I > find acronyms helpful, when reading a complete TLSA RRset, I > find=20 >=20 > mail.example.com. IN TLSA 3 1 1 ... >=20 > much easier to quickly parse at a glance than=20 >=20 > mail.example.com. IN TLSA DANE-EE SPKI SHA2-256 ... >=20 > which requires a lot more cognitive effort. >=20 Well that depends on how well versed one is in reading TLSA records,=20 someone who is glancing at the record can make a guess what all the = fields mean=20 in the second case but in the first case it is just numbers, that = requires reading registry or RFC to comprehend.=20 The goal is to make life easier for the non-expert.=20 Olafur From internet-drafts@ietf.org Thu Sep 19 13:12:16 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0AAA21F8C0C; Thu, 19 Sep 2013 13:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRIA5hLfbFR4; Thu, 19 Sep 2013 13:12:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACEF21F89A5; Thu, 19 Sep 2013 13:12:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> Date: Thu, 19 Sep 2013 13:12:16 -0700 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-registry-acronyms-00.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 20:12:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DNS-based Authentication of Named Entitie= s Working Group of the IETF. Title : Adding acronyms to simplify DANE conversations Author(s) : Olafur Gudmundsson Filename : draft-ietf-dane-registry-acronyms-00.txt Pages : 5 Date : 2013-09-19 Abstract: Experience has show that people get confused using the three numeric fields the TLSA record. This document specifies descriptive acronyms for the three numeric fields in the TLSA records. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronyms There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-registry-acronyms-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From warren@kumari.net Thu Sep 19 13:18:47 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731FD21F8618 for ; Thu, 19 Sep 2013 13:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7P+RbGKCxpc for ; Thu, 19 Sep 2013 13:18:42 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD3A21F8414 for ; Thu, 19 Sep 2013 13:18:42 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.103]) by vimes.kumari.net (Postfix) with ESMTPSA id 684941B401BE; Thu, 19 Sep 2013 16:18:41 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Warren Kumari In-Reply-To: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> Date: Thu, 19 Sep 2013 16:18:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> To: "dane@ietf.org list" X-Mailer: Apple Mail (2.1510) Subject: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 20:18:47 -0000 Dear DANE WG, This starts a Working Group Last Call for = draft-ietf-dane-registry-acronym. The draft is available here: = https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronym/ Please review this (really short) draft to see if you think it is ready = for publication and comments to the list, clearly stating your view. This WGLC ends Thu 03-Oct-2013. Thanks, Warren Kumari (as DANE WG co-chair) On Sep 19, 2013, at 4:12 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the DNS-based Authentication of Named = Entities Working Group of the IETF. >=20 > Title : Adding acronyms to simplify DANE conversations > Author(s) : Olafur Gudmundsson > Filename : draft-ietf-dane-registry-acronyms-00.txt > Pages : 5 > Date : 2013-09-19 >=20 > Abstract: > Experience has show that people get confused using the three numeric > fields the TLSA record. This document specifies descriptive = acronyms > for the three numeric fields in the TLSA records. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronyms >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dane-registry-acronyms-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 -- For every complex problem, there is a solution that is simple, neat, and = wrong. -- H. L. Mencken From viktor1dane@dukhovni.org Thu Sep 19 13:23:36 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334F421F8947 for ; Thu, 19 Sep 2013 13:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IS3GRSMMKL8p for ; Thu, 19 Sep 2013 13:23:32 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id AC5FE21F898A for ; Thu, 19 Sep 2013 13:23:31 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F3AFF2AB07E; Thu, 19 Sep 2013 20:23:30 +0000 (UTC) Date: Thu, 19 Sep 2013 20:23:30 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130919202330.GB29796@mournblade.imrryr.org> References: <522A57C8.8040702@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] draft-ietf-dane-srv X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 20:23:36 -0000 On Thu, Sep 19, 2013 at 06:30:59PM +0100, Tony Finch wrote: > > It seems that draft-ietf-dane-srv has expired. Does the document > > editor (and, more important, the WG) still have an interest in moving > > this forward? > > Yes I would like to. I have been busy at work recently, but I will try to > find the time to put out an update. Welcome back. When you get a chance, please also take a look at the new OPS and SMTP drafts Wes and I put together. Let us know if you have any comments, and of course we should try to avoid conflicts between these and the SRV draft. For example, the new SMTP draft specifies that SMTP servers SHOULD NOT publish TLSA RRs with usages 0/1, both for MTA to MTA traffic and for port 587 when MUAs discover submission hosts via SRV records. So the SRV draft should not exclude such application-specific specifications. https://tools.ietf.org/html/draft-dukhovni-smtp-opportunistic-tls-01 https://tools.ietf.org/html/draft-dukhovni-dane-ops-01 with work-in-progress snapshots at: http://vdukhovni.github.io/ietf/ -- Viktor. From sca@andreasschulze.de Thu Sep 19 13:31:54 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE43521F8445 for ; Thu, 19 Sep 2013 13:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkQxdV85sN0p for ; Thu, 19 Sep 2013 13:31:50 -0700 (PDT) Received: from mout.andreasschulze.de (mout.andreasschulze.de [84.201.4.158]) by ietfa.amsl.com (Postfix) with ESMTP id BB5A321F843F for ; Thu, 19 Sep 2013 13:31:50 -0700 (PDT) X-Received: line deleted by mout X-Received: line deleted by mout DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andreasschulze.de; s=GzhbMIk; t=1379622339; r=y; bh=3P69y3bcjUj9gwmKBiW34bcgHl9WoH+GgVEy77S6w9M=; h=Date:From:To:Subject:References:In-Reply-To; z=Date:=20Thu,=2019=20Sep=202013=2022:25:38=20+0200|From:=20Andreas =20Schulze=20|To:=20dane@ietf.org|Subject:= 20Re:=20[dane]=20Start=20of=20WGLC=20for=20draft-ietf-dane-registr y-acronym|References:=20<20130919201216.14866.61161.idtracker@ietf a.amsl.com>=0D=0A=20|In-Reply-To:=20; b=CpVAeZDhW2GwBPAxcUqWWaEjE4+heiLeNrQxlrNS3vtSGd+iYRGlWxw4GyNGIz3fx GbsmGXE4KOuHOnqQgYMLqB2gRMVNXcPpH3qxEL4QlBDDSMWqR5h6ClcUoNInE9Sb3Y 1JCdUWSmlbR6ogOJAm3zVi/oKtU+0663/zH+53LSU7STzOP31TToVrBNkqwIrwSKbe kCpjDUwrh02SfJl6rfjeVz6QGSNwxNseKUwCQ1dxhVdNYTVxKTgN8bfbFscsyjbPkP ALDvRTLB4SDbOlJXNsQDZuMEeHemm8ZtcKSI2T3I+8vujfSjLoRSvlt42IaMaKsdfH cB+10w1HmFrNw7OVVdRBi/ZM06hZyAO5DVT5A6nM/8qHKxy118ZoDUSPPkRD82R6j0 CZ5TmlIH7YLcuMFSTFep5iBMo9vGUsitK+n7ThkrAlKZrY/eX5PwGAP756tjxjSrzm pUFcnhqmfbVXHwE3ZFBGK0kcekNfHA0wl1+0zKr7qX/8ly7Hv7q2VgTrdI8x3VkbcA lD6k63+3PqzZiclmuVCSNlAFk1SktcmBBEaLzvTbGS9y7H/LzZkazs9ITcK+81KDuV +6CAF8Uy3POXpmHIWMsoQOb1Cfv2uIDmwfvTmNajbf+sN5E9jfMlMDpaqY8fY0hEZG XIWLUiJgKdAOys7Mgebulyyw= X-Received: line deleted by mout Date: Thu, 19 Sep 2013 22:25:38 +0200 Message-ID: <20130919222538.Horde.isgFzMX6-T6bYeiR1yuGkg2@horde.andreasschulze.de> From: Andreas Schulze To: dane@ietf.org References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.1.4) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 20:31:54 -0000 Zitat von Warren Kumari : > https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronym/ got a 404 From ynir@checkpoint.com Thu Sep 19 13:33:36 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B55421F8445 for ; Thu, 19 Sep 2013 13:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.317 X-Spam-Level: X-Spam-Status: No, score=-10.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWTcApo+DM9F for ; Thu, 19 Sep 2013 13:33:31 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 228E621F843F for ; Thu, 19 Sep 2013 13:33:30 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8JKXGYO017187; Thu, 19 Sep 2013 23:33:16 +0300 X-CheckPoint: {523B5F8C-44-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Thu, 19 Sep 2013 23:33:16 +0300 From: Yoav Nir To: Andreas Schulze Thread-Topic: [dane] Start of WGLC for draft-ietf-dane-registry-acronym Thread-Index: AQHOtXV3Y3XlWFNpuESRVUCyhbIK3JnNT5gAgAACKIA= Date: Thu, 19 Sep 2013 20:33:16 +0000 Message-ID: <3EE8F8F3-6D6E-4175-8498-4C922232A912@checkpoint.com> References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <20130919222538.Horde.isgFzMX6-T6bYeiR1yuGkg2@horde.andreasschulze.de> In-Reply-To: <20130919222538.Horde.isgFzMX6-T6bYeiR1yuGkg2@horde.andreasschulze.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.151] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 20:33:36 -0000 Me too.=20 This one works: http://tools.ietf.org/html/draft-ietf-dane-registry-acronyms-00 On Sep 19, 2013, at 11:25 PM, Andreas Schulze wrote: >=20 > Zitat von Warren Kumari : >=20 >> https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronym/ > got a 404 >=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From stephen.farrell@cs.tcd.ie Thu Sep 19 13:36:24 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A4221F87B7 for ; Thu, 19 Sep 2013 13:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spuGv9SMH2s8 for ; Thu, 19 Sep 2013 13:36:18 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 973AA21F85EB for ; Thu, 19 Sep 2013 13:36:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 78666BE79; Thu, 19 Sep 2013 21:36:14 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMs967sNLlnV; Thu, 19 Sep 2013 21:36:04 +0100 (IST) Received: from [10.87.48.3] (unknown [86.46.21.7]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 39E55BE77; Thu, 19 Sep 2013 21:36:04 +0100 (IST) Message-ID: <523B602A.2070706@cs.tcd.ie> Date: Thu, 19 Sep 2013 21:35:54 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Yoav Nir References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <20130919222538.Horde.isgFzMX6-T6bYeiR1yuGkg2@horde.andreasschulze.de> <3EE8F8F3-6D6E-4175-8498-4C922232A912@checkpoint.com> In-Reply-To: <3EE8F8F3-6D6E-4175-8498-4C922232A912@checkpoint.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 20:36:24 -0000 Typo. [1] works S [1] https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronyms/ On 09/19/2013 09:33 PM, Yoav Nir wrote: > Me too. > > This one works: > http://tools.ietf.org/html/draft-ietf-dane-registry-acronyms-00 > > On Sep 19, 2013, at 11:25 PM, Andreas Schulze > wrote: > >> >> Zitat von Warren Kumari : >> >>> https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronym/ >> got a 404 >> >> >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > > From warren@kumari.net Thu Sep 19 13:46:46 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9280E21F8976 for ; Thu, 19 Sep 2013 13:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIV246T0jGRq for ; Thu, 19 Sep 2013 13:46:42 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162F221F846E for ; Thu, 19 Sep 2013 13:46:41 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.103]) by vimes.kumari.net (Postfix) with ESMTPSA id 51D881B401AB; Thu, 19 Sep 2013 16:46:39 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Warren Kumari In-Reply-To: <523B602A.2070706@cs.tcd.ie> Date: Thu, 19 Sep 2013 16:46:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0EBACB6A-351F-4FF0-BE55-95301C357A8D@kumari.net> References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <20130919222538.Horde.isgFzMX6-T6bYeiR1yuGkg2@horde.andreasschulze.de> <3EE8F8F3-6D6E-4175-8498-4C922232A912@checkpoint.com> <523B602A.2070706@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1510) Cc: "" Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 20:46:46 -0000 On Sep 19, 2013, at 4:35 PM, Stephen Farrell = wrote: >=20 > Typo. [1] works Doh! I have a script that generates these mails (and throws a reminder onto = my calendar=85) -- guess I need to add some better error checking=85 It's one of those "I'm *sure* I can save myself heaps of time by writing = a script to do this" and then you waste way more time writing the = script[0][1]. W [0]: http://xkcd.com/1205/ [1]:=20 "I've just spent a cheerful hours of my time writing a program on my = computer that will tell me instantly what the volume of the mound was. = It's a very neat and sexy program with all sorts of pop-up menus and = things, and the advantage of doing it the way I have is that on any = future occasion on which I need to know the volume of a megapode nest, = given its basic dimensions, my computer will give the answer in less = than a second, which is a wonderful saving of time. The downside, I = suppose, is that I cannot conceive of any further occasion that I am = likely to need to know the volume of a megapode nest,... " Douglas = Adams, "Last Chance to See" >=20 > S >=20 > [1] = https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronyms/ >=20 > On 09/19/2013 09:33 PM, Yoav Nir wrote: >> Me too.=20 >>=20 >> This one works: >> http://tools.ietf.org/html/draft-ietf-dane-registry-acronyms-00 >>=20 >> On Sep 19, 2013, at 11:25 PM, Andreas Schulze >> wrote: >>=20 >>>=20 >>> Zitat von Warren Kumari : >>>=20 >>>> https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronym/ >>> got a 404 >>>=20 >>>=20 >>> _______________________________________________ >>> dane mailing list >>> dane@ietf.org >>> https://www.ietf.org/mailman/listinfo/dane >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >>=20 >>=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 -- "Real children don't go hoppity-skip unless they are on drugs." -- Susan, the ultimate sensible governess (Terry Pratchett, = Hogfather) From cloos@jhcloos.com Thu Sep 19 15:04:37 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7D521F8790 for ; Thu, 19 Sep 2013 15:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbdvNal6jpHP for ; Thu, 19 Sep 2013 15:04:37 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) by ietfa.amsl.com (Postfix) with ESMTP id 01D3A21F8613 for ; Thu, 19 Sep 2013 15:04:36 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 92E7A1DFC5; Thu, 19 Sep 2013 22:04:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1379628271; bh=E6zy15k5oldnYq5Hjd+P6Vfy9hcwTK40NpcSZ1nhams=; h=From:To:Subject:In-Reply-To:References:Date:From; b=A1rQRp89SvPiykngJEDmDIAQlcFClhSpOGOaiuVbcm5cs6bo+jxkpDSBZ3dmNtmQ2 aLBBNyxJxI7rox9+0NnicLpm90LFm8gGk6xuhWec0wSBFel3GIEKUMjAUj0Xc4qpIw d0X0BKvwINchng5rRrwVPGXeg540eOxpuAUlDw4SxHw== Received: by carbon.jhcloos.org (Postfix, from userid 500) id CE2346001E; Thu, 19 Sep 2013 22:00:49 +0000 (UTC) From: James Cloos To: "dane\@ietf.org list" In-Reply-To: (Warren Kumari's message of "Thu, 19 Sep 2013 16:18:39 -0400") References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Thu, 19 Sep 2013 18:00:49 -0400 Message-ID: Lines: 31 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:130919:"dane\@ietf.org::47xvjElLUEv0F2t4:05uBQp X-Hashcash: 1:28:130919:dane@ietf.org::cL7WMpii+tyOiC1/:000g64WX Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 22:04:37 -0000 PKIX-TA looks better than PKIX-CA; CA makes it look like it has to be an association to a root cert. It would be nice to have a better short description for type 3 than Domain-issued certificate, notwithstanding the existance of that string in rfc 6698. DANE isn't about issuing certs, but rather about establishing trust paths to them. But I cannot come up with an alternative.... Nits: The paragraph: "It is expected that DANE parser's in applications and DNS software MAY adopt parsing the acronyms for each field, installed base MAY NOT get updated." could use better grammar. Perhaps: s/each field, installed base/each field, but the installed base/ And perhaps /MAY NOT/may not/. Unlike the first MAY, the may not isn't really a 2119. (The Nits link agrees.) In the xml, I'd do: s(CA constraint)(CA constraint) it should look better in the output. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From viktor1dane@dukhovni.org Thu Sep 19 15:10:40 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11A521F85BB for ; Thu, 19 Sep 2013 15:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFgO7SE1K7kz for ; Thu, 19 Sep 2013 15:10:35 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id DEF8921F84D9 for ; Thu, 19 Sep 2013 15:10:35 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4F3602AB07E; Thu, 19 Sep 2013 22:10:35 +0000 (UTC) Date: Thu, 19 Sep 2013 22:10:35 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130919221035.GC29796@mournblade.imrryr.org> References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 22:10:41 -0000 On Thu, Sep 19, 2013 at 06:00:49PM -0400, James Cloos wrote: > Nits: > > The paragraph: "It is expected that DANE parser's in applications and While we're "nitting", the plural "parsers" should not have an apostrophe. Agreed on PKIX-TA vs. PKIX-CA. -- Viktor. From warren@kumari.net Thu Sep 19 16:07:46 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B4121F8B4E for ; Thu, 19 Sep 2013 16:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybGbDRMLun4k for ; Thu, 19 Sep 2013 16:07:42 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33DB21F89EB for ; Thu, 19 Sep 2013 16:07:28 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.103]) by vimes.kumari.net (Postfix) with ESMTPSA id E6DED1B400EE; Thu, 19 Sep 2013 19:07:26 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Warren Kumari In-Reply-To: <20130919202330.GB29796@mournblade.imrryr.org> Date: Thu, 19 Sep 2013 19:07:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <522A57C8.8040702@stpeter.im> <20130919202330.GB29796@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1510) Subject: Re: [dane] draft-ietf-dane-srv X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 23:07:46 -0000 On Sep 19, 2013, at 4:23 PM, Viktor Dukhovni = wrote: > On Thu, Sep 19, 2013 at 06:30:59PM +0100, Tony Finch wrote: >=20 >>> It seems that draft-ietf-dane-srv has expired. Does the document >>> editor (and, more important, the WG) still have an interest in = moving >>> this forward? >>=20 >> Yes I would like to. I have been busy at work recently, but I will = try to >> find the time to put out an update. >=20 > Welcome back. +1.=20 > When you get a chance, please also take a look at > the new OPS and SMTP drafts Wes and I put together. Let us know > if you have any comments, and of course we should try to avoid > conflicts between these and the SRV draft. >=20 > For example, the new SMTP draft specifies that SMTP servers SHOULD > NOT publish TLSA RRs with usages 0/1, both for MTA to MTA traffic > and for port 587 when MUAs discover submission hosts via SRV records. > So the SRV draft should not exclude such application-specific > specifications. >=20 During the Berlin meeting it was proposed that draft-ietf-dane-smtp be = merged with draft-dukhovni-smtp-opportunistic-tls. There was overwhelming support in favor of doing so -- I'm assuming = y'all are fine with this? Also, while catching up=85 There was a proposal to adopt draft-dukhovni-dane-ops-01.=20 There was overwhelming support for doing so, and no objections. I will = initial an onlist call for adoption inna bit=85 W > = https://tools.ietf.org/html/draft-dukhovni-smtp-opportunistic-tls-01 > https://tools.ietf.org/html/draft-dukhovni-dane-ops-01 >=20 > with work-in-progress snapshots at: >=20 > http://vdukhovni.github.io/ietf/ >=20 > --=20 > Viktor. > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 --=20 Do not meddle in the affairs of wizards, for they are subtle and quick = to anger. =20 -- J.R.R. Tolkien From warren@kumari.net Thu Sep 19 16:11:12 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3C421F893E for ; Thu, 19 Sep 2013 16:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21uE0XA2V2tw for ; Thu, 19 Sep 2013 16:11:08 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB53921F856A for ; Thu, 19 Sep 2013 16:11:04 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.103]) by vimes.kumari.net (Postfix) with ESMTPSA id 883491B401CE; Thu, 19 Sep 2013 19:11:04 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Sep 2013 19:11:04 -0400 Message-Id: <2C4C1296-8731-4B7D-A434-F766B61748BA@kumari.net> To: "dane@ietf.org list" , draft-dukhovni-dane-ops@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [dane] Start of WGLC for draft-dukhovni-dane-ops X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 23:11:12 -0000 Dear DANE WG, This starts a Working Group Last Call for draft-dukhovni-dane-ops. The draft is available here: = https://datatracker.ietf.org/doc/draft-dukhovni-dane-ops/ Please review this draft to see if you think it is ready for publication and comments to the list, clearly stating your view. We polled the room in Berlin and there was very good support for = adopting this.=20 Here is a link to the slides to jog your memory (presented by Wes): = http://www.ietf.org/proceedings/87/slides/slides-87-dane-1.pdf This WGLC ends Thu 03-Oct-2013. Thanks, Warren Kumari (as DANE WG co-chair) -- Curse the dark, or light a match. You decide, it's your dark. -- Valdis Kletnieks From warren@kumari.net Thu Sep 19 16:14:51 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF25C21F871B for ; Thu, 19 Sep 2013 16:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.765 X-Spam-Level: X-Spam-Status: No, score=-101.765 tagged_above=-999 required=5 tests=[AWL=-0.562, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cotnOb0Uh0kw for ; Thu, 19 Sep 2013 16:14:47 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4568F21F859C for ; Thu, 19 Sep 2013 16:14:46 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.103]) by vimes.kumari.net (Postfix) with ESMTPSA id D07741B401C3; Thu, 19 Sep 2013 19:14:45 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Warren Kumari In-Reply-To: <2C4C1296-8731-4B7D-A434-F766B61748BA@kumari.net> Date: Thu, 19 Sep 2013 19:14:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4A6A8691-9E31-4C37-A89E-68D126085EB5@kumari.net> References: <2C4C1296-8731-4B7D-A434-F766B61748BA@kumari.net> To: "dane@ietf.org list" , draft-dukhovni-dane-ops@tools.ietf.org X-Mailer: Apple Mail (2.1510) Subject: Re: [dane] Start of WGLC for draft-dukhovni-dane-ops X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 23:14:52 -0000 Bugger. I *obviously* should not be doing anything with a computer = today=85 I ran the wrong script=85 This was supposed to be a call for adoption=85.=20= Please disregard=85 Ever have one of those days?! I'm having one of those weeks=85 W On Sep 19, 2013, at 7:11 PM, Warren Kumari wrote: > Dear DANE WG, >=20 > This starts a Working Group Last Call for draft-dukhovni-dane-ops. >=20 > The draft is available here: = https://datatracker.ietf.org/doc/draft-dukhovni-dane-ops/ >=20 > Please review this draft to see if you think it is ready for = publication > and comments to the list, clearly stating your view. >=20 > We polled the room in Berlin and there was very good support for = adopting this.=20 > Here is a link to the slides to jog your memory (presented by Wes): = http://www.ietf.org/proceedings/87/slides/slides-87-dane-1.pdf >=20 > This WGLC ends Thu 03-Oct-2013. >=20 > Thanks, > Warren Kumari > (as DANE WG co-chair) >=20 >=20 >=20 > -- > Curse the dark, or light a match. You decide, it's your dark. > -- Valdis Kletnieks >=20 >=20 -- The plural of anecdote is not evidence. -- Bill Lockyer, California Attorney General From warren@kumari.net Thu Sep 19 16:21:45 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7279921F8AF4 for ; Thu, 19 Sep 2013 16:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.436 X-Spam-Level: X-Spam-Status: No, score=-102.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tq9exFeva61a for ; Thu, 19 Sep 2013 16:21:40 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C9321F8984 for ; Thu, 19 Sep 2013 16:21:40 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.103]) by vimes.kumari.net (Postfix) with ESMTPSA id 2BCD61B40150; Thu, 19 Sep 2013 19:21:39 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Sep 2013 19:21:38 -0400 Message-Id: To: "dane@ietf.org list" , "draft-dukhovni-dane-ops@tools.ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [dane] Call for Adoption: draft-dukhovni-dane-ops X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 23:21:45 -0000 Dear DANE WG, Please disregard the previous mail where I accidentally tried to start a = WGLC. Wrong button... This starts a Call for Adoption for draft-dukhovni-dane-ops. The draft is available here: = https://datatracker.ietf.org/doc/draft-dukhovni-dane-ops/ Please review this draft to see if you think it is suitable for adoption = by DANE, and comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. We polled the room in Berlin and there was very good support for = adopting this.=20 Here is a link to the slides to jog your memory (presented by Wes = Hardaker): = http://www.ietf.org/proceedings/87/slides/slides-87-dane-1.pdf This call for adoption ends Thu 03-Oct-2013. Thanks, Warren Kumari (as DANE WG co-chair) P.S: Yes, I did just acknowledge that I am over tired / distracted and = shouldn't be sitting in front of a machine anymore=85 And yet I'm still poking at things. What could possibly go wrong?!=20 -- Some people are like Slinkies......Not really good for anything but they = still bring a smile to your face when you push them down the stairs. From cloos@jhcloos.com Thu Sep 19 16:23:19 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC02221F8C40 for ; Thu, 19 Sep 2013 16:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTp5KI2DsAYL for ; Thu, 19 Sep 2013 16:23:14 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) by ietfa.amsl.com (Postfix) with ESMTP id 4315921F8B12 for ; Thu, 19 Sep 2013 16:23:14 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id F0FA41DFC5; Thu, 19 Sep 2013 23:23:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1379632992; bh=yeKvCHo/igzwPbW6RJopnKn6VxCzc8IvtteFPuKjefo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=T/kFBSLSDOOsavU0EyiZJHok4l3bP0xlDX9lCFxv9hUv1Vej/Onp6TDGEWFo6VIbw tPu4g7lUW//Ji12PemKSp9qh27QjJYxuXXRXBrvfYerYknEr8jQJoBj3ya8E9feauH J/deQYYc3zZ0jfd45JwTvdON1G33DT8sOE7H1pYxKHw== Received: by carbon.jhcloos.org (Postfix, from userid 500) id 7206D6001E; Thu, 19 Sep 2013 23:21:27 +0000 (UTC) From: James Cloos To: Viktor Dukhovni In-Reply-To: <20130919221035.GC29796@mournblade.imrryr.org> (Viktor Dukhovni's message of "Thu, 19 Sep 2013 22:10:35 +0000") References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <20130919221035.GC29796@mournblade.imrryr.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Thu, 19 Sep 2013 19:21:27 -0400 Message-ID: Lines: 13 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:130919:viktor1dane@dukhovni.org::orABxW/XWw3H5+wx:000000000000000000000000000000000000FmQep X-Hashcash: 1:28:130919:dane@ietf.org::6drKweZ7ZrNIN7U5:0001jDZt Cc: dane@ietf.org Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 23:23:20 -0000 >>>>> "VD" == Viktor Dukhovni writes: >> The paragraph: "It is expected that DANE parser's in applications and VD> While we're "nitting", the plural "parsers" should not have an VD> apostrophe. Agreed on PKIX-TA vs. PKIX-CA. Yikes. Even with the cut-n-paste I missed the existance of that apostrophe. :^( -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From cloos@jhcloos.com Thu Sep 19 16:42:29 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C33021F841B for ; Thu, 19 Sep 2013 16:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTydvgjBZ8iF for ; Thu, 19 Sep 2013 16:42:25 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAA421F84EF for ; Thu, 19 Sep 2013 16:42:25 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 7502F1DFCA; Thu, 19 Sep 2013 23:42:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1379634144; bh=/3PzXB/jJto+VdH/1JXGp6y3sVdmd6UELLUwO64KbsU=; h=From:To:Subject:In-Reply-To:References:Date:From; b=j/+6AavQ8QuFj96KgVd5uxJyOgdRVRMHQWyPB+9Jpc2WBB/Q8kPG+UONakbuDIJFY HaokGNqmHPooz2JZpl5rXJDXnSrEQynkiWXL9lQRwYLmltT4HaKaT12poW/iBIrsU6 xuu3rFiTsCIcxQXomTg2m58xsUBfsss111zJa+sDi7A== Received: by carbon.jhcloos.org (Postfix, from userid 500) id EAB126001E; Thu, 19 Sep 2013 23:41:45 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: (Warren Kumari's message of "Thu, 19 Sep 2013 19:21:38 -0400") References: User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Thu, 19 Sep 2013 19:41:45 -0400 Message-ID: Lines: 5 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:130919:dane@ietf.org::Qd7I2g60bSZnFjFx:0002P/H7 Subject: Re: [dane] Call for Adoption: draft-dukhovni-dane-ops X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 23:42:29 -0000 +1 -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From viktor1dane@dukhovni.org Thu Sep 19 19:11:34 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB44721F864D for ; Thu, 19 Sep 2013 19:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbKiJJTtzc2N for ; Thu, 19 Sep 2013 19:11:29 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id C77AC21F8640 for ; Thu, 19 Sep 2013 19:11:29 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EDF572AB07E; Fri, 20 Sep 2013 02:11:24 +0000 (UTC) Date: Fri, 20 Sep 2013 02:11:24 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130920021124.GE29796@mournblade.imrryr.org> References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <20130919221035.GC29796@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130919221035.GC29796@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 02:11:35 -0000 On Thu, Sep 19, 2013 at 10:10:35PM +0000, Viktor Dukhovni wrote: > Agreed on PKIX-TA vs. PKIX-CA. On second thought, I am not so sure, the CA constraint with usage 0, is NOT a trust-anchor, the trust-anchor is still the PKIX root CA. This usage requires the presence of a given CA (root or intermediate) in the chain, but does not promote that CA to a trust anchor (as with usage 2). So perhaps the original PKIX-CA is in fact better. -- Viktor. From oej@edvina.net Thu Sep 19 22:48:26 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C655A21F85E6 for ; Thu, 19 Sep 2013 22:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxB-ZUqof7rG for ; Thu, 19 Sep 2013 22:48:25 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 370BF21F8503 for ; Thu, 19 Sep 2013 22:48:23 -0700 (PDT) Received: from [192.168.40.16] (h87-96-134-126.dynamic.se.alltele.net [87.96.134.126]) by smtp7.webway.se (Postfix) with ESMTPA id 32FBE93C2A1; Fri, 20 Sep 2013 05:48:20 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_8BD4471E-D1B8-4E0F-B9A1-703C34510872" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Olle E. Johansson" In-Reply-To: Date: Fri, 20 Sep 2013 07:48:24 +0200 Message-Id: <4920FC9A-2A2A-4992-B252-D18D7372CB03@edvina.net> References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> To: Warren Kumari X-Mailer: Apple Mail (2.1508) Cc: "dane@ietf.org list" Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 05:48:26 -0000 --Apple-Mail=_8BD4471E-D1B8-4E0F-B9A1-703C34510872 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 19 sep 2013 kl. 22:18 skrev Warren Kumari : > Dear DANE WG, >=20 > This starts a Working Group Last Call for = draft-ietf-dane-registry-acronym. >=20 > The draft is available here: = https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronym/ >=20 > Please review this (really short) draft to see if you think it is = ready for publication > and comments to the list, clearly stating your view. This is a step forward. It will make it easier to understand, discuss = and configure DANE. /O >=20 > This WGLC ends Thu 03-Oct-2013. >=20 > Thanks, > Warren Kumari > (as DANE WG co-chair) >=20 > On Sep 19, 2013, at 4:12 PM, internet-drafts@ietf.org wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the DNS-based Authentication of Named = Entities Working Group of the IETF. >>=20 >> Title : Adding acronyms to simplify DANE conversations >> Author(s) : Olafur Gudmundsson >> Filename : draft-ietf-dane-registry-acronyms-00.txt >> Pages : 5 >> Date : 2013-09-19 >>=20 >> Abstract: >> Experience has show that people get confused using the three numeric >> fields the TLSA record. This document specifies descriptive = acronyms >> for the three numeric fields in the TLSA records. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronyms >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-dane-registry-acronyms-00 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >>=20 >=20 > -- > For every complex problem, there is a solution that is simple, neat, = and wrong. > -- H. L. Mencken >=20 >=20 >=20 >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden --Apple-Mail=_8BD4471E-D1B8-4E0F-B9A1-703C34510872 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii warren@kumari.net>:
Dear DANE = WG,

This starts a Working Group Last Call for = draft-ietf-dane-registry-acronym.

The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronym/
Please review this (really short) draft to see if you think it is = ready for publication
and comments to the list, clearly stating your = view.

This is a step forward. It will = make it easier to understand, discuss and configure = DANE.

/O

This = WGLC ends Thu 03-Oct-2013.

Thanks,
Warren Kumari
(as DANE = WG co-chair)

On Sep 19, 2013, at 4:12 PM, internet-drafts@ietf.org = wrote:


A New Internet-Draft is = available from the on-line Internet-Drafts directories.
This draft is = a work item of the DNS-based Authentication of Named Entities Working = Group of the IETF.

Title =           : Adding = acronyms to simplify DANE conversations
Author(s) =       : Olafur Gudmundsson
Filename =        : = draft-ietf-dane-registry-acronyms-00.txt
Pages =           : 5
Date =            : = 2013-09-19

Abstract:
 Experience has show that people = get confused using the three numeric
 fields the TLSA record. =  This document specifies descriptive acronyms
 for the = three numeric fields in the TLSA records.


The IETF = datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronyms
There's also a htmlized version available = at:
http://tools.ietf.org/html/draft-ietf-dane-registry-acronyms-00
=

Please note that it may take a couple of minutes from the time = of submission
until the htmlized version and diff are available at = tools.ietf.org.

Internet-Drafts are also available by anonymous = FTP = at:
ftp://ftp.ietf.org/internet-drafts/

________________________= _______________________
dane mailing = list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane

--
For every complex problem, there is a solution = that is simple, neat, and wrong.
=             &n= bsp;  -- H. L. = Mencken




_______________________________________________=
dane mailing list
dane@ietf.org
https://www.ietf.org/ma= ilman/listinfo/dane

---
* Olle E = Johansson - oej@edvina.net
* Cell phone = +46 70 593 68 51, Office +46 8 96 40 20, Sweden



= --Apple-Mail=_8BD4471E-D1B8-4E0F-B9A1-703C34510872-- From cloos@jhcloos.com Fri Sep 20 03:12:55 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF12621F91A3 for ; Fri, 20 Sep 2013 03:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.875 X-Spam-Level: X-Spam-Status: No, score=-1.875 tagged_above=-999 required=5 tests=[AWL=-0.476, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgYbqNkwozR2 for ; Fri, 20 Sep 2013 03:12:51 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) by ietfa.amsl.com (Postfix) with ESMTP id 938B521F9195 for ; Fri, 20 Sep 2013 03:12:51 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 111921E135; Fri, 20 Sep 2013 10:12:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1379671969; bh=QPJgu0f23ZJ3DwAo/SesypfseZFJw3gejRm2ZL8bghI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=avyjEwvEFsOrZclKmdBP+1ahjJKhEcGUcVAOAwml7Kaei4t2wZ/toznAAS615b8lp k0B6iMqfyuBA43sPQbc79gQosn+pjfbrmGJjDD0ilA6wBi+TM0dQ0F7n/KsxcXJcWh 5Xgg7pEhuU8F5wSoUZAC6mOKHcLjdGjM5IkPO7LteOw== Received: by carbon.jhcloos.org (Postfix, from userid 500) id 110536001E; Fri, 20 Sep 2013 10:10:48 +0000 (UTC) From: James Cloos To: dane@ietf.org In-Reply-To: <20130920021124.GE29796@mournblade.imrryr.org> (Viktor Dukhovni's message of "Fri, 20 Sep 2013 02:11:24 +0000") References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <20130919221035.GC29796@mournblade.imrryr.org> <20130920021124.GE29796@mournblade.imrryr.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 20 Sep 2013 06:10:48 -0400 Message-ID: Lines: 18 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:130920:dane@ietf.org::j+GuTJrEW/ipeszy:0000k2mg X-Hashcash: 1:28:130920:viktor1dane@dukhovni.org::+JDJo35FM9oPSRie:000000000000000000000000000000000000HL0DZ Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 10:12:55 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> This usage requires the presence of a given CA (root or intermediate) VD> in the chain, but does not promote that CA to a trust anchor (as VD> with usage 2). So perhaps the original PKIX-CA is in fact better. On a ship with multiple anchors, each /is/ still an anchor. Even if the crew does not trust one at a time to hold the ship in place. The type 0/1 tlsa are anchors, but the admin lacks trust in either technology on its own and requires both technologies verify. It also IMHO looks cleaner (perhaps also less confusing) to have one bit specify EE|TA and the other specify CERT|DANE. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From viktor1dane@dukhovni.org Fri Sep 20 07:27:18 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D852321F9A49 for ; Fri, 20 Sep 2013 07:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTw0jT8aVjt7 for ; Fri, 20 Sep 2013 07:27:13 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id AF66021F9A40 for ; Fri, 20 Sep 2013 07:27:13 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C02732AB0A4; Fri, 20 Sep 2013 14:27:10 +0000 (UTC) Date: Fri, 20 Sep 2013 14:27:10 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130920142710.GG29796@mournblade.imrryr.org> References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <20130919221035.GC29796@mournblade.imrryr.org> <20130920021124.GE29796@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 14:27:19 -0000 On Fri, Sep 20, 2013 at 06:10:48AM -0400, James Cloos wrote: > VD> This usage requires the presence of a given CA (root or intermediate) > VD> in the chain, but does not promote that CA to a trust anchor (as > VD> with usage 2). So perhaps the original PKIX-CA is in fact better. > > On a ship with multiple anchors, each /is/ still an anchor. Even if > the crew does not trust one at a time to hold the ship in place. I look at this as a ship with an anchor, and a "golden link" in the chain (O.K., gold is not stronger than iron, but we won't take this metaphor too literally). Yes, the "golden link" can also be a "golden anchor" when the TLSA record association data matches a public root CA. An interesting anomaly arises at a site that only explicitly trusts an intermediate CA (via appropriate local software and configuration) and is validating a chain that starts with an untrusted ancestor CA that matches the TLSA RR: TLSA-CA -> ... -> local PKIX-TA -> ... -> EE certificate Should DANE admit this chain? Under the "2 anchors" analogy arguably it should. I think it should not. The CA *constraint* in RFC 6698 was never intended to accept more certificate chains than one would accept with PKIX alone, it is supposed to only be an additional check. The PKIX trust anchor is primary and plays an assymetric role. > The type 0/1 tlsa are anchors, but the admin lacks trust in either > technology on its own and requires both technologies verify. I think this is a radical departure from PKIX terminology. -- Viktor. From viktor1dane@dukhovni.org Fri Sep 20 07:30:12 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A99421F9A05 for ; Fri, 20 Sep 2013 07:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMP8rd5Jb2YU for ; Fri, 20 Sep 2013 07:30:07 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [208.77.212.107]) by ietfa.amsl.com (Postfix) with ESMTP id 270CC21F9B10 for ; Fri, 20 Sep 2013 07:30:02 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 843192AB0A4; Fri, 20 Sep 2013 14:30:01 +0000 (UTC) Date: Fri, 20 Sep 2013 14:30:01 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20130920143001.GH29796@mournblade.imrryr.org> References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <20130919221035.GC29796@mournblade.imrryr.org> <20130920021124.GE29796@mournblade.imrryr.org> <20130920142710.GG29796@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130920142710.GG29796@mournblade.imrryr.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 14:30:12 -0000 On Fri, Sep 20, 2013 at 02:27:10PM +0000, Viktor Dukhovni wrote: > The PKIX trust anchor is primary and plays an assymetric role. [ Muphry strikes! The PKIX TA Measures how big an ass the verifier is for trusting it :-) ] -- Viktor. From david.lloyd@fsmail.net Sat Sep 21 04:31:16 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BBE11E8151 for ; Sat, 21 Sep 2013 04:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_50=0.001, SARE_FREE_WEBM_NetFs=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEJlQHLpPs5U for ; Sat, 21 Sep 2013 04:31:10 -0700 (PDT) Received: from smtpout.wanadoo.co.uk (smtpout5.wanadoo.co.uk [80.12.242.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7F63611E814E for ; Sat, 21 Sep 2013 04:31:09 -0700 (PDT) Received: from wwinf3706 ([10.232.27.33]) by mwinf5d65 with ME id TnX81m0060irfA203nX8S2; Sat, 21 Sep 2013 13:31:08 +0200 Date: Sat, 21 Sep 2013 13:31:08 +0200 From: david.lloyd@fsmail.net To: ipsec@ietf.org, dane@ietf.org Message-ID: <22017290.30831379763068147.JavaMail.www@wwinf3706> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [86.26.3.116] X-Wum-Nature: EMAIL-NATURE X-WUM-FROM: |~| X-WUM-TO: |~||~| X-WUM-REPLYTO: |~| Subject: [dane] Bootstrapping IPSec from DNSSSEC/DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: david.lloyd@fsmail.net List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 11:31:16 -0000 Hi, I am interested in using a variant of DANE to bootstrap my IPSec IKE root certificate trust. Is anyone aware of any work been done in this area? >From my understanding, it looks as though the is no technical issue with using reverse DNS lookup for the IPSec target machine with DNSSec (although this may be a little unreliable on the "real-world" internet), so returning standard DANE entries for the IPSec certificate. Then I would simply use these as part of the standard IPSec certificate validation algorithm. Looking at similar proposed applications of DANE, such as the draft-ietf-dane-srv, mostly this involves defining an appropriate protocol query name (for example _ipsec.123.123.123.123.in-addr.arpa). Is this something that would fit into an existing document either from the IKE side or the DANE side? Or would it be worth me creating an more extensive proposal? Regards, David L P.S. Sorry for cross-signing two lists! From ynir@checkpoint.com Sat Sep 21 05:59:41 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA5911E81BF; Sat, 21 Sep 2013 05:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.328 X-Spam-Level: X-Spam-Status: No, score=-10.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kmooTmpFSOQ; Sat, 21 Sep 2013 05:59:36 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 393B011E81BB; Sat, 21 Sep 2013 05:59:36 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8LCxP4Y020496; Sat, 21 Sep 2013 15:59:25 +0300 X-CheckPoint: {523D982C-A-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Sat, 21 Sep 2013 15:59:24 +0300 From: Yoav Nir To: "" Thread-Topic: [dane] Bootstrapping IPSec from DNSSSEC/DANE Thread-Index: AQHOtr4iTVR6J9u2QkGzbufPDyXY6JnP9QKA Date: Sat, 21 Sep 2013 12:59:24 +0000 Message-ID: <39C9757C-9E0B-4606-AB6F-5143E913EF95@checkpoint.com> References: <22017290.30831379763068147.JavaMail.www@wwinf3706> In-Reply-To: <22017290.30831379763068147.JavaMail.www@wwinf3706> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.24.10] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [dane] Bootstrapping IPSec from DNSSSEC/DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 12:59:41 -0000 Hi David I believe this would require a separate document. But I'm not sure that tyi= ng it to an IP address is appropriate. IKE implementations work from behind= NAT devices and sometimes move around (see MOBIKE), so I think it would be= more appropriate to tie the record to any type of ID payload that we have = in IKE: IP address and FQDN at least, maybe also KEYID and RFC822 address.= =20 You might need to profile the IKE IDs used for this. Yoav On Sep 21, 2013, at 2:31 PM, david.lloyd@fsmail.net wrote: > Hi, >=20 > I am interested in using a variant of DANE to bootstrap my IPSec IKE root= certificate trust. Is anyone aware of any work been done in this area? >=20 > From my understanding, it looks as though the is no technical issue with = using reverse DNS lookup for the IPSec target machine with DNSSec (although= this may be a little unreliable on the "real-world" internet), so returnin= g standard DANE entries for the IPSec certificate. Then I would simply use= these as part of the standard IPSec certificate validation algorithm. >=20 > Looking at similar proposed applications of DANE, such as the draft-ietf-= dane-srv, mostly this involves defining an appropriate protocol query name = (for example _ipsec.123.123.123.123.in-addr.arpa). >=20 > Is this something that would fit into an existing document either from th= e IKE side or the DANE side? Or would it be worth me creating an more exte= nsive proposal? >=20 > Regards, >=20 > David L >=20 > P.S. Sorry for cross-signing two lists! > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From cloos@jhcloos.com Sat Sep 21 07:39:36 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1FA21F9EB8; Sat, 21 Sep 2013 07:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qljzF6T4SFJT; Sat, 21 Sep 2013 07:39:36 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3B521F9EAF; Sat, 21 Sep 2013 07:39:35 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 8963A1DE6D; Sat, 21 Sep 2013 14:39:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1379774373; bh=x0eqD840frbzCOtcc9WTlr/tkBwrUloxl9383/JQ7fc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=lcHqNq+xts2qfacIYjC5i856ExUOvBdLFe+fTNDBp4M3yIhr7ffMm///tisA7ba18 95arnerKREj2aLGygRjR0B1Eth1vp2hU+1Qny565VdwYri1k3+BMKDkCkO9vtxMeUp MRC/Y0Q7j9cjTg0TPCK09TYpsPbvFvG0UYg4pFkowSQ== Received: by carbon.jhcloos.org (Postfix, from userid 500) id CB4A06001E; Sat, 21 Sep 2013 14:36:51 +0000 (UTC) From: James Cloos To: david.lloyd@fsmail.net In-Reply-To: <22017290.30831379763068147.JavaMail.www@wwinf3706> (david lloyd's message of "Sat, 21 Sep 2013 13:31:08 +0200") References: <22017290.30831379763068147.JavaMail.www@wwinf3706> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2013 James Cloos OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sat, 21 Sep 2013 10:36:51 -0400 Message-ID: Lines: 8 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:130921:david.lloyd@fsmail.net::ayx3ztgeF1P5uilV:00000000000000000000000000000000000000O5v2U X-Hashcash: 1:28:130921:ipsec@ietf.org::0YzCxo1IZ7OC/nSW:004tjjP X-Hashcash: 1:28:130921:dane@ietf.org::HqYYCod2wEN7g9nU:0003XIT5 Cc: ipsec@ietf.org, dane@ietf.org Subject: Re: [dane] Bootstrapping IPSec from DNSSSEC/DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 14:39:36 -0000 > I am interested in using a variant of DANE to bootstrap my IPSec IKE > root certificate trust. Is anyone aware of any work been done in this Start with rfcs 4025 and 4322. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From paul@cypherpunks.ca Sat Sep 21 18:53:55 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B9911E81F5; Sat, 21 Sep 2013 18:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0v7k7LXiclHW; Sat, 21 Sep 2013 18:53:49 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id A148E11E81F2; Sat, 21 Sep 2013 18:53:49 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cjBXV16vtz3pK; Sat, 21 Sep 2013 21:53:46 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ufzpAEttT5VP; Sat, 21 Sep 2013 21:53:45 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Sat, 21 Sep 2013 21:53:45 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id E881C8009E; Sat, 21 Sep 2013 21:53:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DFA8580018; Sat, 21 Sep 2013 21:53:45 -0400 (EDT) Date: Sat, 21 Sep 2013 21:53:45 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Yoav Nir In-Reply-To: <39C9757C-9E0B-4606-AB6F-5143E913EF95@checkpoint.com> Message-ID: References: <22017290.30831379763068147.JavaMail.www@wwinf3706> <39C9757C-9E0B-4606-AB6F-5143E913EF95@checkpoint.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "" , "" , "" Subject: Re: [dane] [IPsec] Bootstrapping IPSec from DNSSSEC/DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 01:53:55 -0000 On Sat, 21 Sep 2013, Yoav Nir wrote: > I believe this would require a separate document. But I'm not sure that tying it to an IP address is appropriate. IKE implementations work from behind NAT devices and sometimes move around (see MOBIKE), so I think it would be more appropriate to tie the record to any type of ID payload that we have in IKE: IP address and FQDN at least, maybe also KEYID and RFC822 address. > > You might need to profile the IKE IDs used for this. > On Sep 21, 2013, at 2:31 PM, david.lloyd@fsmail.net wrote: >> I am interested in using a variant of DANE to bootstrap my IPSec IKE root certificate trust. Is anyone aware of any work been done in this area? >> >> From my understanding, it looks as though the is no technical issue with using reverse DNS lookup for the IPSec target machine with DNSSec (although this may be a little unreliable on the "real-world" internet), so returning standard DANE entries for the IPSec certificate. Then I would simply use these as part of the standard IPSec certificate validation algorithm. >> >> Looking at similar proposed applications of DANE, such as the draft-ietf-dane-srv, mostly this involves defining an appropriate protocol query name (for example _ipsec.123.123.123.123.in-addr.arpa). >> >> Is this something that would fit into an existing document either from the IKE side or the DANE side? Or would it be worth me creating an more extensive proposal? We (freeswan) tried to use the reverse and failed. It's even worse now with IPv6. If you think of clients running a DNSSEC validating resolver themselves, than having a module in the DNS server that looks up IPSECKEY records in the forward, signed by DNSSEC, and then instructs the IKE daemon to setup a tunnel would require no new standards document. Just ensure you ignore the "gateway" property as it is not secure without the coupling to the reverse tree. Paul From jakob@kirei.se Sun Sep 22 12:05:17 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D02811E8131 for ; Sun, 22 Sep 2013 12:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P05kfhN3zrjz for ; Sun, 22 Sep 2013 12:05:11 -0700 (PDT) Received: from spg.kirei.se (spg.kirei.se [IPv6:2001:67c:394:15::9]) by ietfa.amsl.com (Postfix) with ESMTP id 05F0321F9EAE for ; Sun, 22 Sep 2013 12:04:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kirei.se; s=spg20100524; h=received:content-type:mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to:x-mailer; bh=WKj3mlwLfQojJrxkWhgZCW7u+70jIu8uNsmR0WUbXWU=; b=F2w29WO1/hGCBO1UiQNb5Yi22KJOePsoHSOvIJlpqLglidRSLL5EO2pwGcH8uX9+jM88ExnaZIvXA oNJatT0cUC4F7XMMV/EJEF1wL/GjDHmSzrZEfsMdPZgHI4UDQBc2fq2NZrec4oww861pp9a/TouWqu Mmk6Y22YnmZ0iaww= Received: from mail.kirei.se (unknown [91.206.174.10]) by spg-relay.kirei.se (Halon Mail Gateway) with ESMTPS; Sun, 22 Sep 2013 21:04:56 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jakob Schlyter In-Reply-To: Date: Sun, 22 Sep 2013 21:04:54 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: To: Warren Kumari X-Mailer: Apple Mail (2.1510) Cc: "draft-dukhovni-dane-ops@tools.ietf.org" , "dane@ietf.org list" Subject: Re: [dane] Call for Adoption: draft-dukhovni-dane-ops X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 19:05:22 -0000 I support adoption. jakob From sca@andreasschulze.de Sun Sep 22 13:47:51 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E8021F9D0C for ; Sun, 22 Sep 2013 13:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_20=-0.74, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dyd1TS1EEAQq for ; Sun, 22 Sep 2013 13:47:35 -0700 (PDT) Received: from mout.andreasschulze.de (mout.andreasschulze.de [84.201.4.158]) by ietfa.amsl.com (Postfix) with ESMTP id AAE2421F9385 for ; Sun, 22 Sep 2013 13:47:35 -0700 (PDT) X-Received: line deleted by mout X-Received: line deleted by mout DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andreasschulze.de; s=GzhbMIk; t=1379882409; r=y; bh=g067ssm0daGTvbpxttuDtR9esjvsJF7ryK74YdcGUWU=; h=Date:From:To:Subject:References:In-Reply-To; z=Date:=20Sun,=2022=20Sep=202013=2022:40:07=20+0200|From:=20Andreas =20Schulze=20|To:=20dane@ietf.org|Subject:= 20Re:=20[dane]=20Call=20for=20Adoption:=20draft-dukhovni-dane-ops| References:=20|In -Reply-To:=20; b=Y6qGvC7Vn5HHbSHR9wQS7Mcd09Vv7ACdB4zFHOBZxHsca+v18IQ0xvB76a+pIV8Ss BB8j6ViJWQb3IrDw2HRP+FZyK8YKUh9rMFRFXkTJZUMMs+m/5fVsRzfvwOcZKfhPgy LmSZc22+GarUXiBOag4WxzarQVXadWzP5DjE+wsCusVGoyvlApQHTfcLylvxbaNHcE v3BG47fXl5TnAI8iewdiXd2Fsl1IKyiLXK5E7IZ8WofhtlDpDyANdIS0IHzTOdpiq3 GWfPqJQsiL5cFDfnv7uED4EGVvPkkFrpnrwx+tPb6BP5WwprvcZBbkDvv7eFc9w52J Gr5Ye+/oLTcBAqQv+lsItmIKIpt2gSkmjH+EDjtvkriUYyyyRmvNB++ia+42OC+5k5 6HubhTOCVQcZ+tA/SfnRL8bdtBRYMDgKmCVz4LsktLpG1ZPjM1hFdF0INP39OREdx5 jgwsfd+QUD6X/vegIMx3A8YruQkKyGSa1TrUGN8LPhkIxW5uA9twUYiTccRkxgdmRh ltbGoKYFxLeAv8UaOZ8Tdak/Ego7ULNkxWZCWu2V8WQibecGyNj+UEm+GngiMh6KLk qBRLwWJQdnVg/hw0wDxerG+VDuBhRggYOfeiYcC4uW4MPG7++/aHrzU0MwrqDI2xBj 0Lm3bwN6ks0FJuRvLfeHAWJA= X-Received: line deleted by mout Date: Sun, 22 Sep 2013 22:40:07 +0200 Message-ID: <20130922224007.Horde.6YtYwTg7EyuhPe5cyPI6yA1@horde.andreasschulze.de> From: Andreas Schulze To: dane@ietf.org References: In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.1.4) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [dane] Call for Adoption: draft-dukhovni-dane-ops X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 20:47:51 -0000 Zitat von Warren Kumari : > This starts a Call for Adoption for draft-dukhovni-dane-ops. I run multiple servers using Victors postfix-implementation without any issues. Andreas From pieter.lexis@os3.nl Sun Sep 22 23:26:42 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A19D21F9C05 for ; Sun, 22 Sep 2013 23:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Te-clPbIeBdj for ; Sun, 22 Sep 2013 23:26:41 -0700 (PDT) Received: from mail.serv.os3.nl (mail.serv.os3.nl [IPv6:2001:610:158:960::25]) by ietfa.amsl.com (Postfix) with ESMTP id 065A311E815E for ; Sun, 22 Sep 2013 23:26:39 -0700 (PDT) Received: from smtp.os3.nl (smtp.os3.nl [IPv6:2001:610:158:960::119]) by mail.serv.os3.nl (Postfix) with ESMTP id 5D0FB17B9A6 for ; Mon, 23 Sep 2013 08:30:44 +0200 (CEST) Received: from [192.168.137.117] (unknown [188.207.68.128]) by smtp.os3.nl (Postfix) with ESMTPSA id E019917B979 for ; Mon, 23 Sep 2013 08:30:43 +0200 (CEST) Message-ID: <523FDF19.8040001@os3.nl> Date: Mon, 23 Sep 2013 08:26:33 +0200 From: Pieter Lexis User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: dane@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [dane] Call for Adoption: draft-dukhovni-dane-ops X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 06:26:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/20/2013 01:21 AM, Warren Kumari wrote: > This starts a Call for Adoption for draft-dukhovni-dane-ops. Yes, Viktor is doing awesome work. - -- Pieter -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJSP98VAAoJELPqGO5ebd4jUeQQAJ4epohSF/BK40RZ5qyamTEu mC6ll3TPn58va6gXw3erhr7xDOvoKoxhzbbteEk/Ce4u2XlkVYXj0lqYG87OCCZ7 GYJwxj9EoY3TloGUcZ5w66b25eMRKQqAaRzMgcErtYlUXJR3fbtAb6+5u2U4H6t1 MWdGoIuktz1mAkojtu4XG3xOmwonQrZ/Q6/A+sPOBs0hbRKUlxOGI3WwCPczy3Zh t1iIvRHS2LDm6W5IU5h6ChdONR8tt6OOSg774bXcbKTt6b8IHRPFx0KnGUL1osrj 2ytZ55jbehMjN99Fx4Tk3yFcY82ndTSWc2cwqbUPqfOFJBIDWmnY6dfZgOphuhlC 1R8NOLXd0T73ysqRved+YtXRcFxcmhZkB/aG52ffzREkFlB5tyr5pz4HH4FkSVvP AjjbWEcLbYQs5orx2bRANZmXn/BVJEncTr8YVWodp1APuzyEUDBNfkJeYC+8iYP5 DZJreDf/WkTdwDzVldWW1UnRYxZCRFB4MPI5+wPncJO4fMvkP4IB5JN/IorSsThZ BJSRCt5KKZwZllLuW8kyizk4J6aoZDMnSLeM+eu4FJFqxFt+JDavqm2NgjZQxSqK d/yqHHOqiZu2eYbtTccUyp2mE72jphnaePMjSzCGaUsrnsdI3YPNPjHOYXhglHjW gg/NBLRjqVAk2xDftVwT =v4Ip -----END PGP SIGNATURE----- From ietf@rozanak.com Fri Sep 27 15:13:27 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2897621F8E51; Fri, 27 Sep 2013 15:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8vjCJ-lSXDH; Fri, 27 Sep 2013 15:13:22 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id F1A4E21F9808; Fri, 27 Sep 2013 15:13:19 -0700 (PDT) Received: from kopoli (g225191041.adsl.alicedsl.de [92.225.191.41]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MQzYs-1VHXqn3j3O-00U5Ui; Fri, 27 Sep 2013 18:13:18 -0400 From: "Hosnieh Rafiee" To: "perpass" , Date: Sat, 28 Sep 2013 00:13:10 +0200 Message-ID: <002601cebbce$c37c3f80$4a74be80$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac66GAmkrg604EBOQj6E9T/FIDhOTg== Content-Language: en-us X-Provags-ID: V02:K0:qHdZjREDdYsBxNOj/2+4SNOj6BexqynEi7n9Cn6tbfT MYuQCJe6abQcytQphj0p7kpwJywBjB9AIRS2DQXNxZNEFDOESi rlWAZldg+mQn4fC+Ebif+WKUp9Zg4HH0PaIrShzOfBfm90PKuq WVb29YgKgcw/hOtOpAaRg0zBDSkQsKxwIwdBswV3iE8x5qfdLE VW8cN4rve8tgNGitmcjqACzhctR07BwocRhSnax9BPMRttm+rj Mc3r8iaqi8C95s8tppNfZEgoJrOAP34urGzBB0NMBPTMP4vdp8 3CGY6yKE5YyWhqdl+dpcw/Hmhd88o3Z4/bLGCAv0Vo/vX+00ZW nnD4IKh63iE96pJgwELk= Subject: [dane] Reviewers needed - Secure DNS authentication X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 22:13:27 -0000 Hello, I am looking for reviewers to review the http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig draft. It deals with the use of CGA (RFC 3972) or SSAS for authentication purposes during various types of scenarios. This is truly possible when the authentication is based on the source IP address. Everything in this authentication is done "on the fly" and only once is there a need to configure the Servers. Advantages: - If the shared secret is compromised (which is true in TSIG, you won't need to repeat the process of re-sharing the shared secret among the many hosts that used the compromised shared secret) - If for any reason the IP address of any nodes involved in authentication is changed, then the other nodes will still be able to verify that it is the same node - It is both easier and preferable to use this approach to prove the address ownership while at the same time performing source IP address authentication. - The nodes don't need to go through the chain of trusts because the magic of CGA or SSAS works well. This means that if the other nodes are aware of one node's real IP address then that is all the information the other nodes need to identify this node. No matter how your node changes its IP address. This draft explains how to easily handle this situation, automatically, without the need for human intervention. I am sure you will find it interesting. The different scenarios that are considered are: - Authentication during FQDN - Authentication during zone transfer - Authentication of the resolvers in stub resolvers - Authentication of root DNS servers to recursive DNS servers We also considered the scenario where the server doesn't support CGA or SeND. The interesting thing about this draft is that you can use a CGA script generator that I will provide and make available to everybody. Then just manually set the IP address for the node that wants to use CGA-TSIG. The CGA-TSIG implementation will thereafter processes the handling for all the CGA parameters. This scenario is good for the future of the Internet where IPv6 is used. I guess many DNS servers now support IPv6 as well as IPv4. I am looking forward to receiving your comments. Thank you, Hosnieh P.S. So if you'll review mine i'll review yours.. Deal??? :-) From warren@kumari.net Fri Sep 27 18:03:55 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC95821F9A31; Fri, 27 Sep 2013 18:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YICY9RFkGsJ6; Fri, 27 Sep 2013 18:03:51 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC4621F90DC; Fri, 27 Sep 2013 18:03:50 -0700 (PDT) Received: from [10.243.40.142] (mobile-198-228-224-005.mycingular.net [198.228.224.5]) by vimes.kumari.net (Postfix) with ESMTPSA id EFA381B400DE; Fri, 27 Sep 2013 21:03:48 -0400 (EDT) References: <002601cebbce$c37c3f80$4a74be80$@rozanak.com> In-Reply-To: <002601cebbce$c37c3f80$4a74be80$@rozanak.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (11A465) From: Warren Kumari Date: Fri, 27 Sep 2013 21:03:46 -0400 To: Hosnieh Rafiee Cc: perpass , "" Subject: Re: [dane] Reviewers needed - Secure DNS authentication X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 01:03:55 -0000 I'm sorry, but this is not related to DANE (nor was it last time you came sh= opping around). I (of course) have no problem with folk reviewing it, just making it clear t= hat it isn't a DANE thing... W Warren Kumari ------ Please excuse typing, etc -- This was sent from a device with a tiny keyboar= d. > On Sep 27, 2013, at 6:13 PM, "Hosnieh Rafiee" wrote: >=20 > Hello, >=20 > I am looking for reviewers to review the > http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig draft. It deals > with the use of CGA (RFC 3972) or SSAS for authentication purposes during > various types of scenarios. This is truly possible when the authentication= > is based on the source IP address. Everything in this authentication is do= ne > "on the fly" and only once is there a need to configure the Servers. > Advantages: > - If the shared secret is compromised (which is true in TSIG, you won't ne= ed > to repeat the process of re-sharing the shared secret among the many hosts= > that used the compromised shared secret) > - If for any reason the IP address of any nodes involved in authentication= > is changed, then the other nodes will still be able to verify that it is > the same node > - It is both easier and preferable to use this approach to prove the addre= ss > ownership while at the same time performing source IP address > authentication. > - The nodes don't need to go through the chain of trusts because the magi= c > of CGA or SSAS works well. This means that if the other nodes are aware of= > one node's real IP address then that is all the information the other node= s > need to identify this node. No matter how your node changes its IP addres= s. > This draft explains how to easily handle this situation, automatically, > without the need for human intervention.=20 > I am sure you will find it interesting.=20 >=20 > The different scenarios that are considered are: > - Authentication during FQDN > - Authentication during zone transfer > - Authentication of the resolvers in stub resolvers > - Authentication of root DNS servers to recursive DNS servers >=20 > We also considered the scenario where the server doesn't support CGA or > SeND. The interesting thing about this draft is that you can use a CGA > script generator that I will provide and make available to everybody. Then= > just manually set the IP address for the node that wants to use CGA-TSIG. > The CGA-TSIG implementation will thereafter processes the handling for al= l > the CGA parameters.=20 >=20 > This scenario is good for the future of the Internet where IPv6 is used. I= > guess many DNS servers now support IPv6 as well as IPv4.=20 >=20 > I am looking forward to receiving your comments.=20 >=20 > Thank you, > Hosnieh > P.S. So if you'll review mine i'll review yours.. Deal??? :-) >=20 > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane >=20 From ietf@rozanak.com Sat Sep 28 06:47:55 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C12821E80DD; Sat, 28 Sep 2013 06:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ht71Z+efPJi7; Sat, 28 Sep 2013 06:47:49 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id B83C221F9D42; Sat, 28 Sep 2013 06:47:46 -0700 (PDT) Received: from kopoli (g231251251.adsl.alicedsl.de [92.231.251.251]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Mgbk7-1VBFjJ3I0d-00NzZw; Sat, 28 Sep 2013 09:47:44 -0400 From: "Hosnieh Rafiee" To: "'Warren Kumari'" References: <002601cebbce$c37c3f80$4a74be80$@rozanak.com> In-Reply-To: Date: Sat, 28 Sep 2013 15:47:32 +0200 Message-ID: <000601cebc51$4caa5fd0$e5ff1f70$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHhNdW1NOP0zz8kGUAEoaOrvgBu5wHF0IV3mafKp4A= Content-Language: en-us X-Provags-ID: V02:K0:adzGBBerLOIAiMS2t+YSYP7Xyy5KDdl0EHylvRxh1/a O2czigbpA9xXm7cyEN5puJBOUtYr0n22iAz9m1x2dV7hZ5lQiG 1hfM0rrzpdLbieccJwFEl2zWhhf8r8SJ1aYSvLlADGPqnsFik7 YZqUlT4Jzfc+0rKDVfWDPnVU7hXnzzsccPX7IBWmdilfbzuz4o mEPEY9s+ixgw7g5V2cekZoGD3eXn/tw92UgbNOr/248trHYiGv hbO67Of6hj4a2BDWaR2pM/c8IXNE4RiNrgsYxVQFqJdClUZV+H OubqXbexVShxW61vSRYx8cMxJnNaxC2AYF+MeoPU8VnZW0zvOC O50Z+2+54vG35fuAqW+s= Cc: Andrew Sullivan , 'perpass' , dane@ietf.org Subject: Re: [dane] Reviewers needed - Secure DNS authentication X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 13:47:55 -0000 > I (of course) have no problem with folk reviewing it, just making it clear that it > isn't a DANE thing... You're right it is individual submission which has a document shepherd. I asked Andrew to be a document shepherd for this work. But we are trying to hunt reviewers :-) . Some DNS experts have already reviewed this document and the document improved a lot since the first version. We are now looking for more reviewers (security expert, DNS expert, etc) for technical and organization comments. Any volunteer reviewers that give us more useful comments so that we can proceed with it. The reviewers can send their comments directly to I and Andrew or to the list. Thanks, Hosnieh From david.lloyd@fsmail.net Sun Sep 29 13:23:17 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD8011E8134 for ; Sun, 29 Sep 2013 13:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[BAYES_50=0.001, SARE_FREE_WEBM_NetFs=0.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3kSnO8BEL3M for ; Sun, 29 Sep 2013 13:23:12 -0700 (PDT) Received: from smtpout.wanadoo.co.uk (smtpout4.wanadoo.co.uk [80.12.242.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9887F21E80B7 for ; Sun, 29 Sep 2013 13:23:11 -0700 (PDT) Received: from wwinf3715 ([10.232.27.59]) by mwinf5d59 with ME id X8P81m00t1GX7wy038P8Fk; Sun, 29 Sep 2013 22:23:08 +0200 Date: Sun, 29 Sep 2013 22:23:08 +0200 From: david.lloyd@fsmail.net To: ipsec@ietf.org, dane@ietf.org Message-ID: <7039763.53681380486188849.JavaMail.www@wwinf3715> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [86.26.3.116] X-Wum-Nature: EMAIL-NATURE X-WUM-FROM: |~| X-WUM-TO: |~||~| X-WUM-REPLYTO: |~| Subject: [dane] Bootstrapping IPSec from DNSSSEC/DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: david.lloyd@fsmail.net List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Sep 2013 20:23:17 -0000 Hi, Thanks for the various responses. I have also been asked for a little clarification on what I am trying to achieve, so I'll give a quick overview. There's not much to it... Basically, we have three independent groups who have certificate-based IPSec (on IPv6), and now they'd like occasionally to connect to each other. The obvious solution is to cross-sign certificates, but we have also recently implemented DNSSEC, so I was wondering if there was a better/another way. Or maybe: I have a shiny new hammer called DNSSEC, and a lot of things are starting to look like nails. In terms of getting IPSec based off DNSSEC, the two RFCs 4025 and 4322 actually do pretty much what I want (plus or minus that it'll look very different to the way I am configuring TLS DANE). I am going to see if I can get those to work. For the other things that were talked about: Mobile devices and NATs - It is true that reverse lookup is inappropriate for these scenarios, but ultimately this is just a rejig of the problem that the incoming ipaddress is not particularly useful in these scenarios. If a server wishes to verify such connecting clients, it'll have to choose something else as an identifier (and thus it falls back into the traditional CA/Kerebros setup) Reverse DNS being poorly supported by iSPs - To be honest, this is less of a problem for me as I only have an internal deployment, so I can do what I like (in-addr.arpa is ultimately just a convention, anyone could run a reverse DNS system that actually works properly). Most of my ip addresses are not routable from the public internet anyway. It did lead me to the somewhat more philosophical question of what it means to "own" an ipaddress if I can't associate my public keys with a secure central registry... So I think that the answer is that I can do this with existing technology, with some basic restrictions in that I'll need to be running my own reverse DNS lookup for my deployment - which seems entirely sensible as I want to have control over which ip addresses "exist" in my environment. Thanks! DDD From paul.hoffman@vpnc.org Sun Sep 29 19:16:47 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEA621F9D2C for ; Sun, 29 Sep 2013 19:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gc4IMYCatGbk for ; Sun, 29 Sep 2013 19:16:46 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9237C21F9D23 for ; Sun, 29 Sep 2013 19:16:46 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8U2GhdO069372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 29 Sep 2013 19:16:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: <20130920021124.GE29796@mournblade.imrryr.org> Date: Sun, 29 Sep 2013 19:16:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4D79E741-F559-4D6D-9AB0-E7B35A62C783@vpnc.org> References: <20130919201216.14866.61161.idtracker@ietfa.amsl.com> <20130919221035.GC29796@mournblade.imrryr.org> <20130920021124.GE29796@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1510) Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 02:16:47 -0000 On Sep 19, 2013, at 7:11 PM, Viktor Dukhovni = wrote: > On Thu, Sep 19, 2013 at 10:10:35PM +0000, Viktor Dukhovni wrote: >=20 >> Agreed on PKIX-TA vs. PKIX-CA. >=20 > On second thought, I am not so sure, the CA constraint with usage > 0, is NOT a trust-anchor, the trust-anchor is still the PKIX root CA. >=20 > This usage requires the presence of a given CA (root or intermediate) > in the chain, but does not promote that CA to a trust anchor (as > with usage 2). So perhaps the original PKIX-CA is in fact better. PKIX is not clear if there are PKIX TAs that are not CAs, as we = discussed extensively earlier in this WG. We do not need to open those = wounds with molten salt. Either term is probably technically accurate, = and we won't know for sure. The rest of this document seems fine, and is a valuable addition to the = DANE world. --Paul Hoffman= From paul@cypherpunks.ca Mon Sep 30 07:52:25 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13EB21F9C33; Mon, 30 Sep 2013 07:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJln6KUnqpqc; Mon, 30 Sep 2013 07:52:19 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id B7F7621F9AF0; Mon, 30 Sep 2013 07:52:18 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cpRQp2r58z9Mv; Mon, 30 Sep 2013 10:52:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id V4tdxpOL2kMY; Mon, 30 Sep 2013 10:52:01 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Mon, 30 Sep 2013 10:52:00 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 8EF0E805F2; Mon, 30 Sep 2013 10:51:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 86594805F1; Mon, 30 Sep 2013 10:51:59 -0400 (EDT) Date: Mon, 30 Sep 2013 10:51:59 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: david.lloyd@fsmail.net In-Reply-To: <7039763.53681380486188849.JavaMail.www@wwinf3715> Message-ID: References: <7039763.53681380486188849.JavaMail.www@wwinf3715> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "ipsec@ietf.org WG" , dane WG list Subject: Re: [dane] [IPsec] Bootstrapping IPSec from DNSSSEC/DANE X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 14:52:25 -0000 On Sun, 29 Sep 2013, david.lloyd@fsmail.net wrote: > Thanks for the various responses. I have also been asked for a little clarification on what I am trying to achieve, so I'll give a quick overview. > > There's not much to it... Basically, we have three independent groups who have certificate-based IPSec (on IPv6), and now they'd like occasionally to connect to each other. The obvious solution is to cross-sign certificates, but we have also recently implemented DNSSEC, so I was wondering if there was a better/another way. Or maybe: I have a shiny new hammer called DNSSEC, and a lot of things are starting to look like nails. > > In terms of getting IPSec based off DNSSEC, the two RFCs 4025 and 4322 actually do pretty much what I want (plus or minus that it'll look very different to the way I am configuring TLS DANE). I am going to see if I can get those to work. We have been working on re-doing IPsec OE (which can use DANE/DNSSEC) using IKEv2. We will be writing up our findings in a new draft and implement this in libreswan. The core functionality is not hard. The problem is in cornercases and trying not to get stuck in too many of them like the BTNS work did. > For the other things that were talked about: > > Mobile devices and NATs - It is true that reverse lookup is inappropriate for these scenarios, but ultimately this is just a rejig of the problem that the incoming ipaddress is not particularly useful in these scenarios. If a server wishes to verify such connecting clients, it'll have to choose something else as an identifier (and thus it falls back into the traditional CA/Kerebros setup) Forget the reverse. You either use the forward lookup with DNSSEC using a locally running DNSSEC resolver or you if you don't find anything, you try an anonymous (MITMable) IPsec directly. > > So I think that the answer is that I can do this with existing technology, with some basic restrictions in that I'll need to be running my own reverse DNS lookup for my deployment - which seems entirely sensible as I want to have control over which ip addresses "exist" in my environment. Yes. the problems are mostly in the local implementation. How to deal with NAT and overlapping IP addresses. How to ensure there is no malicious NAT-T pre-NAT IP attempts at traffic stealing (eg 8.8.8.8) How (or if) to present the difference of "anonymous IPsec" versus "one or two sided authenticated IPsec" to the user. What to do when the roles of initiator/responder change and the connection was only authenticated by the original initiator. I hope to have a rough draft and implementation ready in Vancouver, Paul From warren@kumari.net Mon Sep 30 11:42:46 2013 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B8921F9AD8 for ; Mon, 30 Sep 2013 11:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EWM2yX6GtPa for ; Mon, 30 Sep 2013 11:42:42 -0700 (PDT) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id C042221F9DC9 for ; Mon, 30 Sep 2013 11:42:38 -0700 (PDT) Received: from [192.168.1.153] (unknown [66.84.81.70]) by vimes.kumari.net (Postfix) with ESMTPSA id 5DD0A1B400DE; Mon, 30 Sep 2013 14:42:31 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Warren Kumari In-Reply-To: Date: Mon, 30 Sep 2013 14:42:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <522A57C8.8040702@stpeter.im> <20130919202330.GB29796@mournblade.imrryr.org> To: "dane@ietf.org list" , Tony Finch X-Mailer: Apple Mail (2.1510) Subject: Re: [dane] draft-ietf-dane-srv X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2013 18:42:47 -0000 On Sep 19, 2013, at 7:07 PM, Warren Kumari wrote: >=20 > On Sep 19, 2013, at 4:23 PM, Viktor Dukhovni = wrote: >=20 >> On Thu, Sep 19, 2013 at 06:30:59PM +0100, Tony Finch wrote: >>=20 >>>> It seems that draft-ietf-dane-srv has expired. Does the document >>>> editor (and, more important, the WG) still have an interest in = moving >>>> this forward? >>>=20 >>> Yes I would like to. I have been busy at work recently, but I will = try to >>> find the time to put out an update. >>=20 >> Welcome back. >=20 > +1.=20 >=20 >=20 >> When you get a chance, please also take a look at >> the new OPS and SMTP drafts Wes and I put together. Let us know >> if you have any comments, and of course we should try to avoid >> conflicts between these and the SRV draft. >>=20 >> For example, the new SMTP draft specifies that SMTP servers SHOULD >> NOT publish TLSA RRs with usages 0/1, both for MTA to MTA traffic >> and for port 587 when MUAs discover submission hosts via SRV records. >> So the SRV draft should not exclude such application-specific >> specifications. >>=20 >=20 > During the Berlin meeting it was proposed that draft-ietf-dane-smtp be = merged with draft-dukhovni-smtp-opportunistic-tls. >=20 > There was overwhelming support in favor of doing so -- I'm assuming = y'all are fine with this? Dear Tony, Can you please let us know if you have the time (and inclination) to = continue working on a combined draft-ietf-dane-smtp / = draft-dukhovni-smtp-opportunistic-tls document with yourself and Viktor = as co-authors? We understand that you are really busy, and are fine if = you simply do not have the time at the moment=85. If we do not get a response by Monday October 7th (one week) we will = have to appoint new author(s). W [ Apologies for doing this on-list.]=20 >=20 > Also, while catching up=85 >=20 > There was a proposal to adopt draft-dukhovni-dane-ops-01.=20 > There was overwhelming support for doing so, and no objections. I will = initial an onlist call for adoption inna bit=85 >=20 > W >=20 >> = https://tools.ietf.org/html/draft-dukhovni-smtp-opportunistic-tls-01 >> https://tools.ietf.org/html/draft-dukhovni-dane-ops-01 >>=20 >> with work-in-progress snapshots at: >>=20 >> http://vdukhovni.github.io/ietf/ >>=20 >> --=20 >> Viktor. >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >>=20 >=20 > --=20 > Do not meddle in the affairs of wizards, for they are subtle and quick = to anger. =20 > -- J.R.R. Tolkien >=20 >=20 -- "Working the ICANN process is like being nibbled to death by ducks, it takes forever, it doesn't make sense, and in the end we're still dead = in the water."=20 -- Tom Galvin, VeriSign's vice president for government relations.