From nobody Sun Jun 1 19:04:32 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389A51A0149 for ; Sun, 1 Jun 2014 19:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.151 X-Spam-Level: X-Spam-Status: No, score=-6.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AT7QSvql58VB for ; Sun, 1 Jun 2014 19:04:27 -0700 (PDT) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CB9C1A0141 for ; Sun, 1 Jun 2014 19:04:26 -0700 (PDT) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sun, 1 Jun 2014 22:04:20 -0400 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Sun, 1 Jun 2014 22:04:17 -0400 Received: from b01cxnp22033.gho.pok.ibm.com (b01cxnp22033.gho.pok.ibm.com [9.57.198.23]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 574806E801C for ; Sun, 1 Jun 2014 22:04:07 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by b01cxnp22033.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s5224FjZ8651246 for ; Mon, 2 Jun 2014 02:04:15 GMT Received: from d01av02.pok.ibm.com (localhost [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s5224FSR029036 for ; Sun, 1 Jun 2014 22:04:15 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av02.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s5224FMv029029; Sun, 1 Jun 2014 22:04:15 -0400 In-Reply-To: <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> References: <201405290805.s4T85HBT008757@new.toad.com> <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> To: Paul Hoffman MIME-Version: 1.0 X-KeepSent: B1999EAD:836E27A5-85257CE8:0067D557; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0.1 October 14, 2013 From: Tom Gindin Message-ID: Date: Sun, 1 Jun 2014 22:04:13 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 9.0.1FP1HF1|April 25, 2014) at 06/01/2014 22:04:15, Serialize complete at 06/01/2014 22:04:15 Content-Type: multipart/alternative; boundary="=_alternative 000B5ECB85257CEB_=" X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14060202-0320-0000-0000-0000036E3C69 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/OvDX5uNfamfsM3OyqzRDVR50SVA Cc: dane@ietf.org Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jun 2014 02:04:30 -0000 This is a multipart message in MIME format. --=_alternative 000B5ECB85257CEB_= Content-Type: text/plain; charset="US-ASCII" Paul: On a technical, or at least quasi-technical point, doesn't usage 3 say that it must match the "end-entity certificate given by the server in TLS"? That suggests to me that TLSA might need DANE to support another usage (perhaps 4), which matches a bare public key as given in RFC 7520. This is my first post to DANE, so please forgive me if I'm missing some of the history. DANE surely should accomodate TLSA, but changing statements about extensibility in the existing document to their opposites does not seem like the best way to do that. A revision to 6698 should presumably leave the current last sentence of 2.1.1 accurate as it applies to usages 0-3, to avoid breaking any existing code that might rely on it. So my proposed certificate usage values are: 0 Issuer 1 Server Certificate - to be fully validated 2 Trust Anchor 3 Server Certificate - may be self-signed, no chain validation 4 Public Key Certificate usage 4 is used to specify a certificate, or the public key of such a certificate, that MUST match the public key given by the server in TLS or TLSA. Unlike certificate usage 3, this usage implies that the server supplies a key with neither validity dates nor name in the session negotiation. Tom Gindin, CISSP P.S. The opinions above are mine, and not necessarily those of my employer. From: Paul Hoffman To: John Gilmore Cc: dane@ietf.org Date: 05/29/2014 10:01 AM Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys Sent by: "dane" On May 29, 2014, at 1:05 AM, John Gilmore wrote: > I remember fighting this fight in the DANE WG, and the result was > something along the lines of "We'll narrow the RFC now, and then > if-and-when raw public keys are approved by the TLS WG, then we'll > amend it to include them." Yep. That is still the plan. > Well, the time has come. Raw public keys > are approved by the TLS WG. The trouble is that nobody has bothered > to amend the TLSA RFC, so the new draft RFC tells people "just use > DANE", but the DANE TLSA RFC says, "No you can't". Anyone could have started the process for an update to 6689 to reflect this. They haven't yet. > I propose to add some text to the draft RFC 7250 that extends RFC 6698 > by defining how raw public keys are stored in TLSA records. That is a horrible abuse of the RFC publication process. That is, instead of you asking for IETF review of your idea, you are trying to slip in a significant technical change with no community review. > My coauthors seem to prefer that we just ignore the entire issue, > issue RFC 7250, and ignore the conflict between the two. What conflict? DANE is clearly defined. If you want to update the definition (and many of us would support that), write the one-page Internet Draft to do so. > As someone > who learned most of what I know about protocols (and the Internet) > from reading Saint Jon Postel's clearly written RFCs, I would hate to > inflict that on future readers. We should not release documents that > contain deliberate incompatabilities. And you are not. > We think RFC 7250 is ready to go except for this remaining issue. It > has been approved by the TLS WG, the IESG, the RFC Editor, and all the > co-authors but me. > > Here's my proposed wording change for RFC 7520. Improvements welcome. > Start from this version: > > https://www.rfc-editor.org/authors/rfc7250.txt > > Section 4.4. > OLD (entire section): > When the TLS server has specified RawPublicKey as the > server_certificate_type, authentication of the TLS server to the TLS > client is supported only through authentication of the received > client SubjectPublicKeyInfo via an out-of-band method. > > NEW (entire section): > When the TLS server has specified RawPublicKey as the > server_certificate_type, authentication of the TLS server to the TLS > client is supported only through authentication of the received > client SubjectPublicKeyInfo via an out-of-band method. > > In order to support out-of-band authentication via DANE [RFC6698], > this document extends the DANE TLSA record definition to allow such > records to describe raw public keys as well as PKIX [RFC5280] > certificates. This extension does not define any new field values; > it merely defines how existing fields are processed when being > matched to raw public keys provided by TLS servers. > > A raw public key is represented in a TLSA record by specifying a > certificate usage of 3 (domain-provided), a selector of 1 > (SubjectPublicKeyInfo), and a matching type of 0. The > SubjectPublicKeyInfo that holds the public key is placed in the > certificate association data. Matching types other than 0 may also > be used, by placing the corresponding hash value into the > certificate association data. > > DANE [RFC6698] section 1.3 is extended to say: > > This document only applies to raw public keys and to PKIX > [RFC5280] certificates, not certificates of other formats. > > DANE section 2.1.1 is extended to say: > > The certificate usages 0, 1 and 2 defined in this document > explicitly only apply to PKIX-formatted certificates in DER > encoding [X.690]. If TLS allows other formats later, or if > extensions to this RRtype are made that accept other formats for > certificates, those certificates will need their own certificate > usage values. > > In DANE section 2.1.1, in addition to the definition of certificate > usage 3 with TLS servers that use PKIX certificates, certificate > usage 3 may also be used with TLS servers that use raw public keys: > > 3 -- Certificate usage 3 is also used to specify a raw public key > that MUST match the raw public key presented by the server in > TLS. When the TLS server provides a raw public key, there is no > PKIX certificate and no PKIX validation is done; the TLS > server's raw public key MUST match the raw public key provided in > the TLSA record. This certificate usage is sometimes referred > to as "domain-issued" because it allows a domain administrator > to directly certify a domain's public keys. > > I believe that this wording reflects the up-to-now tacit consensus on > how the DANE WG expects TLS raw public keys to be represented and > processed in TLSA records. In the absence of significant dissent or > further improvements, I propose to provide the above updates to the > RFC Editor and release the new RFC. As co-author of RFC 6689, I fully disagree. The correct way to update RFC 6698 is with a new RFC that has community review. --Paul Hoffman _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane --=_alternative 000B5ECB85257CEB_= Content-Type: text/html; charset="US-ASCII" Paul:

        On a technical, or at least quasi-technical point, doesn't usage 3 say that it must match the "end-entity certificate given by the server in TLS"?  That suggests to me that TLSA might need DANE to support another usage (perhaps 4), which matches a bare public key as given in RFC 7520.  This is my first post to DANE, so please forgive me if I'm missing some of the history.
        DANE surely should accomodate TLSA, but changing statements about extensibility in the existing document to their opposites does not seem like the best way to do that.  A revision to 6698 should presumably leave the current last sentence of 2.1.1 accurate as it applies to usages 0-3, to avoid breaking any existing code that might rely on it.
        So my proposed certificate usage values are:
0        Issuer
1        Server Certificate - to be fully validated
2        Trust Anchor
3        Server Certificate - may be self-signed, no chain validation
4        Public Key
       Certificate usage 4 is used to specify a certificate, or the public key of such a certificate, that MUST match the public key given by the server in TLS or TLSA.  Unlike  certificate usage 3, this usage implies that the server supplies a key with neither validity dates nor name in the session negotiation.

Tom Gindin, CISSP
P.S.        The opinions above are mine, and not necessarily those of my employer.



From:        Paul Hoffman <paul.hoffman@vpnc.org>
To:        John Gilmore <gnu@toad.com>
Cc:        dane@ietf.org
Date:        05/29/2014 10:01 AM
Subject:        Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys
Sent by:        "dane" <dane-bounces@ietf.org>



On May 29, 2014, at 1:05 AM, John Gilmore <gnu@toad.com> wrote:

> I remember fighting this fight in the DANE WG, and the result was
> something along the lines of "We'll narrow the RFC now, and then
> if-and-when raw public keys are approved by the TLS WG, then we'll
> amend it to include them."  

Yep. That is still the plan.

> Well, the time has come.  Raw public keys
> are approved by the TLS WG.  The trouble is that nobody has bothered
> to amend the TLSA RFC, so the new draft RFC tells people "just use
> DANE", but the DANE TLSA RFC says, "No you can't".

Anyone could have started the process for an update to 6689 to reflect this. They haven't yet.

> I propose to add some text to the draft RFC 7250 that extends RFC 6698
> by defining how raw public keys are stored in TLSA records.

That is a horrible abuse of the RFC publication process. That is, instead of you asking for IETF review of your idea, you are trying to slip in a significant technical change with no community review.

> My coauthors seem to prefer that we just ignore the entire issue,
> issue RFC 7250, and ignore the conflict between the two.  

What conflict? DANE is clearly defined. If you want to update the definition (and many of us would support that), write the one-page Internet Draft to do so.

> As someone
> who learned most of what I know about protocols (and the Internet)
> from reading Saint Jon Postel's clearly written RFCs, I would hate to
> inflict that on future readers.  We should not release documents that
> contain deliberate incompatabilities.

And you are not.

> We think RFC 7250 is ready to go except for this remaining issue.  It
> has been approved by the TLS WG, the IESG, the RFC Editor, and all the
> co-authors but me.
>
> Here's my proposed wording change for RFC 7520.  Improvements welcome.
> Start from this version:
>
>  https://www.rfc-editor.org/authors/rfc7250.txt
>
> Section 4.4.
> OLD (entire section):
>   When the TLS server has specified RawPublicKey as the
>   server_certificate_type, authentication of the TLS server to the TLS
>   client is supported only through authentication of the received
>   client SubjectPublicKeyInfo via an out-of-band method.
>
> NEW (entire section):
>   When the TLS server has specified RawPublicKey as the
>   server_certificate_type, authentication of the TLS server to the TLS
>   client is supported only through authentication of the received
>   client SubjectPublicKeyInfo via an out-of-band method.
>
>   In order to support out-of-band authentication via DANE [RFC6698],
>   this document extends the DANE TLSA record definition to allow such
>   records to describe raw public keys as well as PKIX [RFC5280]
>   certificates.  This extension does not define any new field values;
>   it merely defines how existing fields are processed when being
>   matched to raw public keys provided by TLS servers.
>
>   A raw public key is represented in a TLSA record by specifying a
>   certificate usage of 3 (domain-provided), a selector of 1
>   (SubjectPublicKeyInfo), and a matching type of 0.  The
>   SubjectPublicKeyInfo that holds the public key is placed in the
>   certificate association data.  Matching types other than 0 may also
>   be used, by placing the corresponding hash value into the
>   certificate association data.
>
>   DANE [RFC6698] section 1.3 is extended to say:
>
>      This document only applies to raw public keys and to PKIX
>      [RFC5280] certificates, not certificates of other formats.
>
>   DANE section 2.1.1 is extended to say:
>
>      The certificate usages 0, 1 and 2 defined in this document
>      explicitly only apply to PKIX-formatted certificates in DER
>      encoding [X.690].  If TLS allows other formats later, or if
>      extensions to this RRtype are made that accept other formats for
>      certificates, those certificates will need their own certificate
>      usage values.
>
>   In DANE section 2.1.1, in addition to the definition of certificate
>   usage 3 with TLS servers that use PKIX certificates, certificate
>   usage 3 may also be used with TLS servers that use raw public keys:
>
>      3 -- Certificate usage 3 is also used to specify a raw public key
>      that MUST match the raw public key presented by the server in
>      TLS.  When the TLS server provides a raw public key, there is no
>      PKIX certificate and no PKIX validation is done; the TLS
>      server's raw public key MUST match the raw public key provided in
>      the TLSA record.  This certificate usage is sometimes referred
>      to as "domain-issued" because it allows a domain administrator
>      to directly certify a domain's public keys.
>
> I believe that this wording reflects the up-to-now tacit consensus on
> how the DANE WG expects TLS raw public keys to be represented and
> processed in TLSA records.  In the absence of significant dissent or
> further improvements, I propose to provide the above updates to the
> RFC Editor and release the new RFC.

As co-author of RFC 6689, I fully disagree. The correct way to update RFC 6698 is with a new RFC that has community review.

--Paul Hoffman
_______________________________________________
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane
--=_alternative 000B5ECB85257CEB_=-- From nobody Sun Jun 1 19:27:44 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6671A0281 for ; Sun, 1 Jun 2014 19:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvrYYrXhSvao for ; Sun, 1 Jun 2014 19:27:39 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 973F91A0155 for ; Sun, 1 Jun 2014 19:27:39 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 16E202AB19D; Mon, 2 Jun 2014 02:27:33 +0000 (UTC) Date: Mon, 2 Jun 2014 02:27:33 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140602022733.GK27883@mournblade.imrryr.org> References: <201405290805.s4T85HBT008757@new.toad.com> <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/8HSpAdp0Q849X-i-bEpcO_0rIqU Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jun 2014 02:27:41 -0000 On Sun, Jun 01, 2014 at 10:04:13PM -0400, Tom Gindin wrote: > On a technical, or at least quasi-technical point, doesn't usage 3 say > that it must match the "end-entity certificate given by the server in > TLS"? Usage DANE-EE(3) with selector SPKI(1) matches the subject public key info of the peer. While as specified in 6698 this SPKI is expected to be adorned in X.509 finery, it is a natural extension to allow the same association to apply to bare public keys. There is simply no need for a new certificate usage here (one for which selector 0 would make no sense). Indeed it would force server operators to needlessly publish the SPKI digest twice: example. IN TLSA 3 1 1 {blob} example. IN TLSA 4 1 1 {blob} for no good reason. > Certificate usage 4 is used to specify a certificate, or the > public key of such a certificate, that MUST match the public key given by > the server in TLS or TLSA. Unlike certificate usage 3, this usage > implies that the server supplies a key with neither validity dates nor > name in the session negotiation. Those qualifications already apply to usage 3 (ops draft document which specifies this to be published soon), with SPKI(1), DANE-EE(3) is already a bare key usage, just sometimes embedded in an X.509 cert. There is no need for a usage 4 (yet), at least not for this use-case. -- Viktor. From nobody Mon Jun 2 07:14:44 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC531A033E for ; Mon, 2 Jun 2014 07:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ck7EtCSr3hA6 for ; Mon, 2 Jun 2014 07:14:39 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id DF4111A033C for ; Mon, 2 Jun 2014 07:14:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E18F2BE77; Mon, 2 Jun 2014 15:14:32 +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 bGe2S4wGhFgi; Mon, 2 Jun 2014 15:14:31 +0100 (IST) Received: from [10.87.48.12] (unknown [86.46.20.65]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D12F3BE4C; Mon, 2 Jun 2014 15:14:31 +0100 (IST) Message-ID: <538C86C7.8000805@cs.tcd.ie> Date: Mon, 02 Jun 2014 15:14:31 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dane@ietf.org References: <201405290805.s4T85HBT008757@new.toad.com> <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> <20140602022733.GK27883@mournblade.imrryr.org> In-Reply-To: <20140602022733.GK27883@mournblade.imrryr.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/CZcBJnP-sd3lSzAvTtuKFuvGAvc Cc: "dane-chairs@tools.ietf.org" Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jun 2014 14:14:42 -0000 Folks, Can we try get this one settled soon, at least in terms of any changes to draft-ietf-tls-oob? The core WG have been waiting on that for quite a while as its a normative dependency for CoAP. (So, dane WG chairs - if you could propose a consensus call for the action to take that'd be great and we can move on.) Cheers, S. From nobody Mon Jun 2 07:52:27 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F9E1A0331 for ; Mon, 2 Jun 2014 07:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdCou88xvDGx for ; Mon, 2 Jun 2014 07:52:22 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02A771A0223 for ; Mon, 2 Jun 2014 07:52:21 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 139F42AB160; Mon, 2 Jun 2014 14:52:15 +0000 (UTC) Date: Mon, 2 Jun 2014 14:52:15 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140602145215.GP27883@mournblade.imrryr.org> References: <201405290805.s4T85HBT008757@new.toad.com> <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> <20140602022733.GK27883@mournblade.imrryr.org> <538C86C7.8000805@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <538C86C7.8000805@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/nVTS1pTjmCF4sR1DYsqqee0XHro Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jun 2014 14:52:23 -0000 On Mon, Jun 02, 2014 at 03:14:31PM +0100, Stephen Farrell wrote: > Can we try get this one settled soon, at least in terms of > any changes to draft-ietf-tls-oob? > > The core WG have been waiting on that for quite a while as > its a normative dependency for CoAP. > > (So, dane WG chairs - if you could propose a consensus call > for the action to take that'd be great and we can move on.) Could you perhaps restate the questions to be considered? I think John Gilmore posed two questions: * What is the representation of oob public keys in DANE TLSA records. Proposed "3 1 X". [FWIW I support this view, with the added observation from James Cloos that "3 0 0" can also match raw public keys via the enclosed SPKI value]. * What document should define this representation, and amend the restrictive language in 6698 Section 1.3: This document only applies to PKIX [RFC5280] certificates, not certificates of other formats. and extend the definition of usage 3 or some new [ideally not] usage to handle raw public keys. Are these the right questions? [ Turf issues aside, there seems to be enough subtle detail in getting this right that it seems to me that a new DANE WG document, quite possibly whatever we call the current "ops" draft by the time November rolls around, is the right place to define this mapping. ] -- Viktor. From nobody Mon Jun 2 09:53:34 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485381A03C2 for ; Mon, 2 Jun 2014 09:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NU5gW5pE32dE for ; Mon, 2 Jun 2014 09:53:24 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C93071A03C1 for ; Mon, 2 Jun 2014 09:53:24 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2C99B802BF for ; Mon, 2 Jun 2014 12:53:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1401727998; bh=Cvs6jp8bDdKVMaNY+ji3Y8X1y4EBXlnBg5b6+QAivnI=; h=Date:From:To:Subject:In-Reply-To:References; b=eOATVVQiVi/vJ8Ja0IbLBVMxo3T7SnEM3ytxmb4QNGMoRt/O8tLdNZOL3wsL81OXt MNMHNW3CGFqRbwTEqAG0R1cgmzt81j9Kqf8hVW/h+bs843q9f6En0pZwql7oe5VE5v PDTcopPPlGmSp5hfPrlwOxyCNwMuCG29QEUgdgJw= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s52GrHRx000366 for ; Mon, 2 Jun 2014 12:53:17 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 2 Jun 2014 12:53:17 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20140602022733.GK27883@mournblade.imrryr.org> Message-ID: References: <201405290805.s4T85HBT008757@new.toad.com> <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> <20140602022733.GK27883@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/EG10Ujrw7sy3oQPk2khJQU36U2o Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jun 2014 16:53:26 -0000 On Mon, 2 Jun 2014, Viktor Dukhovni wrote: > On Sun, Jun 01, 2014 at 10:04:13PM -0400, Tom Gindin wrote: > >> On a technical, or at least quasi-technical point, doesn't usage 3 say >> that it must match the "end-entity certificate given by the server in >> TLS"? > > Usage DANE-EE(3) with selector SPKI(1) matches the subject public > key info of the peer. While as specified in 6698 this SPKI is > expected to be adorned in X.509 finery, it is a natural extension > to allow the same association to apply to bare public keys. Not only the natural extension, it was added specifically to accomodate bare public keys in the future/ > There is simply no need for a new certificate usage here (one for > which selector 0 would make no sense). Indeed it would force > server operators to needlessly publish the SPKI digest twice: > > example. IN TLSA 3 1 1 {blob} > example. IN TLSA 4 1 1 {blob} > > for no good reason. I agree. One TLSA that covers the SPKI should work for TLS servers that give out a bare public key or an EE cert. I'm okay with WH' suggestion of putting this in the soon to be dane ops document, or with an ERRATA to 6698 or with a new one page RFC. Paul From nobody Mon Jun 2 10:29:33 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFA41A033C for ; Mon, 2 Jun 2014 10:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgPUmzUEb_pC for ; Mon, 2 Jun 2014 10:29:29 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F2151A0264 for ; Mon, 2 Jun 2014 10:29:29 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5608C2AAD93; Mon, 2 Jun 2014 17:29:22 +0000 (UTC) Date: Mon, 2 Jun 2014 17:29:22 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140602172922.GS27883@mournblade.imrryr.org> References: <201405290805.s4T85HBT008757@new.toad.com> <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> <20140602022733.GK27883@mournblade.imrryr.org> <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140602145215.GP27883@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/4kUfKihJyOvU9Xt_txSY6gx4MNw Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jun 2014 17:29:31 -0000 On Mon, Jun 02, 2014 at 02:52:15PM +0000, Viktor Dukhovni wrote: > * What is the representation of oob public keys in DANE TLSA > records. Proposed "3 1 X". > > [FWIW I support this view, with the added observation from > James Cloos that "3 0 0" can also match raw public keys via > the enclosed SPKI value]. In whatever document ends up publishing the details, I would say: TLS clients that support out of band public keys ([TLS WG document reference]) authenticated via DANE TLSA records SHOULD NOT employ the "oob public key" TLS extension unless all the server's TLSA records are compatible with out of band public keys. The client SHOULD send an SNI extension with the server's TLSA base domain even if it is willing or expecting to use out of band public keys. [ Rationale. ] Compatible TLSA records include all records with certificate usage DANE-EE(3) and selector SPKI(1) with any matching type. Clients MAY also elect to treat records with usage DANE-EE(3), selector Cert(0) and matching type Full(0) as compatible, provided they are willing and able to extract the public key from such a TLSA record for comparison with the server's bare out of band public key. For the server side, I would add: Servers that support "oob public key" MAY employ SNI to select the correct public key, either by identifying a matching certificate from which to extract the key, or via some other mapping from the requested domain to the corresponding key. -- Viktor. From nobody Mon Jun 2 13:42:04 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317E61A0455 for ; Mon, 2 Jun 2014 13:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0UXi9qx6n23 for ; Mon, 2 Jun 2014 13:42:03 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25C281A0448 for ; Mon, 2 Jun 2014 13:42:03 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id s52KfuBT026606 for ; Mon, 2 Jun 2014 13:41:56 -0700 Message-Id: <201406022041.s52KfuBT026606@new.toad.com> To: dane@ietf.org In-reply-to: <20140602172922.GS27883@mournblade.imrryr.org> References: <201405290805.s4T85HBT008757@new.toad.com> <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> <20140602022733.GK27883@mournblade.imrryr.org> <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> <20140602172922.GS27883@mournblade.imrryr.org> Comments: In-reply-to Viktor Dukhovni message dated "Mon, 02 Jun 2014 17:29:22 -0000." Date: Mon, 02 Jun 2014 13:41:56 -0700 From: John Gilmore Archived-At: http://mailarchive.ietf.org/arch/msg/dane/h2twRaVRoE78eCxngB_x7ISvx_A Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jun 2014 20:42:04 -0000 Viktor suggested: > In whatever document ends up publishing the details, I would say: > > TLS clients that support out of band public keys ([TLS WG > document reference]) authenticated via DANE TLSA records SHOULD > NOT employ the "oob public key" TLS extension unless all the > server's TLSA records are compatible with out of band public > keys. The client SHOULD send an SNI extension with the server's > TLSA base domain even if it is willing or expecting to use out > of band public keys. > > [ Rationale. ] > > Compatible TLSA records include all records with certificate > usage DANE-EE(3) and selector SPKI(1) with any matching type. TLS servers that offer raw public keys should not restrict their TLSA records to only those that match raw public keys. This is not only unnecessary, but harmful. It harms interoperability, and it dents the general applicability strategy of TLSA records, which is that clients look through the set of returned TLSA records for the one(s) that are relevant to their current negotiation. Raw public key support is *negotiated* by the TLS server. In the general case, it will likely offer both raw public keys and PKIX certificates, and the client will choose which option it likes. So that the transaction can complete authentication regardless of which option the client chooses, the server's domain name zone should be free to publish TLSA records that match raw public keys, TLSA records that match PKIX certificates, or both. The TLS server itself should always be free to offer any kind of authentication that it supports. The raw public keys draft already says that it should only offer to negotiate certificate types that it actually both supports and possesses a relevant key for; that is all the constraint that needs to be placed on the TLS server. I do not understand the reference to SNI. Why is there any greater need to send an SNI option than in any other TLS negotiation? Is there something to say here that wasn't already said in RFC 3546 or RFC 6066? e.g. RFC 3546 page 10: It is RECOMMENDED that clients include an extension of type "server_name" in the client hello whenever they locate a server by a supported name type. A server that receives a client hello containing the "server_name" extension, MAY use the information contained in the extension to guide its selection of an appropriate certificate to return to the client, and/or other aspects of security policy. > Clients MAY also elect to treat records with usage DANE-EE(3), > selector Cert(0) and matching type Full(0) as compatible, > provided they are willing and able to extract the public key > from such a TLSA record for comparison with the server's bare > out of band public key. I think this is a bad idea. If the TLS server offers a raw public key, it should not try to authenticate it via a TLSA record that contains a PKIX certificate. The intent of raw public keys is to allow simpler (need I say easier to debug and more secure) clients that don't need to parse, let alone validate, a PKIX certificate. This just complicates clients for no gain in interoperability. There is no gain in interoperability because, if matching a raw public key in a PKIX certificate is OPTIONAL, then clients can't be depended upon to extract a key from a PKIX certificate in order to authenticate the key. This means that server zones will have to publish a real raw public key in a TLSA record anytime they want to have interoperability with raw public key clients. Given that the server zone must in practice publish a real raw key, suggesting that clients should optionally match against a (second) TLSA record containing a complicated PKIX certificate is a burden without any gain. > For the server side, I would add: > > Servers that support "oob public key" MAY employ SNI to select > the correct public key, either by identifying a matching > certificate from which to extract the key, or via some other > mapping from the requested domain to the corresponding key. I think that where the server's public key comes from is irrelevant to the protocol. It could have been extracted from a PKIX certificate, it could have been generated by rolling dice, it could have come from divine inspiration, thermal noise, or the Linux filesystem. Why would we suggest one particular method? If the point is that the Server Name Indication option sent by the client might affect the offered key, that's a point. But the same is even more true of the offered PKIX certificate in traditional TLS, so if we feel the need to say this, why aren't we already saying it about PKIX certificates? John From nobody Mon Jun 2 14:14:06 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFFAC1A03EC for ; Mon, 2 Jun 2014 14:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fALSR480xoe4 for ; Mon, 2 Jun 2014 14:14:01 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B2DB1A03DF for ; Mon, 2 Jun 2014 14:14:01 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B31672AAFFC; Mon, 2 Jun 2014 21:13:54 +0000 (UTC) Date: Mon, 2 Jun 2014 21:13:54 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140602211354.GU27883@mournblade.imrryr.org> References: <201405290805.s4T85HBT008757@new.toad.com> <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> <20140602022733.GK27883@mournblade.imrryr.org> <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> <20140602172922.GS27883@mournblade.imrryr.org> <201406022041.s52KfuBT026606@new.toad.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201406022041.s52KfuBT026606@new.toad.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/2hdyWCAL2sul-rOBA7Dl5MdVhmA Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jun 2014 21:14:03 -0000 On Mon, Jun 02, 2014 at 01:41:56PM -0700, John Gilmore wrote: > TLS servers that offer raw public keys should not restrict their TLSA > records to only those that match raw public keys. There are no such records. Records of the form "3 1 X" also match leaf certificates. > It harms interoperability, and it dents the > general applicability strategy of TLSA records, which is that clients > look through the set of returned TLSA records for the one(s) that are > relevant to their current negotiation. This is not compatible with key rotation or other transitions between past/present/future TLSA records which result in a subset of the TLSA records being "active" (matching the server's actual keys) and another subset being "inactive" (matching either past or future keys). Clients MUST be willing to process all TLSA records, or else should not expect DANE authentication to work. > Raw public key support is *negotiated* by the TLS server. In the > general case, it will likely offer both raw public keys and PKIX > certificates, and the client will choose which option it likes. That's fine "3 1 X" records are compatible with both, but the presence of records with any other known certificate usage or "3 0 X" records (with the possible exception of X == 0) needs to suppress client use of oob public keys when the client's "oob" authentication strategy is DANE. > So > that the transaction can complete authentication regardless of which > option the client chooses, the server's domain name zone should be > free to publish TLSA records that match raw public keys, TLSA records > that match PKIX certificates, or both. That's what "3 1 X" records do. Other records only work with PKIX, and since these may be the only "active" ones (the mythical [Rationale] in short form) the client should assume the worst and not negotiate its way into a dead-end whereby authentication fails. > The TLS server itself should always be free to offer any kind of > authentication that it supports. Yep, that's fine. > I do not understand the reference to SNI. Why is there any greater > need to send an SNI option than in any other TLS negotiation? Is > there something to say here that wasn't already said in RFC 3546 or > RFC 6066? e.g. RFC 3546 page 10: Some mention of interaction with SNI is perhaps redundant, but IMHO useful. Mentioned only because some might think that SNI is only for certificates and is obviated by "oob" keys, but it is not. > > Clients MAY also elect to treat records with usage DANE-EE(3), > > selector Cert(0) and matching type Full(0) as compatible, > > provided they are willing and able to extract the public key > > from such a TLSA record for comparison with the server's bare > > out of band public key. > > I think this is a bad idea. If the TLS server offers a raw public > key, it ["it" is the client here] > should not try to authenticate it via a TLSA record that > contains a PKIX certificate. The intent of raw public keys is to > allow simpler (need I say easier to debug and more secure) clients > that don't need to parse, let alone validate, a PKIX certificate. > This just complicates clients for no gain in interoperability. Clients MAY decide whether they are willing to transform "3 0 0" into the contained "3 1 0". If the WG feel that contrary to the observation by James Cloose this is a bad idea, I am not particularly fixated on this corner case. However, if clients don't map "3 0 0" to "3 1 0", then the presence of "3 0 0" in the TLSA RRset should also suppress use of "oob" keys. > There is no gain in interoperability [...] Indeed, it is only a gain in opportunities to use the oob extension, and thereby make the TLS handshake smaller. > If the point is that the Server Name Indication option sent by the > client might affect the offered key, that's a point. But the same is > even more true of the offered PKIX certificate in traditional TLS, so > if we feel the need to say this, why aren't we already saying it about > PKIX certificates? We are already stating that DANE clients need to use SNI in other contexts. I just carried this over to "oob" keys too. The observation is inessential if it is considered obvious/redundant. -- Viktor. From nobody Mon Jun 2 22:05:07 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D87B1A00B2 for ; Mon, 2 Jun 2014 22:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3Ve6p7e4m1H for ; Mon, 2 Jun 2014 22:05:03 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD5631A00B1 for ; Mon, 2 Jun 2014 22:05:02 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4C531802BF for ; Tue, 3 Jun 2014 01:04:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1401771896; bh=mklkAzB18CA+tHmPAAkdTuNl85s+dEwzrte8CQiqkLU=; h=Date:From:To:Subject:In-Reply-To:References; b=rz4t6mdAbxpKSP1iMmDKTDZs9RCvVr03JiVNanrBIy0byWt2jLK1XcFtJZSBEuaxU BWJHJQCySDk5LwaXFPlJEZLMuRqENvip7EtlWgLEkGljfjzRZz1leiAa8u1ihz+JD7 OT6tr5KuuQ48LXJRqyPDdrBrdSn/PV5nYahWicvI= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s5354tkT022885 for ; Tue, 3 Jun 2014 01:04:55 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 3 Jun 2014 01:04:55 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20140602172922.GS27883@mournblade.imrryr.org> Message-ID: References: <201405290805.s4T85HBT008757@new.toad.com> <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> <20140602022733.GK27883@mournblade.imrryr.org> <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> <20140602172922.GS27883@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/XzcXslVOHE8v85oivEOT4q6Z1iE Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jun 2014 05:05:05 -0000 On Mon, 2 Jun 2014, Viktor Dukhovni wrote: > In whatever document ends up publishing the details, I would say: > > TLS clients that support out of band public keys ([TLS WG > document reference]) authenticated via DANE TLSA records SHOULD > NOT employ the "oob public key" TLS extension unless all the > server's TLSA records are compatible with out of band public > keys. The client SHOULD send an SNI extension with the server's > TLSA base domain even if it is willing or expecting to use out > of band public keys. Again, I don't see why. If there is one TLSA record that matches the public key of the server, that's good enough. If you do any kind of TLS key rollover, the TLS admin better pre-publish the proper TLSA records. Saying that all TLSA records should be of a type compatible with oob serves no purpose and could hinder deploymentment of oob TLS. If a TLS client local policy prefers oob, and it finds only non-oob compatible TLSA records, it could omit using oob to prevent issues. But I don't think that is a MUST. > For the server side, I would add: > > Servers that support "oob public key" MAY employ SNI to select > the correct public key, either by identifying a matching > certificate from which to extract the key, or via some other > mapping from the requested domain to the corresponding key. I do not see why we need to drag SNI into this. How is SNI different for bare keys versus certificates? If the client tells the server the SNI, the server picks the right identity - regardless of the 7250 extension. Paul From nobody Tue Jun 3 06:08:55 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5E81A01F6 for ; Tue, 3 Jun 2014 06:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubTyO1JYfIEf for ; Tue, 3 Jun 2014 06:08:50 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 102D31A026D for ; Tue, 3 Jun 2014 06:08:46 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 167B52AABD5; Tue, 3 Jun 2014 13:08:40 +0000 (UTC) Date: Tue, 3 Jun 2014 13:08:40 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140603130839.GY27883@mournblade.imrryr.org> References: <201405290805.s4T85HBT008757@new.toad.com> <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> <20140602022733.GK27883@mournblade.imrryr.org> <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> <20140602172922.GS27883@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.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/q7I0cmeMdsyOiyOqz70lioHwNdM Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 03 Jun 2014 13:08:53 -0000 On Tue, Jun 03, 2014 at 01:04:55AM -0400, Paul Wouters wrote: > On Mon, 2 Jun 2014, Viktor Dukhovni wrote: > > >In whatever document ends up publishing the details, I would say: > > > > TLS clients that support out of band public keys ([TLS WG > > document reference]) authenticated via DANE TLSA records SHOULD > > NOT employ the "oob public key" TLS extension unless all the > > server's TLSA records are compatible with out of band public > > keys. The client SHOULD send an SNI extension with the server's > > TLSA base domain even if it is willing or expecting to use out > > of band public keys. > > Again, I don't see why. If there is one TLSA record that matches the > public key of the server, that's good enough. If you do any kind of TLS > key rollover, the TLS admin better pre-publish the proper TLSA records. Suppose the only one that does is a "DANE-TA(2) Cert(0) SHA2-256(1)". What then? ; transition state when updating DNS records prior to new ; key deployment. ; example.com IN TLSA 3 1 1 {recent past blob} example.com IN TLSA 2 0 1 {current blob} A client that negotiates "oob public key" in this state fails to authenticate the server. > Saying that all TLSA records should be of a type compatible with oob > serves no purpose and could hinder deploymentment of oob TLS. Obviously I have a purpose in mind, for some reason it is not getting through. I think some others have understood, perhaps they can have a crack at explaining it to you. > If a TLS client local policy prefers oob, and it finds only non-oob > compatible TLSA records, it could omit using oob to prevent issues. > But I don't think that is a MUST. We can quibble over MUST vs. SHOULD. However, and especially because the point appears to be non-obvious to many, experts included, it needs to be made. ALL the TLSA records need to be "3 1 X", possibly also "3 0 0", or else the client SHOULD skip "oob". > > Servers that support "oob public key" MAY employ SNI to select > > the correct public key, either by identifying a matching > > certificate from which to extract the key, or via some other > > mapping from the requested domain to the corresponding key. > > I do not see why we need to drag SNI into this. How is SNI different for > bare keys versus certificates? It isn't. I just wanted to spell it out. DANE clients send SNI, even if when they use "oob public key". As in my reply to John Gilmore, if everyone agrees this is obvious, it is not essential (but harmless, no?). -- Viktor. From nobody Tue Jun 3 10:38:28 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8971A023D for ; Tue, 3 Jun 2014 10:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-hfGjuaYeGK for ; Tue, 3 Jun 2014 10:38:25 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2FFF1A023A for ; Tue, 3 Jun 2014 10:38:24 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id l18so7194552wgh.35 for ; Tue, 03 Jun 2014 10:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=RdyldLOUpjJs3ydn/ZGgbPUlTJVXh+0G6TpgtWUOydc=; b=wis8TFHsjDP8Wd+Lm3xzIDEe4++OqjKERkiCQcaupyGejI/PbeT4Kmo/uhK3fD5Xr8 iPhOmmIqFc+oB8ahskJJdzU13dY37jrzqxufvCMbJbpP4FPSVFRENQWZ7CXQzw9qmbZ3 aG9Sd3r+8ONyMN6imO3qedu2S8b9VwhgH78l+7Nlm73mWKDwTYWmxBWXx5FByRAUp7MB hY5fouwxoilMQzSLKlgXGv201ZrRtVk+jqEwEyucu3WkednTGLLxXz+n58Jn3ok9sCh0 UvBGlwZY+EC42SK7BmFeO2qFMe2AKrLMsZbXfA4nE62QlaXW9rR7UbDBkYqBlPlxsA55 W8bA== MIME-Version: 1.0 X-Received: by 10.194.175.106 with SMTP id bz10mr16774979wjc.96.1401817098050; Tue, 03 Jun 2014 10:38:18 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Tue, 3 Jun 2014 10:38:17 -0700 (PDT) Date: Tue, 3 Jun 2014 13:38:17 -0400 X-Google-Sender-Auth: 5MANBBA9MXAqcBoDbMBSxKltLSM Message-ID: From: Phillip Hallam-Baker To: "dane@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/q6x7WYr9IzBmC5KLEVJy7WCt1ac Subject: [dane] Related work: OmniPublish X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jun 2014 17:38:26 -0000 All, I submitted the following draft: https://datatracker.ietf.org/doc/draft-hallambaker-omnipublish/ The draft proposes a JSON/REST based protocol that a service can use to 1) Tell the local DNS service 'hey I am here, please configure records for me to serve the XYZ protocol'. (also potentially configure firewalls etc). 2) Acquire the necessary cryptographic credentials to provide that service. Now as you would expect from me, the draft is designed to make it as easy as possible for people to get certs from a CA. But combining the two publication tasks into one protocol makes it a good fit for DANE as well. Looking at recent attacks and the needs of cloud service environments and the problem of doing high quality key generation, I believe that at some point in the future the consensus will shift away from the 'generate the keys at the end point' model to a 'generate keys where you know the job will be done right' model. So today the process of bringing up a server is that you install the application, go through the application config, generate keys, do the DNS configuration, apply for certs, configure the server and go. That is going to take a week of elapsed time in a typical enterprise as every request cuts across departments. With OmniPublish the only admin steps required are install the application and go through the application config. The application knows everything else it needs at that point and can ask. Not suggesting this as a WG item. But it is clear that something like this is going to be needed if DANE is ever going to be practical. From nobody Tue Jun 3 19:19:34 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A66D1A0180 for ; Tue, 3 Jun 2014 19:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iju3yGCEmcR3 for ; Tue, 3 Jun 2014 19:19:30 -0700 (PDT) Received: from smtp92.ord1c.emailsrvr.com (smtp92.ord1c.emailsrvr.com [108.166.43.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF801A017A for ; Tue, 3 Jun 2014 19:19:29 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 96193140C96; Tue, 3 Jun 2014 22:19:23 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp4.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 40BE9140C94; Tue, 3 Jun 2014 22:19:22 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Olafur Gudmundsson In-Reply-To: <201405290805.s4T85HBT008757@new.toad.com> Date: Tue, 3 Jun 2014 22:19:20 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <08E92113-6C1F-4BD3-8846-4B117FA1AC1E@ogud.com> References: <201405290805.s4T85HBT008757@new.toad.com> To: John Gilmore X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/qu5DyDX6W7HfO7wUmTrcHI3D0Y0 Cc: dane@ietf.org Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 02:19:33 -0000 John,=20 Sorry for the top posting of our main arguments.=20 RFC7250 has shipped, please do not hold up the publication.=20 We need a quick turnaround to address the issues you identified below.=20= As Wes Hardaker commented in a later message we have an =93Dane uses and = fixes=94 document in the queue and adding this to it is appropriate. (dane-ops)=20 =20 On May 29, 2014, at 4:05 AM, John Gilmore wrote: > The TLS Working Group is in the final stages of approving RFC 7250, > "Using Raw Public Keys in TLS/DTLS": >=20 > https://www.rfc-editor.org/authors/rfc7250.txt >=20 > The draft modifies the TLS protocol to allow clients and servers to > negotiate and exchange types of authentication material other than > PKIX certificate chains, and defines a format for exchanging a raw > public key. These public keys are authenticated "out of band", > outside the TLS protocol, for example by prior administration (in some > Internet-of-Things cases), or by the use of DANE. Paul Wouters was > the main author, and the protocol and document were significantly > improved by several co-authors from the TLS WG. >=20 > In reviewing the draft, I noticed that it doesn't ever describe how > you store such a public key in a TLSA record. And the TLSA RFC 6698 > explicitly specifies that TLSA records can ONLY store PKIX > certificates! The relevant sections are: >=20 > RFC 6698 Sec. 1.3: >=20 > This document only applies to PKIX [RFC5280] certificates, not > certificates of other formats. This is a major change and specifying how to do other certificate types=20= should go through the normal standards process.=20 DANE WG is happy to take that on, and this should be processed before we = go on to DANE-bis document.=20 >=20 > RFC 6698 Sec. 2.1.1: >=20 > The certificate usages defined in this document explicitly only = apply > to PKIX-formatted certificates in DER encoding [X.690]. If TLS > allows other formats later, or if extensions to this RRtype are made > that accept other formats for certificates, those certificates will > need their own certificate usage values. >=20 > I remember fighting this fight in the DANE WG, and the result was > something along the lines of "We'll narrow the RFC now, and then > if-and-when raw public keys are approved by the TLS WG, then we'll > amend it to include them." Well, the time has come. Raw public keys > are approved by the TLS WG. The trouble is that nobody has bothered > to amend the TLSA RFC, so the new draft RFC tells people "just use > DANE", but the DANE TLSA RFC says, "No you can't=94. Lets fix this, based on experience! >=20 > I propose to add some text to the draft RFC 7250 that extends RFC 6698 > by defining how raw public keys are stored in TLSA records. In the chairs opinion that is a bad idea.=20 >=20 > My coauthors seem to prefer that we just ignore the entire issue, > issue RFC 7250, and ignore the conflict between the two. As someone > who learned most of what I know about protocols (and the Internet) > from reading Saint Jon Postel's clearly written RFCs, I would hate to > inflict that on future readers. We should not release documents that > contain deliberate incompatabilities. We wish that this had been detected sooner and a corresponding document = was in=20 the publication queue, we are willing to commit to get this fix ASAP.=20 >=20 > We think RFC 7250 is ready to go except for this remaining issue. It > has been approved by the TLS WG, the IESG, the RFC Editor, and all the > co-authors but me. >=20 > Here's my proposed wording change for RFC 7520. Improvements welcome. > Start from this version: >=20 > https://www.rfc-editor.org/authors/rfc7250.txt >=20 > Section 4.4. > OLD (entire section): > When the TLS server has specified RawPublicKey as the > server_certificate_type, authentication of the TLS server to the TLS > client is supported only through authentication of the received > client SubjectPublicKeyInfo via an out-of-band method. >=20 > NEW (entire section): > When the TLS server has specified RawPublicKey as the > server_certificate_type, authentication of the TLS server to the TLS > client is supported only through authentication of the received > client SubjectPublicKeyInfo via an out-of-band method. >=20 > In order to support out-of-band authentication via DANE [RFC6698], > this document extends the DANE TLSA record definition to allow such > records to describe raw public keys as well as PKIX [RFC5280] > certificates. This extension does not define any new field values; > it merely defines how existing fields are processed when being > matched to raw public keys provided by TLS servers. >=20 > A raw public key is represented in a TLSA record by specifying a > certificate usage of 3 (domain-provided), a selector of 1 > (SubjectPublicKeyInfo), and a matching type of 0. The > SubjectPublicKeyInfo that holds the public key is placed in the > certificate association data. Matching types other than 0 may also > be used, by placing the corresponding hash value into the > certificate association data. >=20 > DANE [RFC6698] section 1.3 is extended to say: >=20 > This document only applies to raw public keys and to PKIX > [RFC5280] certificates, not certificates of other formats. >=20 > DANE section 2.1.1 is extended to say: >=20 > The certificate usages 0, 1 and 2 defined in this document > explicitly only apply to PKIX-formatted certificates in DER > encoding [X.690]. If TLS allows other formats later, or if > extensions to this RRtype are made that accept other formats for > certificates, those certificates will need their own certificate > usage values. >=20 > In DANE section 2.1.1, in addition to the definition of certificate > usage 3 with TLS servers that use PKIX certificates, certificate > usage 3 may also be used with TLS servers that use raw public keys: >=20 > 3 -- Certificate usage 3 is also used to specify a raw public key > that MUST match the raw public key presented by the server in > TLS. When the TLS server provides a raw public key, there is no > PKIX certificate and no PKIX validation is done; the TLS > server's raw public key MUST match the raw public key provided in > the TLSA record. This certificate usage is sometimes referred > to as "domain-issued" because it allows a domain administrator > to directly certify a domain's public keys. >=20 > I believe that this wording reflects the up-to-now tacit consensus on > how the DANE WG expects TLS raw public keys to be represented and > processed in TLSA records. In the absence of significant dissent or > further improvements, I propose to provide the above updates to the > RFC Editor and release the new RFC. >=20 > John We think this text is a good starting point, for the OPS document that = will update RFC6698 The plan we propose is publish RFC7250 and push the fix out no later = than right after the IETF meeting in Toronto.=20 Olafur & Warren=20 From nobody Tue Jun 3 19:31:38 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F751A01A6 for ; Tue, 3 Jun 2014 19:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQHVRhDCB5t8 for ; Tue, 3 Jun 2014 19:31:35 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF4661A0185 for ; Tue, 3 Jun 2014 19:31:34 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 14A3B1DFD6; Wed, 4 Jun 2014 02:31:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1401849087; bh=E+xkzDJjbMlKBazcliykQ7EjfQq6ljEm44+xCmxpRz4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hpKT7KSy54igNnOGtAd4pH0zTuTqpZ/ynCOoiMqONUqvOquRGm/KaY+vaZ1usNL3v jKbORpIms4I1QxhH4/H+yn3MfIY6scLgH1Sb3rA5Nmjz2GoNyKBvAHKi5gv9pEzgmE CNVXWhK7RsbPkEO663bxbZCYW62KyjxnSgseU2eo= Received: by carbon.jhcloos.org (Postfix, from userid 500) id C62576001E; Wed, 4 Jun 2014 02:23:39 +0000 (UTC) From: James Cloos To: Viktor Dukhovni In-Reply-To: <20140603130839.GY27883@mournblade.imrryr.org> (Viktor Dukhovni's message of "Tue, 3 Jun 2014 13:08:40 +0000") References: <201405290805.s4T85HBT008757@new.toad.com> <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> <20140602022733.GK27883@mournblade.imrryr.org> <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> <20140602172922.GS27883@mournblade.imrryr.org> <20140603130839.GY27883@mournblade.imrryr.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 03 Jun 2014 22:23:39 -0400 Message-ID: Lines: 31 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140604:viktor1dane@dukhovni.org::4dNUotFxNNhqp7WM:000000000000000000000000000000000000BMh5y X-Hashcash: 1:30:140604:dane@ietf.org::QsWXI2Jrodo+zakQ:000TpHbL Archived-At: http://mailarchive.ietf.org/arch/msg/dane/5zX9gROhOaLqhJOhGW4F9NljW3w Cc: dane@ietf.org Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 02:31:36 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> Suppose the only one that does is a "DANE-TA(2) Cert(0) SHA2-256(1)". VD> What then? The oob requesting client aborts. And, perhaps, tries again w/o oob. Or, if the client also groks oob-via-ldap, it uses the ldap info instead of the tlsa. I know (based on your posts) that you don't like that as a possible outcome. But for many it is not a big deal. The RFCs do not need to demand that everyone avoid every possible corner case. They instead should explain what occurs when the corners are met. It is not that we fail to understand the issue, we just don't mind the possibility that an oob attempt might fail, even where a non-oob wouldn't. If there are no tlsa records which could work, and if the client can only do oob via dane, then it should avoid oob for that connection. If it does not know how to extract an spki from a cert, and every tlsa which might be for the ee is full cert, then again it should avoid oob. But if any of the tlsa might be ok, there is nothing wrong with it trying oob, just in case it might work. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Tue Jun 3 19:34:32 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBDE1A01A6 for ; Tue, 3 Jun 2014 19:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQa1YOeuxk_1 for ; Tue, 3 Jun 2014 19:34:30 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 713331A01C1 for ; Tue, 3 Jun 2014 19:34:29 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id CE59A1DFD6; Wed, 4 Jun 2014 02:34:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1401849263; bh=qrayyTi1ivBThk5eXhtUkNqgTAM00zwwF9SdxKUILIc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=CR+u9qaIDh9FNGls7C5ez30Kuax1RD44jVCGZ7nlt7U1utp6LmOmyQTMlyJibgsL+ 342s6HEJhCmStd7uQNZKYwxCiRGPqhFJ/Yh1tbr1jvJjyZfu0hn1hjT/Q2/nOzF+5+ eWGamV4ZUCr4BBip8T8I2eAv6huM4D4U6uROqSgc= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 36C076001E; Wed, 4 Jun 2014 02:26:37 +0000 (UTC) From: James Cloos To: Viktor Dukhovni In-Reply-To: <20140603130839.GY27883@mournblade.imrryr.org> (Viktor Dukhovni's message of "Tue, 3 Jun 2014 13:08:40 +0000") References: <201405290805.s4T85HBT008757@new.toad.com> <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> <20140602022733.GK27883@mournblade.imrryr.org> <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> <20140602172922.GS27883@mournblade.imrryr.org> <20140603130839.GY27883@mournblade.imrryr.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 03 Jun 2014 22:26:37 -0400 Message-ID: Lines: 18 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140604:viktor1dane@dukhovni.org::Q7cj41QdUgyVEZus:000000000000000000000000000000000000+/jA3 X-Hashcash: 1:30:140604:dane@ietf.org::/iC1nZfVOigSkU31:000fEF5P Archived-At: http://mailarchive.ietf.org/arch/msg/dane/V5q_EgU2ak41W6BbQiovEI3BRRk Cc: dane@ietf.org Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 02:34:31 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> It isn't. I just wanted to spell it out. DANE clients send SNI, VD> even if when they use "oob public key". As in my reply to John VD> Gilmore, if everyone agrees this is obvious, it is not essential VD> (but harmless, no?). Just as a point of reference, SNI is irrelevant for all of my tls servers and their tlsa records. I'm sure I'm not alone in that. So I also do not understand why the oob document(s) should need to say anything about sni. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Tue Jun 3 19:55:54 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F7C1A0027 for ; Tue, 3 Jun 2014 19:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aaEewijiKUE for ; Tue, 3 Jun 2014 19:55:42 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C90AC1A0023 for ; Tue, 3 Jun 2014 19:55:41 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 47E702AAB4F; Wed, 4 Jun 2014 02:55:35 +0000 (UTC) Date: Wed, 4 Jun 2014 02:55:35 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140604025535.GJ27883@mournblade.imrryr.org> References: <201405290805.s4T85HBT008757@new.toad.com> <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> <20140602022733.GK27883@mournblade.imrryr.org> <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> <20140602172922.GS27883@mournblade.imrryr.org> <20140603130839.GY27883@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.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/pZoYeeOv3_XjNUL5negbq2uy6Fo Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 02:55:53 -0000 On Tue, Jun 03, 2014 at 10:23:39PM -0400, James Cloos wrote: > VD> Suppose the only one that does is a "DANE-TA(2) Cert(0) SHA2-256(1)". > VD> What then? > > The oob requesting client aborts. And, perhaps, tries again w/o oob. > > Or, if the client also groks oob-via-ldap, it uses the ldap info instead > of the tlsa. > > I know (based on your posts) that you don't like that as a possible outcome. > But for many it is not a big deal. Authentication unnecessarily failing is indeed a big deal. There isn't always a user to click OK, and stateful fallback is a pain to get right and opens up opportunities for downgrade attacks. Unreliable authentication protocols that fail even when both sides are doing everything right are broken by design. Needless corner cases need to be rounded out. I am willing to say "SHOULD" rather than MUST, but otherwise, I am not giving up without a better argument than "IETF security protocols sport broken corner case by design" and we're used to it. Just like we're used to broken implementations I guess. I am from a design and implementation culture where we do it well, or not at all. The onus to get this corner case avoided needs to be either on the client or on the server. The client-side solution is simpler: * Avoid "oob public key" negotiation when authentication is via DANE and TLSA records may require a full certificate. The server-side solution is more complex: * When publishing any "3 1 X" TLSA records, always publish records that match the current leaf keys. When transitioning to/from "3 1 X" TLSA RRs to other usage/selector pairs, change one thing at a time. Either change the keys while keeping the set of usage/selector pairs fixed (publishing these for both new and old keys during the transition), or else keep the keys fixed and publish both new and old usage/selector combinations during the transition. If the group strongly prefers the server-side approach, speak up. Silence on the issue leads to security protocol implementations that break for no good reason for a multiple of the TLSA RR TTL. The OPS draft needs to advise the use of either or both of the above approaches. -- Viktor. From nobody Wed Jun 4 00:47:25 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640571A0100 for ; Wed, 4 Jun 2014 00:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ue5yeYPgFAhA for ; Wed, 4 Jun 2014 00:47:20 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 824041A00FA for ; Wed, 4 Jun 2014 00:47:20 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 598691DE94; Wed, 4 Jun 2014 07:47:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1401868032; bh=TWFMiUopZxjOty+YdSaCZ4nM4tPpnKsQYYZew2sYvi8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=oxBI9BtE9Kyz/tIfFZx3ldVXOGEDiTyDaowvM8XzgX+WGVi+DN6/Iqn5ZE0R8BdHO Be8m7Y0fQpPe66WdxrBWypV2nXbqOn39WseTmxgepbp3MJ77Eag8hdOjvJ9FhYE2U8 T9foBfnQ7MknWtcx/dXteCVr8hrBzvZGn4v/Q3IQ= Received: by carbon.jhcloos.org (Postfix, from userid 500) id DFC1560021; Wed, 4 Jun 2014 07:38:54 +0000 (UTC) From: James Cloos To: Viktor Dukhovni In-Reply-To: <20140604025535.GJ27883@mournblade.imrryr.org> (Viktor Dukhovni's message of "Wed, 4 Jun 2014 02:55:35 +0000") References: <201405290805.s4T85HBT008757@new.toad.com> <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> <20140602022733.GK27883@mournblade.imrryr.org> <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> <20140602172922.GS27883@mournblade.imrryr.org> <20140603130839.GY27883@mournblade.imrryr.org> <20140604025535.GJ27883@mournblade.imrryr.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Wed, 04 Jun 2014 03:38:54 -0400 Message-ID: Lines: 71 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140604:viktor1dane@dukhovni.org::jHAmE3kAj89d33n2:000000000000000000000000000000000000dySkV X-Hashcash: 1:30:140604:dane@ietf.org::tdqM3pGNEziFISZ2:0005s/Fx Archived-At: http://mailarchive.ietf.org/arch/msg/dane/gGUxapo_bCmTc1zFkAGZ6fruKZA Cc: dane@ietf.org Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 07:47:22 -0000 >>>>> "VD" == Viktor Dukhovni writes: Perhaps I worded poorly. Trying again. It is OK for some document -- esp if it is a BCP -- to say that doing certain things can prove problemantic. But even for a tls client which likes to try oob, and which only uses dane to verify oob, it is not unreasonable to try oob and if it fails try normal tls. Without any need for user clicking, et alia. That procedure should be rare; it SHOULD only occur when a destination is changing from supporting oob to not supporting it, and even then only if the dns got changed before the server's config. OTOH, multiple types of tlsa can exist for servers which support both oob and full cert clients. Such servers may want to specify type 0, 1 or 2 for the full cert clients and type 3 for the oob clients. I'm an example, in fact. My web server has a paid cert for compatibility reasons, and I publish a 111 for it. Since I'm wasting money on the cert, full-cert clients might as well pkix verify it. But since I'm fine with oob, once that becomes available for my sw I'd be happy to add a 311 to support it. I'm certain other sites will have similar objectives. Avoiding oob in that case makes oob less useful than it might be. Especially if oob-only clients show up. Sites like goog may have the same ideas even for their MXs. Because tlsa mis-configuration should be so rare, it also is OK for a client which finds itself in such a circumstance to abort completely. Oob-only clients will have to. Either way, some alert -- popup, email, syslog, whatever -- is good. But if the client prefers to retry w/o oob doing so generally should not require user intervention. The fact that it occurred is strong evidence that the site is transitioning away from oob. VD> Authentication unnecessarily failing is indeed a big deal. But this particular case should be most unusual. Most changeovers will follow the add-new-tlsa, change-server-config, remove-old-tlsa pattern. Telling clients never to try oob when multiple tlsas are present means that transitions *to* oob would break if the middle step is change-server-only-to-do-oob or add-oob-too. I have no objection to a document explaining to server admins what is likely to work and what is likely to fail. And how each potential failure is likely to present. And although it seems like miniscule should is enough when advising admins how best to deploy, I won't argue against SHOULD in such a document. But telling clients they cannot TRY, or even SHOULD NOT TRY, just because a mis-configuration is possible, is too much. Even if all of the tlsas *are* 31x, there is no guarantee any will match. That failure case is really no different than the no-ee-spki- matches failure case, except that clients which can do both oob and full could, in the latter case, fall back to full and try again. That also might fail. I should note that I only just considerred the idea of oob-only. I think that I've edited that concept into the above missive, but I'm way too tired to be sure. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Wed Jun 4 00:52:07 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8E71A00FA for ; Wed, 4 Jun 2014 00:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtbseYt42VAv for ; Wed, 4 Jun 2014 00:52:04 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E3291A00FF for ; Wed, 4 Jun 2014 00:52:04 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id E1DBE1DE94; Wed, 4 Jun 2014 07:51:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1401868318; bh=74ZQsCoyUkbG9uMplcjzZv890JwgG4PjsT+ceaA7Uvg=; h=From:To:Subject:Date:From; b=prVoRXSv6X77DS2EFFaxV2wqVtUwig6ShBlP9LcHnaqP640bqUMh4ZTau9wMvmgOf 82FGoUe4v3qy2gbWQ4YGj77tBknK2YzDvagHHhjYvbdfuIeaiwmUN5COp3/A9ii/oD RtoMPYr0AbPAErf/egYve/aEY64cdoy/8A3h4SX4= Received: by carbon.jhcloos.org (Postfix, from userid 500) id A556560021; Wed, 4 Jun 2014 07:48:36 +0000 (UTC) From: James Cloos To: dane@ietf.org User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Wed, 04 Jun 2014 03:48:36 -0400 Message-ID: Lines: 25 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140604:dane@ietf.org::fafej1Z1pU+m3Zpx:0004qORZ Archived-At: http://mailarchive.ietf.org/arch/msg/dane/MbG8j6ZPbeb6Gj_EAhkX0pqJLuo Subject: [dane] tls oob vs tlsa 11x X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 07:52:05 -0000 I just occurred to me that, given that oob is negotiated bewteen the client and the server, that the oob concept is !pkix, and any verification of the spki is conceptually identical, a tlsa 11x is just as usable by an oob client as a 31x is. It does not matter than a typical full cert client would do a pkix verification on top of the tlsa verification when the tlsa is 11x. The oob client *and server* have agreed not to bother with pkix, so any ee-spki association is sufficient to verify the offerred spki. In other words, by agreeing to oob, the server gives the client consent to ignore any pki details about the verification. Only tlsa 0 and 2, which do not dirrectly reference the ee, are really unusable in the oob case. So the proper language probably is something like: End-Entity SPKI association via dane, ldap, firmare or any other pre-agreed method. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Wed Jun 4 05:59:03 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A321A01D2 for ; Wed, 4 Jun 2014 05:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVL9DS9vSU-Y for ; Wed, 4 Jun 2014 05:58:59 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3AEBA1A01D5 for ; Wed, 4 Jun 2014 05:58:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AC7B5BF43; Wed, 4 Jun 2014 13:58:52 +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 BVcq76s1eo9H; Wed, 4 Jun 2014 13:58:49 +0100 (IST) Received: from [10.43.50.173] (unknown [193.190.253.145]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EB538BF42; Wed, 4 Jun 2014 13:58:48 +0100 (IST) Message-ID: <538F180A.40906@cs.tcd.ie> Date: Wed, 04 Jun 2014 13:58:50 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Olafur Gudmundsson , John Gilmore References: <201405290805.s4T85HBT008757@new.toad.com> <08E92113-6C1F-4BD3-8846-4B117FA1AC1E@ogud.com> In-Reply-To: <08E92113-6C1F-4BD3-8846-4B117FA1AC1E@ogud.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/FAT6JSzEc73BRldXSPMGdac1Jes Cc: dane@ietf.org Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 12:59:01 -0000 Thanks Olafur, Now that the DANE WG are going to address this issue, I think that means that John can send his approval for auth-48 for oob and we can move it forward. Cheers, S. On 04/06/14 03:19, Olafur Gudmundsson wrote: > > John, > Sorry for the top posting of our main arguments. > RFC7250 has shipped, please do not hold up the publication. > We need a quick turnaround to address the issues you identified below. > > As Wes Hardaker commented in a later message we have an “Dane uses and fixes” document in the > queue and adding this to it is appropriate. (dane-ops) > > > On May 29, 2014, at 4:05 AM, John Gilmore wrote: > >> The TLS Working Group is in the final stages of approving RFC 7250, >> "Using Raw Public Keys in TLS/DTLS": >> >> https://www.rfc-editor.org/authors/rfc7250.txt >> >> The draft modifies the TLS protocol to allow clients and servers to >> negotiate and exchange types of authentication material other than >> PKIX certificate chains, and defines a format for exchanging a raw >> public key. These public keys are authenticated "out of band", >> outside the TLS protocol, for example by prior administration (in some >> Internet-of-Things cases), or by the use of DANE. Paul Wouters was >> the main author, and the protocol and document were significantly >> improved by several co-authors from the TLS WG. >> >> In reviewing the draft, I noticed that it doesn't ever describe how >> you store such a public key in a TLSA record. And the TLSA RFC 6698 >> explicitly specifies that TLSA records can ONLY store PKIX >> certificates! The relevant sections are: >> >> RFC 6698 Sec. 1.3: >> >> This document only applies to PKIX [RFC5280] certificates, not >> certificates of other formats. > > This is a major change and specifying how to do other certificate types > should go through the normal standards process. > DANE WG is happy to take that on, and this should be processed before we go on to DANE-bis document. > >> >> RFC 6698 Sec. 2.1.1: >> >> The certificate usages defined in this document explicitly only apply >> to PKIX-formatted certificates in DER encoding [X.690]. If TLS >> allows other formats later, or if extensions to this RRtype are made >> that accept other formats for certificates, those certificates will >> need their own certificate usage values. >> >> I remember fighting this fight in the DANE WG, and the result was >> something along the lines of "We'll narrow the RFC now, and then >> if-and-when raw public keys are approved by the TLS WG, then we'll >> amend it to include them." Well, the time has come. Raw public keys >> are approved by the TLS WG. The trouble is that nobody has bothered >> to amend the TLSA RFC, so the new draft RFC tells people "just use >> DANE", but the DANE TLSA RFC says, "No you can't”. > > Lets fix this, based on experience! > >> >> I propose to add some text to the draft RFC 7250 that extends RFC 6698 >> by defining how raw public keys are stored in TLSA records. > > In the chairs opinion that is a bad idea. > >> >> My coauthors seem to prefer that we just ignore the entire issue, >> issue RFC 7250, and ignore the conflict between the two. As someone >> who learned most of what I know about protocols (and the Internet) >> from reading Saint Jon Postel's clearly written RFCs, I would hate to >> inflict that on future readers. We should not release documents that >> contain deliberate incompatabilities. > > We wish that this had been detected sooner and a corresponding document was in > the publication queue, we are willing to commit to get this fix ASAP. > >> >> We think RFC 7250 is ready to go except for this remaining issue. It >> has been approved by the TLS WG, the IESG, the RFC Editor, and all the >> co-authors but me. >> >> Here's my proposed wording change for RFC 7520. Improvements welcome. >> Start from this version: >> >> https://www.rfc-editor.org/authors/rfc7250.txt >> >> Section 4.4. >> OLD (entire section): >> When the TLS server has specified RawPublicKey as the >> server_certificate_type, authentication of the TLS server to the TLS >> client is supported only through authentication of the received >> client SubjectPublicKeyInfo via an out-of-band method. >> >> NEW (entire section): >> When the TLS server has specified RawPublicKey as the >> server_certificate_type, authentication of the TLS server to the TLS >> client is supported only through authentication of the received >> client SubjectPublicKeyInfo via an out-of-band method. >> >> In order to support out-of-band authentication via DANE [RFC6698], >> this document extends the DANE TLSA record definition to allow such >> records to describe raw public keys as well as PKIX [RFC5280] >> certificates. This extension does not define any new field values; >> it merely defines how existing fields are processed when being >> matched to raw public keys provided by TLS servers. >> >> A raw public key is represented in a TLSA record by specifying a >> certificate usage of 3 (domain-provided), a selector of 1 >> (SubjectPublicKeyInfo), and a matching type of 0. The >> SubjectPublicKeyInfo that holds the public key is placed in the >> certificate association data. Matching types other than 0 may also >> be used, by placing the corresponding hash value into the >> certificate association data. >> >> DANE [RFC6698] section 1.3 is extended to say: >> >> This document only applies to raw public keys and to PKIX >> [RFC5280] certificates, not certificates of other formats. >> >> DANE section 2.1.1 is extended to say: >> >> The certificate usages 0, 1 and 2 defined in this document >> explicitly only apply to PKIX-formatted certificates in DER >> encoding [X.690]. If TLS allows other formats later, or if >> extensions to this RRtype are made that accept other formats for >> certificates, those certificates will need their own certificate >> usage values. >> >> In DANE section 2.1.1, in addition to the definition of certificate >> usage 3 with TLS servers that use PKIX certificates, certificate >> usage 3 may also be used with TLS servers that use raw public keys: >> >> 3 -- Certificate usage 3 is also used to specify a raw public key >> that MUST match the raw public key presented by the server in >> TLS. When the TLS server provides a raw public key, there is no >> PKIX certificate and no PKIX validation is done; the TLS >> server's raw public key MUST match the raw public key provided in >> the TLSA record. This certificate usage is sometimes referred >> to as "domain-issued" because it allows a domain administrator >> to directly certify a domain's public keys. >> >> I believe that this wording reflects the up-to-now tacit consensus on >> how the DANE WG expects TLS raw public keys to be represented and >> processed in TLSA records. In the absence of significant dissent or >> further improvements, I propose to provide the above updates to the >> RFC Editor and release the new RFC. >> >> John > > We think this text is a good starting point, for the OPS document that will update RFC6698 > > The plan we propose is publish RFC7250 and push the fix out no later than right after the > IETF meeting in Toronto. > > Olafur & Warren > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > From nobody Wed Jun 4 06:44:53 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 449201A0238 for ; Wed, 4 Jun 2014 06:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFVDNVGfn0I9 for ; Wed, 4 Jun 2014 06:44:50 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED8A71A01F3 for ; Wed, 4 Jun 2014 06:44:49 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DDF2C2AB1EB; Wed, 4 Jun 2014 13:44:41 +0000 (UTC) Date: Wed, 4 Jun 2014 13:44:41 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140604134441.GN27883@mournblade.imrryr.org> References: <20140602022733.GK27883@mournblade.imrryr.org> <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> <20140602172922.GS27883@mournblade.imrryr.org> <20140603130839.GY27883@mournblade.imrryr.org> <20140604025535.GJ27883@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.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/A-oNT8s9uTDt9LA8VwvVyHN5FWA Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 13:44:52 -0000 On Wed, Jun 04, 2014 at 03:38:54AM -0400, James Cloos wrote: > >>>>> "VD" == Viktor Dukhovni writes: > > Perhaps I worded poorly. Trying again. > > It is OK for some document -- esp if it is a BCP -- to say that doing > certain things can prove problemantic. > > But even for a tls client which likes to try oob, and which only uses > dane to verify oob, it is not unreasonable to try oob and if it fails > try normal tls. Without any need for user clicking, et alia. > > That procedure should be rare; it SHOULD only occur when a destination > is changing from supporting oob to not supporting it, and even then > only if the dns got changed before the server's config. If implementors don't think the issue though, they might well fail and not retry. I've seen enough "naive" and "cargo cult" code in this space to be skeptical of likely implementation quality in the absence of specific guidance. Thus the OPS BCP should provide specific guidance, alerting implementors to the issue, and advising them of the simplest solution (skip oob when somewhat likely to fail and the client implements use of PKIX certs). > OTOH, multiple types of tlsa can exist for servers which support both > oob and full cert clients. Such servers may want to specify type 0, > 1 or 2 for the full cert clients and type 3 for the oob clients. You may recall my observations about mixing models ("PKIX" vs. "DANE"). > I'm an example, in fact. My web server has a paid cert for > compatibility reasons, and I publish a 111 for it. You allowed to needlessly torment users whose trusted CA list does not include your issuing CA. :-) > Since I'm wasting > money on the cert, full-cert clients might as well pkix verify it. This rationale is generally flawed, because were DNSSEC compromised, the attacker would replace your 111 with a 311 of his choice. Thus the "111" is only useful in applications that refuse to mix models, and only honour PKIX usages. It is hard to say what the right policy is for browser-oriented web sites, there is no application-specific definition of how or whether browsers are to implement DANE authentication. RFC 6698 is a generic template for application protocols, and does not define browser behaviour. > But since I'm fine with oob, once that becomes available for my sw > I'd be happy to add a 311 to support it. I'm certain other sites will > have similar objectives. If you're publishing 311, you obviate the 111 record, unless in fact some specification appears that mandates PKIX usages in browsers, in which case your "311" would only apply to some other class of clients. > Avoiding oob in that case makes oob less useful than it might be. > Especially if oob-only clients show up. For single-model clients (those that only support PKIX usages or those that only support DANE usages) the TLSA RRs for the unsupported model are "unusable". I should perhaps have mentioned (and will in the BCP) that one first discards "unusable" TLSA RRs and only then considers whether the *remaining* RRs are "oob compatible". > Sites like goog may have the same ideas even for their MXs. Well, for SMTP, their only choices are DANE-TA or DANE-EE. There is no reason to mix the two. The rationale for DANE-TA is operational, you get to decouple server certificate updates from DNS updates, no DNS changes for server key rotation: _25._tcp.mx1.example.com. IN CNAME dane-ta._tlsa.examle.com. _25._tcp.mx2.example.com. IN CNAME dane-ta._tlsa.examle.com. ... _25._tcp.mxN.example.com. IN CNAME dane-ta._tlsa.examle.com. dane-ta._tlsa.example.com. IN TLSA 2 0 1 {blob} if one publishes "311" along with it, all the benefit is lost, and there is no reason whatever to also publish the "2 0 1". > Because tlsa mis-configuration should be so rare, it also is OK for a > client which finds itself in such a circumstance to abort completely. > Oob-only clients will have to. I've not introduced "misconfiguration" as a use-case. All the corner cases were properly configured. Servers that need to support "oob only" clients will need to publish "311" records, if they do so in combination with other records, only "oob only" clients will negotiate "oob". Oob-only clients will find all incompatible TLSA RRs unusable. They can't do what I suggest and negotiate X.509 certs, so they are out of scope. > VD> Authentication unnecessarily failing is indeed a big deal. > > But this particular case should be most unusual. > > Most changeovers will follow the add-new-tlsa, change-server-config, > remove-old-tlsa pattern. Telling clients never to try oob when multiple > tlsas are present means that transitions *to* oob would break if the > middle step is change-server-only-to-do-oob or add-oob-too. This glosses over key details. For servers that publish only "3 1 X" records, transitions from one set of "3 1 X" records to another just change the number of "3 1 X" records seen, and nobody suspends use of "oob". The only time use of "oob" is discouraged for clients that support both "oob" and not, is when the transition mixes (usable) TLSA usage/selector combinations. > I have no objection to a document explaining to server admins what is > likely to work and what is likely to fail. And how each potential > failure is likely to present. And although it seems like miniscule > should is enough when advising admins how best to deploy, I won't argue > against SHOULD in such a document. I will expand the advice (already needed for key rotation and digest agility) for servers that covers how to transition between old and new key material or TLSA RR types. The same "product set" approach combined with "change one feature at a time" indeed reduces potential impact on clients that implement or honour only a subset of the published record types. > But telling clients they cannot TRY, or even SHOULD NOT TRY, just > because a mis-configuration is possible, is too much. What you characterize as a misconfiguration is not, unless we define new server-side obligations. Transition states are not misconfigurations. If you are suggesting that the strategy I have in mind for "safe" TLSA RRset updates is be a mandate, we can discuss that. If indeed the server is obligated to avoid non product-set mixed states, then clients can always expect each C/U/M combination to contain at least one RR that matches the servers "active" chain. I've never seen such a requirement stated in any DANE WG document. I am open to defining such a requirement, and publishing a methodology for transitions between parameter sets that never violates such a requirement. > Even if all of the tlsas *are* 31x, there is no guarantee any will > match. Now we're talking misconfiguration, that's the server's fault. -- Viktor. From nobody Wed Jun 4 07:15:49 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1191A01F6 for ; Wed, 4 Jun 2014 07:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPGGhISm9rUe for ; Wed, 4 Jun 2014 07:15:42 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58C841A0246 for ; Wed, 4 Jun 2014 07:15:40 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B9CA22AAB4F; Wed, 4 Jun 2014 14:15:32 +0000 (UTC) Date: Wed, 4 Jun 2014 14:15:32 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140604141532.GP27883@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.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/HeMZhArKdIFDncYAZxqZUkaRZfQ Subject: Re: [dane] tls oob vs tlsa 11x X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 14:15:47 -0000 On Wed, Jun 04, 2014 at 03:48:36AM -0400, James Cloos wrote: > I just occurred to me that, given that oob is negotiated bewteen the > client and the server, that the oob concept is !pkix, and any > verification of the spki is conceptually identical, a tlsa 11x is just > as usable by an oob client as a 31x is. This is a slippery slope. In my original SMTP draft I had language suggesting aumatic mapping PKIX-TA(0)->DANE-TA(2) and PKIX-EE(1)->DANE-EE(3). This was abandoned in favour of 0/1 undefined (likely "unusable") for SMTP and only 2/3 supported. If the server operator wants PKIX checks, client-side overrides should probably not be an RFC-defined behaviour. Now it turns out that Postfix treats "0" as "unusable", but indeed automatically maps "1" to "3", because as you observe "why not?". However, I think such liberties should not be officially endorsed. > It does not matter than a typical full cert client would do a pkix > verification on top of the tlsa verification when the tlsa is 11x. > The oob client *and server* have agreed not to bother with pkix, > so any ee-spki association is sufficient to verify the offerred spki. It would be better for such servers to publish "311" and be done. > In other words, by agreeing to oob, the server gives the client consent > to ignore any pki details about the verification. > Only tlsa 0 and 2, which do not dirrectly reference the ee, are really > unusable in the oob case. > So the proper language probably is something like: > > End-Entity SPKI association > > via dane, ldap, firmare or any other pre-agreed method. If the WG collectively agree that non-PKIX clients are free to map PKIX-EE(1) to DANE-EE(3) and that server operators can expect this behaviour, then we still have time to ammend the SMTP draft, to say that PKIX-EE(1) may be published but SHALL be treated as though it were DANE-EE(3) by SMTP clients. My view at this juncture is that such mappings should not be expected, and are a matter of client implementation discretion. If a client views PKIX-EE(1)/SPKI(1) as though it were DANE-EE(3)/SPKI(1) then, that client obviously won't see any "oob" obstacles from any associated RRs (of course PKIX-EE(1)/Cert(0) is still a potential problem, barring new constraints the records servers should publish). -- Viktor. From nobody Wed Jun 4 07:22:47 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69921A023E for ; Wed, 4 Jun 2014 07:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_34=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hAwTpyA0we9 for ; Wed, 4 Jun 2014 07:22:40 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 837561A019C for ; Wed, 4 Jun 2014 07:22:40 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EEB08800C9 for ; Wed, 4 Jun 2014 10:22:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1401891754; bh=+qiiypvLximqmkUVscS2qoTnVNaQacsuLAuBGpJAseM=; h=Date:From:To:Subject:In-Reply-To:References; b=W6baAXaFf8BA7q78UYYN0tghnjxtQEVaYeS3UEYtUq9dhQvU1XtalZiv1Hj/QaI8Z KSJ9QkpBeR7ND1SUr0dpbMWzmaMUoZCW2Aggv8Io/V6/db3p9h4B0aDrw0Lhq/Zw1p NVG6hP81ccNYoMMWxQgXmlbyym/l7RBYQb6ARM/M= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s54EMXJx027389 for ; Wed, 4 Jun 2014 10:22:33 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 4 Jun 2014 10:22:33 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20140604134441.GN27883@mournblade.imrryr.org> Message-ID: References: <20140602022733.GK27883@mournblade.imrryr.org> <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> <20140602172922.GS27883@mournblade.imrryr.org> <20140603130839.GY27883@mournblade.imrryr.org> <20140604025535.GJ27883@mournblade.imrryr.org> <20140604134441.GN27883@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/gW5JLbW8GxO9imf-hx77-E6VVNE Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 14:22:44 -0000 On Wed, 4 Jun 2014, Viktor Dukhovni wrote: > (skip oob when somewhat likely to fail and the client implements use of PKIX certs). It's not "likely to fail" when there is an exising "3 1 x" TLSA record published! >> Since I'm wasting >> money on the cert, full-cert clients might as well pkix verify it. And trust one of the 600 (give or take a 100) CAs to not be compromised? I would argue that if you are using oob, but also want compatibility with classic X.509 certificates, you should use the same "3 1 x" record, and ignore all pkix verification. the only reason to pick something else is if you want the trust anchor to be a CA and not an EE cert. In which case, why are you doing oob+dane? > if one publishes "311" along with it, all the benefit is lost, and > there is no reason whatever to also publish the "2 0 1". You can still pin to a single CA for "classic x.509" and pin to a pubkey for "oob". But you are right in that it is only postponing the inevitable administration that is needed to publish just TLS public keys and not legacy CAs. > The only time use of "oob" is discouraged for clients > that support both "oob" and not, is when the transition mixes > (usable) TLSA usage/selector combinations. Still don't see that :P >> Even if all of the tlsas *are* 31x, there is no guarantee any will >> match. > > Now we're talking misconfiguration, that's the server's fault. Leaves me puzzled even more about what you _are_ trying to convey as the requirement for not mixing "3 1 x" and other types. Paul From nobody Wed Jun 4 07:44:20 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF421A0268 for ; Wed, 4 Jun 2014 07:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMTzxof2rF_t for ; Wed, 4 Jun 2014 07:44:15 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34EDF1A0359 for ; Wed, 4 Jun 2014 07:44:15 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 88BB32AAB4F; Wed, 4 Jun 2014 14:44:08 +0000 (UTC) Date: Wed, 4 Jun 2014 14:44:08 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140604144408.GR27883@mournblade.imrryr.org> References: <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> <20140602172922.GS27883@mournblade.imrryr.org> <20140603130839.GY27883@mournblade.imrryr.org> <20140604025535.GJ27883@mournblade.imrryr.org> <20140604134441.GN27883@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.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/7UUtXmkrdZ_FD8PAKEB3SD508vs Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 14:44:17 -0000 On Wed, Jun 04, 2014 at 10:22:33AM -0400, Paul Wouters wrote: > >(skip oob when somewhat likely to fail and the client implements use of PKIX certs). > > It's not "likely to fail" when there is an exising "3 1 x" TLSA record > published! Sure it is, those record might match only a future or past server key when other RR parameter combinations are also present. Unless we define such transitions as invalid, and publish server-operator guidelines that place the burden on the server to avoid such states. Is that the WG's preference? I can strengthen the key rotation guidelines in the OPs draft (looks like it is about to morph into a standards track 6698 update) to require server operators to avoid transition states in which any of the published C/U/M combinations match only future or only past keys. This requires some attention to detail when updating TLSA RRs, and a tricky process when switching from "311" to "201": 1. 311 old self-signed leaf 2. 311 old leaf + 311 new DANE-TA issued leaf (wait for 1 to age out then deploy new cert chain). 3. 201 new DANE-TA issued chain (previously published as 311 in step 2). at each stage there are now C/U/M combinations that don't match any "active" key. > Leaves me puzzled even more about what you _are_ trying to convey as > the requirement for not mixing "3 1 x" and other types. Consider the above transition from a 311 self-signed cert to a DANE-TA(2) issued cert, in which the server operator is in a hurry, and we've not yet mandated the above process: 1. 311 old self-signed leaf 2. 311 old (still active) leaf + 201 planned TA (wait for 1 to age out, then activate new chain). 3. Drop 311 leaving only 201. This this, "oob" clients lose at step 2 when the new chain is activated, but the RRset has "311" only for obsolete keys and a "201" for the active keys. Note, this is not a "misconfiguration" in any sense with respect to 6698, and is not a problem prior to the introduction of "oob" negotiation. -- Viktor. From nobody Wed Jun 4 08:47:29 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029041A0302 for ; Wed, 4 Jun 2014 08:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aUhccb0neeP for ; Wed, 4 Jun 2014 08:47:25 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4522E1A0270 for ; Wed, 4 Jun 2014 08:47:25 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 79A0B2AB1EB; Wed, 4 Jun 2014 15:47:17 +0000 (UTC) Date: Wed, 4 Jun 2014 15:47:17 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140604154717.GU27883@mournblade.imrryr.org> References: <20140602022733.GK27883@mournblade.imrryr.org> <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> <20140602172922.GS27883@mournblade.imrryr.org> <20140603130839.GY27883@mournblade.imrryr.org> <20140604025535.GJ27883@mournblade.imrryr.org> <20140604134441.GN27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140604134441.GN27883@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/beetQQtGMGLf6Y1dzCLZ5z_NMNw Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 15:47:27 -0000 On Wed, Jun 04, 2014 at 01:44:41PM +0000, Viktor Dukhovni wrote: > If you are suggesting that the strategy I have in mind for "safe" > TLSA RRset updates is be a mandate, we can discuss that. If indeed > the server is obligated to avoid non product-set mixed states, then > clients can always expect each C/U/M combination to contain at > least one RR that matches the servers "active" chain. Sorry, the C/U/M abbreviation (created in error) is likely opaque. I meant: U/S/M * U = usage * S = selector * M = matching type. instead while thinking "certificate usage" I typed C/U/M. It is possible (with care) to ensure that server TLSA records always contain at least one "active" record per U/S/M. We can recommend appropriate record management strategies to server operators. That way no matter which subset of U/S/M values a client either supports or elects to use, authentication will succeed. If use of such strategies becomes a *requirement* (failure to do so is a "misconfiguration), then I'm open to relaxing the client "oob" constraints from "SHOULD NOT" (under list of conditions) to "may choose not to" (under list of conditions just in case the server fails to handle state transitions properly). Clients that decide to proceed with "oob" anyway (but are capable of handling X.509 chains), should then retry without "oob" if authentication fails. If on the other hand servers are not required to enforce the above requirement (each U/S/M contains an "active" record). Then (under list of conditions where server's chain is mixed, ...) clients capable of both "oob" and not "oob" have no reason to go out of their way to shoot themselves in the foot with "oob" and needing to fall back. The "oob" extension in that case is just a minor optimization that is best skipped when potentially problematic. -- Viktor. From nobody Thu Jun 5 04:48:16 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34121A0071 for ; Thu, 5 Jun 2014 04:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0C5j9026D13 for ; Thu, 5 Jun 2014 04:48:11 -0700 (PDT) Received: from proxima.lp0.eu (proxima.lp0.eu [IPv6:2001:8b0:ffea:0:205:b4ff:fe12:530]) by ietfa.amsl.com (Postfix) with ESMTP id B6CCD1A0058 for ; Thu, 5 Jun 2014 04:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=arlott.org; s=exim; h=Content-Transfer-Encoding:Content-Type:MIME-Version:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=//Xgw7uCN5FUPxdByMiad3QvX03LlwplmasxgrkCIe8=; b=nB6dT9fZoF0nR9C1RoI830+TCB9WXife1WFsgx629RkmWLtJqm6XqaT67eyngC5OMzgMeQ/T4381CTsbNz6qi/KWZIy9aVcVL4cAFBh/miOE60QE7OuSqBKZdhUsaJV1kF+3TqH6ewPG3Y89ETG3jnCsmi+gPFXii2YBTeGBJeVSt+1T1qi99I7lVswFlre2/+HDXJmSeHKdYXNVqaa+HBzTWC8ugPGzjIojMW9bJ9WE7JywVpr6NtbzPdnGnCvH8ZVe4SbQGkgkLew8T6P/CBFxdrLBdVOxzWvCZ9KOtgsgswCBlFxVqscwcjWzJyQdDu5Rm8HMY9M/f/Vl9bpqHg==; Received: from lp0_webmail by proxima.lp0.eu with local id 1WsW9G-0005xQ-Fw for dane@ietf.org; Thu, 05 Jun 2014 12:47:59 +0100 Received: from simon by proxima.lp0.eu with https; Thu, 5 Jun 2014 12:47:58 +0100 Message-ID: <4e941a7fe4be00884d43cf848b30bec228883452@8b5064a13e22126c1b9329f0dc35b8915774b7c3.invalid> In-Reply-To: <20140604025535.GJ27883@mournblade.imrryr.org> References: <201405290805.s4T85HBT008757@new.toad.com> <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> <20140602022733.GK27883@mournblade.imrryr.org> <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> <20140602172922.GS27883@mournblade.imrryr.org> <20140603130839.GY27883@mournblade.imrryr.org> <20140604025535.GJ27883@mournblade.imrryr.org> Date: Thu, 5 Jun 2014 12:47:58 +0100 From: "Simon Arlott" To: dane@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/dane/qH5pr6kjzFb0x7UX77ir37M1tJk Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 11:48:13 -0000 On Wed, June 4, 2014 03:55, Viktor Dukhovni wrote: > On Tue, Jun 03, 2014 at 10:23:39PM -0400, James Cloos wrote: > The onus to get this corner case avoided needs to be either on the > client or on the server. The client-side solution is simpler: > > * Avoid "oob public key" negotiation when authentication is > via DANE and TLSA records may require a full certificate. If at least one TLSA record is DANE-EE(3) then a full certificate is not required for that record. Why do you need to restrict the client behaviour when the other currently defined record types are also present? What is the intended behaviour of the oob-capable client when new TLSA record types are defined? Do those records also cause it to refuse to do OOB or does it ignore them? -- Simon Arlott From nobody Thu Jun 5 08:15:16 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30311A028A for ; Thu, 5 Jun 2014 08:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kca0zre64_YB for ; Thu, 5 Jun 2014 08:15:13 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FFBA1A025C for ; Thu, 5 Jun 2014 08:11:53 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 692F22AAB4F; Thu, 5 Jun 2014 15:11:45 +0000 (UTC) Date: Thu, 5 Jun 2014 15:11:45 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140605151145.GA27883@mournblade.imrryr.org> References: <20140602022733.GK27883@mournblade.imrryr.org> <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> <20140602172922.GS27883@mournblade.imrryr.org> <20140603130839.GY27883@mournblade.imrryr.org> <20140604025535.GJ27883@mournblade.imrryr.org> <4e941a7fe4be00884d43cf848b30bec228883452@8b5064a13e22126c1b9329f0dc35b8915774b7c3.invalid> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4e941a7fe4be00884d43cf848b30bec228883452@8b5064a13e22126c1b9329f0dc35b8915774b7c3.invalid> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/8v1nc1aGAPjhisjJgvhRO3kGsC0 Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 15:15:14 -0000 On Thu, Jun 05, 2014 at 12:47:58PM +0100, Simon Arlott wrote: > On Wed, June 4, 2014 03:55, Viktor Dukhovni wrote: > > On Tue, Jun 03, 2014 at 10:23:39PM -0400, James Cloos wrote: > > The onus to get this corner case avoided needs to be either on the > > client or on the server. The client-side solution is simpler: > > > > * Avoid "oob public key" negotiation when authentication is > > via DANE and TLSA records may require a full certificate. > > If at least one TLSA record is DANE-EE(3) then a full certificate > is not required for that record. This is false. Firstly because one cannot match a public key against a "3 0 [12]" record. Secondly, because during transitions between old and new keys which don't preserve the U/S/M combinations used (old key "3 0 1", new key "3 1 1" not yet deployed) some of the TLSA records don't match the server's change, and this may be true for all records with a particular U/S/M combination (until the new key is deployed). Due to DNS caching, keys rollover and TLSA record updates are not synchronized. > Why do you need to restrict the client behaviour when the other > currently defined record types are also present? Because I've written an i's dotted/t's crossed DANE implementation and have thought through the details that many folks are glossing over. Some are with me on the fine details but suggest that the client should instead fail and retry. But then, clients need to know that they should be prepared to retry without oob if they prefer that for some reason to suppressing oob. The text can offer clients a choice. * Suppress oob public keys when it might well lead to authentication failure with servers rolling over keys and the client can handle full cert chains. * Otherwise, be prepared for authentication to fail, and retry without "oob". Predicated on the existence of "usable" records other than "3 1 X" and possibly "3 0 0" if the client is prepared to use that with oob. Finally, the WG could decide that servers which publish U/S/M combinations in their TLSA RRset that contain only future or only past keys are "misconfigured", and that servers SHOULD NOT do that. In that case arguably the burden to get this right is on the server and the client can be let off the hook. I will also add language to the ops draft explaining how servers can avoid such problem TLSA records and that they SHOULD do so. (or at least at that it is strongly RECOMMENDED that they do so). The rationale is that servers have no knowledge of which combinations of usages, selectors or matching types are unsupported, administratively disabled or otherwise unavailable/ignored by the client. The safest assumption is that each U/S/M combination might be the only one supported by a given client, and therefore should always match current (not future or past) server keys. Still, I am not sure that server operators will reliably "get the memo". And thus client caution is approriate where there is little to lose by suppressing a minor TLS optimization. > What is the intended behaviour of the oob-capable client when new > TLSA record types are defined? Do those records also cause it to > refuse to do OOB or does it ignore them? No, "unusable" TLSA records (not recognized by the client that could never be used for matching whether a full cert chain or a bare key is negotiated) are ignored first. The language in the ops draft will spell this out. -- Viktor. From nobody Thu Jun 5 10:51:39 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3891A0281 for ; Thu, 5 Jun 2014 10:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsdBqCEggxMH for ; Thu, 5 Jun 2014 10:51:35 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1B0F1A0285 for ; Thu, 5 Jun 2014 10:51:35 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 59B0F800C9 for ; Thu, 5 Jun 2014 13:51:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1401990688; bh=YTIupFDwdlcnnZKF1Od2wPy3tL4rzcWV9kCiFm6XbWw=; h=Date:From:To:Subject:In-Reply-To:References; b=k5HCvEX/3iSU5wcAL3y5OiQMttjOXnwvnSKCI4oQdwfp0VX4Cdze+99AGvrZ/onNO 9d5OOUKDr8m5KNnLUGqY2G5wAzfxXDbRSotxNCWPW6Xef7p2XgRSejdAMSdSSHF7z/ zIR86YMnau7LjUqL7GlEYYOqZTzAuCFlvNNcz5k8= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s55HpRqj003316 for ; Thu, 5 Jun 2014 13:51:27 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 5 Jun 2014 13:51:27 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20140605151145.GA27883@mournblade.imrryr.org> Message-ID: References: <20140602022733.GK27883@mournblade.imrryr.org> <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> <20140602172922.GS27883@mournblade.imrryr.org> <20140603130839.GY27883@mournblade.imrryr.org> <20140604025535.GJ27883@mournblade.imrryr.org> <4e941a7fe4be00884d43cf848b30bec228883452@8b5064a13e22126c1b9329f0dc35b8915774b7c3.invalid> <20140605151145.GA27883@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/09rZRGYGo1Z-d0JxbYrCn9ECG14 Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 17:51:38 -0000 On Thu, 5 Jun 2014, Viktor Dukhovni wrote: > The text can offer clients a choice. > > * Suppress oob public keys when it might well lead to authentication > failure with servers rolling over keys and the client can handle full > cert chains. You'd have to carefully lay out which kind of failures, eg BOGUS versus missing "3 1 x" TLSA record. > * Otherwise, be prepared for authentication to fail, and retry without > "oob". It all seems local policy to me that does not need to be specified in the document. > Finally, the WG could decide that servers which publish U/S/M > combinations in their TLSA RRset that contain only future or only > past keys are "misconfigured", and that servers SHOULD NOT do that. Why does the WG need to decide that? It's simply the case now? AFAIK, all thoughout DANE the policy is "grab the TLSA RRset - if you find no usable record, authentication fails". No one prevents you from writing a TLS client that first checks for TLSA "3 1 x" records usable for oob before starting a connection, and if you fail to find these records to start TLS without the oob extension. The problem I have is your desire to drop oob when finding a non-"3 1 x" record AND a "3 1 x" record, and argue that the latter record "might be incorrect and the server admin might not realise this when he updated the other type of TLSA record and therefor we should not allow mixed types ever". > In that case arguably the burden to get this right is on the server > and the client can be let off the hook. I don't see why this is ever NOT the case. > The rationale is that servers have no knowledge of which combinations > of usages, selectors or matching types are unsupported, administratively > disabled or otherwise unavailable/ignored by the client. The safest > assumption is that each U/S/M combination might be the only one > supported by a given client, and therefore should always match > current (not future or past) server keys. For any set of X TLSA records of various types, to rollover you add a matching X sets of TLSA records with the new pubkey/cert/chain record. T=1 one set of TLSA records in DNS. T=2 prepare new certs/pubkeys - add another whole st of TLSA records in DNS. T=3 wait for 2x TTL T=4 update the key/cert of the TLS server(s) - Take as long as you want T=5 all TLS servers only have the new cert/key, so remove the old set from T=1 from DNS Where in all of this MUST we say "should always match current (not future or past) server keys." > And thus client caution is approriate where there is little > to lose by suppressing a minor TLS optimization. That's your personal subjective value judgement. I would say, when the operator publishes a TLSA record to match SPKI, they are working hard to get rid of this legacy X.509 container disaster using a very important new TLS extension. Restricting the TLSA RRset or pro-actively dropping the oob extension based on a mixture of TLSA U/S/M records is undesirable, and your justification of "the admin might make an erorr" is an extremely weak reason for it. Paul From nobody Thu Jun 5 11:23:43 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C782E1A02FC for ; Thu, 5 Jun 2014 11:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zD4ZUzBD3xb for ; Thu, 5 Jun 2014 11:23:42 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 424731A028F for ; Thu, 5 Jun 2014 11:23:42 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id s55INYBT006182; Thu, 5 Jun 2014 11:23:34 -0700 Message-Id: <201406051823.s55INYBT006182@new.toad.com> To: James Cloos In-reply-to: References: Comments: In-reply-to James Cloos message dated "Wed, 04 Jun 2014 03:48:36 -0400." Date: Thu, 05 Jun 2014 11:23:34 -0700 From: John Gilmore Archived-At: http://mailarchive.ietf.org/arch/msg/dane/aDZjgi19QaUgC16jV118Kd-rVXA Cc: dane@ietf.org Subject: Re: [dane] tls oob vs tlsa 11x X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 18:23:42 -0000 > I[t] just occurred to me that, given that oob is negotiated bewteen the > client and the server, that the oob concept is !pkix, and any > verification of the spki is conceptually identical, a tlsa 11x is just > as usable by an oob client as a 31x is. Yes, in theory, any TLSA x 1 y record could be used to authenticate a raw public key. (That is, any record whose selector is "public key" as opposed to "cert".) But rather than defining that clients should expect such things, I think the WG should first define a canonical representation for a raw public key in a TLSA record, and require that "raw public key" clients MUST support that representation. This, then, will tell domain name administrators what record format to use in the normal course of publishing raw public keys with servers in their domain. Then, as a separate and probably harder question, we should decide what additional TLSA record formats that clients MUST, SHOULD, MAY, or MUST NOT support. John From nobody Thu Jun 5 11:24:38 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947611A02F9 for ; Thu, 5 Jun 2014 11:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzGNPaQtQgO9 for ; Thu, 5 Jun 2014 11:24:30 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7F031A024D for ; Thu, 5 Jun 2014 11:24:29 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 033F52AB160; Thu, 5 Jun 2014 18:24:16 +0000 (UTC) Date: Thu, 5 Jun 2014 18:24:15 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140605182415.GM27883@mournblade.imrryr.org> References: <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> <20140602172922.GS27883@mournblade.imrryr.org> <20140603130839.GY27883@mournblade.imrryr.org> <20140604025535.GJ27883@mournblade.imrryr.org> <4e941a7fe4be00884d43cf848b30bec228883452@8b5064a13e22126c1b9329f0dc35b8915774b7c3.invalid> <20140605151145.GA27883@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.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/x_e8dB6Yzy7H_mb9KtM_RHGylNc Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 18:24:35 -0000 On Thu, Jun 05, 2014 at 01:51:27PM -0400, Paul Wouters wrote: > It all seems local policy to me that does not need to be specified in > the document. Leaving key implementation correctness details out of documents leads to shoddy non-interoperable implementations. The issues are somewhat subtle, and clearly not obvious to many. My plan is to explain the issues and offer clients a choice. > >Finally, the WG could decide that servers which publish U/S/M > >combinations in their TLSA RRset that contain only future or only > >past keys are "misconfigured", and that servers SHOULD NOT do that. > > Why does the WG need to decide that? It's simply the case now? No it is not. Look at the verification logic in the appendix that loops over all the records. There is no expectation that every TLSA RR reflects current reality, nor can there be. All that's required is that *at least one* TLSA record matches the server chain. To enable key rotation, some records will not, and there is no guidance on how to do key rotation in a way that supports all possible subsets of supported U/S/M values. > AFAIK, all thoughout DANE the policy is "grab the TLSA RRset - if you > find no usable record, authentication fails". This leaves all the relevant details to the point of vacuous irrelevance. This is a subtle topic that requires attention to detail. > The problem I have is your desire to drop oob when finding a non-"3 1 x" > record AND a "3 1 x" record, and argue that the latter record "might be > incorrect and the server admin might not realise this when he updated > the other type of TLSA record and therefore we should not allow mixed > types ever". Not just "might", will be incorrect a non-trivial fraction of the time, unless we specify new server-side requirements. > >In that case arguably the burden to get this right is on the server > >and the client can be let off the hook. > > I don't see why this is ever NOT the case. Because there is nothing in any DANE document that encourages, let alone obligates the server to ensure the necessary invariants. Left to their devices server operators will publish the problematic RRsets (which cause no obvious problems without "oob"). > For any set of X TLSA records of various types, to rollover you add a > matching X sets of TLSA records with the new pubkey/cert/chain record. Suppose the goal is to switch a TA-issued cert (previous self-signed) and publish a DANE-EE(2) association, from a current "3 1 1" leaf cert. This can't be done while preserving the stated invariant without a non-obvious intermideate stage in the DNS keys, because the self-signed initial cert has no TA. Initial: IN TLSA 3 1 1 {legacy EE blob} Intermediate: IN TLSA 3 1 1 {legacy EE blob} IN TLSA 3 1 1 {EE association for new TA issued chain} [switch keys] Final: IN TLSA 2 0 1 {TA cert blob matching new chain} While a simple key rotation looks like: Initial: IN TLSA 3 1 1 {legacy EE blob} Intermediate: IN TLSA 3 1 1 {legacy EE blob} IN TLSA 3 1 1 {new EE blob} [switch keys] Final: IN TLSA 3 1 1 {new EE blob} > >And thus client caution is approriate where there is little > >to lose by suppressing a minor TLS optimization. > > That's your personal subjective value judgement. I would say, when the > operator publishes a TLSA record to match SPKI, they are working hard to > get rid of this legacy X.509 container disaster using a very important > new TLS extension. Most operators who publish "3 1 X" will publish *ONLY* "3 1 X" and my oh-so-subtle comments won't apply. The deployment of "oob" will not be in any way reduced. By making it safer to deploy "oob" (not causing unnecessary outages) I am on your side. > Restricting the TLSA RRset or pro-actively dropping the oob extension > based on a mixture of TLSA U/S/M records is undesirable, and your > justification of "the admin might make an erorr" is an extremely weak > reason for it. And yet you're simply wrong about that. Somewhere, either the client or the server or both need to do some non-obvious things (that I plan to write down) to make sure DANE works reliably (always when everyone does what's expected of them and written down). Authentication protocols that fail in non-obvious corner-cases are not progress. The WG can help shift the balance of the burden to either the client or the server. My plan is encourage caution on both sides. The consequence of caution will be fewer users spending sleepless nights debugging non-obvious problems while cursing the designers of the fragile systems they've saddled with supporting. -- Viktor. From nobody Thu Jun 5 11:56:31 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE121A0247 for ; Thu, 5 Jun 2014 11:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xU68V-5mtDzt for ; Thu, 5 Jun 2014 11:56:27 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 046791A0163 for ; Thu, 5 Jun 2014 11:56:27 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id F1985800C9 for ; Thu, 5 Jun 2014 14:56:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1401994580; bh=uJDO+Fr/Cgi8mNNMcsX2Y9O5F2+ydz2aVvxYPcg96s8=; h=Date:From:To:Subject:In-Reply-To:References; b=XgLkL4gH4Ix0jlttY/6Ja9rZvpEZfmPw7cDI5IrwjWNuRWuvZzZeNhbUx1llwkNfV PWAwWd+XgnB0oftFnk2OaqSK6lVNCgIyyfqaNCJaz96aZkTVgx2dMzh0ite6KJb/13 dkni3YMWQQYioqFSQo4NFgL8HCLYftUDW3od6vkU= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s55IuJnF008258 for ; Thu, 5 Jun 2014 14:56:19 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 5 Jun 2014 14:56:19 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20140605182415.GM27883@mournblade.imrryr.org> Message-ID: References: <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> <20140602172922.GS27883@mournblade.imrryr.org> <20140603130839.GY27883@mournblade.imrryr.org> <20140604025535.GJ27883@mournblade.imrryr.org> <4e941a7fe4be00884d43cf848b30bec228883452@8b5064a13e22126c1b9329f0dc35b8915774b7c3.invalid> <20140605151145.GA27883@mournblade.imrryr.org> <20140605182415.GM27883@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/JOBteQ9B3m42IMrWtueApbxwStQ Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 18:56:29 -0000 On Thu, 5 Jun 2014, Viktor Dukhovni wrote: > No it is not. Look at the verification logic in the appendix that > loops over all the records. There is no expectation that every > TLSA RR reflects current reality, nor can there be. All that's > required is that *at least one* TLSA record matches the server > chain. Right. Which is why you can have mixes of types/selectors/usage. > Because there is nothing in any DANE document that encourages, let > alone obligates the server to ensure the necessary invariants. > Left to their devices server operators will publish the problematic > RRsets (which cause no obvious problems without "oob"). TLSA records are not TLS client remote configuration records. I think it is a bad idea to allow a TLSA record to modify TLS client behaviour for TLS extensions. TLSA is to authenticate, not to configure. > Suppose the goal is to switch a TA-issued cert (previous self-signed) > and publish a DANE-EE(2) association, from a current "3 1 1" leaf > cert. This can't be done while preserving the stated invariant > without a non-obvious intermideate stage in the DNS keys, because > the self-signed initial cert has no TA. > > Initial: > > IN TLSA 3 1 1 {legacy EE blob} > > Intermediate: > > IN TLSA 3 1 1 {legacy EE blob} > IN TLSA 3 1 1 {EE association for new TA issued chain} > > [switch keys] > > Final: > > IN TLSA 2 0 1 {TA cert blob matching new chain} Why can't I do: Initial: IN TLSA 3 1 1 {legacy EE blob} Intermediate: IN TLSA 3 1 1 {legacy EE blob} IN TLSA 2 0 1 {TA cert blob matching new chain} [switch keys] Final: IN TLSA 2 0 1 {TA cert blob matching new chain} The only requirement is to ensure old TLSA RRsets without the new TLSA record do not live anywhere in cache anywhere when the new TLS cert/key/chain is deployed on the server. > Most operators who publish "3 1 X" will publish *ONLY* "3 1 X" and > my oh-so-subtle comments won't apply. The deployment of "oob" will > not be in any way reduced. By making it safer to deploy "oob" (not > causing unnecessary outages) I am on your side. Most operators who want to get rid of X.509 containers and uselessly expiring X.509 certificates (Like Yahoo yesterday?) and wanting to deploy oob will first use a DANE-EE SPKI on a full cert, and do any kind of CA/TA based matching anyway? >> Restricting the TLSA RRset or pro-actively dropping the oob extension >> based on a mixture of TLSA U/S/M records is undesirable, and your >> justification of "the admin might make an erorr" is an extremely weak >> reason for it. > > And yet you're simply wrong about that. Somewhere, either the > client or the server or both need to do some non-obvious things > (that I plan to write down) I have no problem writing down the non-obvious. I just disagree with your proposed TLS client behaviour. I think we both understand each other's viewpoint. It's time for others to chime in. Paul From nobody Thu Jun 5 12:25:49 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F0B1A0301 for ; Thu, 5 Jun 2014 12:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z_RiTkukuTBa for ; Thu, 5 Jun 2014 12:25:40 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 951A71A02F2 for ; Thu, 5 Jun 2014 12:25:40 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D24D62AB160; Thu, 5 Jun 2014 19:25:33 +0000 (UTC) Date: Thu, 5 Jun 2014 19:25:33 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140605192533.GN27883@mournblade.imrryr.org> References: <20140602172922.GS27883@mournblade.imrryr.org> <20140603130839.GY27883@mournblade.imrryr.org> <20140604025535.GJ27883@mournblade.imrryr.org> <4e941a7fe4be00884d43cf848b30bec228883452@8b5064a13e22126c1b9329f0dc35b8915774b7c3.invalid> <20140605151145.GA27883@mournblade.imrryr.org> <20140605182415.GM27883@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.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/0-Z3shsvzWJhE-hWRF6ITIJ80iw Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 19:25:47 -0000 On Thu, Jun 05, 2014 at 02:56:19PM -0400, Paul Wouters wrote: > >Because there is nothing in any DANE document that encourages, let > >alone obligates the server to ensure the necessary invariants. > >Left to their devices server operators will publish the problematic > >RRsets (which cause no obvious problems without "oob"). > > TLSA records are not TLS client remote configuration records. That claim is not universal. For a DANE-capable SMTP client TLSA records actually set a bunch of TLS policy. The "discovery" vs. "lookup" non-issue. > I think it is a bad idea to allow a TLSA record to modify TLS client > behaviour for TLS extensions. TLSA is to authenticate, not to configure. Authentication is behaviour. > >without a non-obvious intermideate stage in the DNS keys, because > >the self-signed initial cert has no TA. > > > > Initial: > > > > IN TLSA 3 1 1 {legacy EE blob} > > > > Intermediate: > > > > IN TLSA 3 1 1 {legacy EE blob} > > IN TLSA 3 1 1 {EE association for new TA issued chain} > > > > [switch keys] > > > > Final: > > > > IN TLSA 2 0 1 {TA cert blob matching new chain} > > Why can't I do: > > Initial: > IN TLSA 3 1 1 {legacy EE blob} > Intermediate: > IN TLSA 3 1 1 {legacy EE blob} > IN TLSA 2 0 1 {TA cert blob matching new chain} > [switch keys] > Final: > IN TLSA 2 0 1 {TA cert blob matching new chain} Well, now before the switch you have a "2 0 1" U/S/M with no active keys. A transition in the opposite direction would break with "oob" clients because it would be the "3 1 1" that matches "future" keys. The safe version of the reverse change looks like: Initial: IN TLSA 2 0 1 {legacy TA blob} Intermediate: IN TLSA 3 1 1 {EE association for legacy TA issued chain} IN TLSA 3 1 1 {future EE blob} [switch keys] Final: IN TLSA 3 1 1 {new EE blob} Had the intermediate listed the original "2 0 1" for the legacy chain, "oob" clients would lose. > Most operators who want to get rid of X.509 containers and uselessly > expiring X.509 certificates (Like Yahoo yesterday?) and wanting to > deploy oob will first use a DANE-EE SPKI on a full cert, and do any kind > of CA/TA based matching anyway? Right, they'll publish "3 1 1", but for some time the actual TLS handshake will exchange certs containing the SPKI, rather than bare SPKI. Eventually clients will start optimizing out the certs. > >And yet you're simply wrong about that. Somewhere, either the > >client or the server or both need to do some non-obvious things > >(that I plan to write down) > > I have no problem writing down the non-obvious. I just disagree with > your proposed TLS client behaviour. First correct, then optimized. Note the definition of "3 1 1" already (once the SMTP and OPS drafts are adopted) largely ignores the cert content (names and expiration, re Yahoo). So the main difference between now and a future client that uses bare keys is that the server sends less data from which the client extracts the SPKI (an optimization). -- Viktor. From nobody Thu Jun 5 15:27:28 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E2B1A0273 for ; Thu, 5 Jun 2014 15:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NG92qFhJobzZ for ; Thu, 5 Jun 2014 15:27:26 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 526CF1A00FE for ; Thu, 5 Jun 2014 15:27:26 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id s55MREBT016220; Thu, 5 Jun 2014 15:27:14 -0700 Message-Id: <201406052227.s55MREBT016220@new.toad.com> To: James Cloos In-reply-to: References: <201405290805.s4T85HBT008757@new.toad.com> <76254E90-245A-4502-AFBE-74A3038BB08F@vpnc.org> <20140602022733.GK27883@mournblade.imrryr.org> <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> <20140602172922.GS27883@mournblade.imrryr.org> <20140603130839.GY27883@mournblade.imrryr.org> <20140604025535.GJ27883@mournblade.imrryr.org> Comments: In-reply-to James Cloos message dated "Wed, 04 Jun 2014 03:38:54 -0400." Date: Thu, 05 Jun 2014 15:27:14 -0700 From: John Gilmore Archived-At: http://mailarchive.ietf.org/arch/msg/dane/r5ZnR6B7OMPftRqizpM2AFBBunw Cc: dane@ietf.org Subject: Re: [dane] Servers which offer RPK but have no TLSA records for that key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 22:27:27 -0000 > But even for a tls client which likes to try oob, and which only uses > dane to verify oob, it is not unreasonable to try oob and if it fails > try normal tls. The TLS Raw Public Keys (RPK) draft RFC does not require clients to retry failed negotiations. If it should, we had better fix it very soon, because it is a single approval from publication. It requires that servers only select RPK if they actively have a key usable with RPK (they send that key in the same message where they select RPK). It currently does not require clients to do the same. But let's look closer at the protocol negotiation to see where it's easiest to fix this situation. Clients that lack software support for PKIX should never offer the PKIX server certificate type in the TLS negotiation. Clients that lack software support for RPK should never offer to negotiate RPK server certificates in the TLS negotiation. This is non-controversial, and is required by RFC 7250. Should clients that lack any Trust Anchors never propose PKIX server certificates? Currently, such clients *do* negotiate PKIX and then prompt the user to validate the certificate that arrived during the PKIX negotiation. (You can verify this by emptying your browser's list of trust anchors and then accessing an TLS website.) Should clients that lack any way to validate a RPK never propose RPK? Since we have no such clients as yet, we could decide this. For example, a client may not have a preconfigured public key for this server, but it may have a DNSSEC resolver and DANE support. But when it starts the TLS session, it will probably not know whether there are any TLSA records that support Raw Public Keys. It sends its server certificate format options in the very first message in the TLS exchange. So, to positively know whether TLSA records exist and support RPK, it would have had to begin and finish a DNSSEC TLSA lookup, and evaluate the results with an eye toward RPK, before beginning *every* TLS exchange it initiates. I think we want to avoid that. Restating, the situation in question is when the client supports DNSSEC and DANE, has TLS software support for both PKIX and RPK, and so does the server, but the published TLSA records may not offer a way to verify the RPK that the server sends. In such a situation, Viktor proposes (if I understand his messages) that the client should offer support for PKIX and RPK server certificates; that the server should select RPK and send an RPK; that the client should then do the TLSA lookup, the client should notice that there is no way to authenticate the RPK it received, and then the client should terminate the TLS exchange and retry, offering only PKIX support. This proposal adds a retry requirement that currently does not exist in either the TLS RFC or the TLS RPK RFC. My proposal to handle this situation is that the client should offer support for PKIX and RPK server certificates; that the server should select PKIX and send a PKIX certificate chain, the client should then do the TLSA lookup, and that then the client should then validate the certificate chain using the TLSA records. This proposal treats the situation as a server misconfiguration. If the server will choose to negotiate RPK but does not have a TLSA record published that can validate RPK, it is misconfigured. Clients are not required to retry in order to attempt to bypass server misconfiguration. Persistent client failure will (eventually) alert the server operator to their error, and they will either fix the TLS server to not offer a RPK, or will fix the domain to include TLSA records that authenticate the server's RPK. John From nobody Thu Jun 5 16:25:22 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC401A032D for ; Thu, 5 Jun 2014 16:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBBxUdHyiukp for ; Thu, 5 Jun 2014 16:25:18 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A8051A0307 for ; Thu, 5 Jun 2014 16:25:18 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D18F22AAB4F; Thu, 5 Jun 2014 23:25:09 +0000 (UTC) Date: Thu, 5 Jun 2014 23:25:09 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140605232509.GQ27883@mournblade.imrryr.org> References: <20140602022733.GK27883@mournblade.imrryr.org> <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> <20140602172922.GS27883@mournblade.imrryr.org> <20140603130839.GY27883@mournblade.imrryr.org> <20140604025535.GJ27883@mournblade.imrryr.org> <201406052227.s55MREBT016220@new.toad.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201406052227.s55MREBT016220@new.toad.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/hqu_Ifgk9FIwBXnKlbAAOholQNs Subject: Re: [dane] Servers which offer RPK but have no TLSA records for that key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 23:25:20 -0000 On Thu, Jun 05, 2014 at 03:27:14PM -0700, John Gilmore wrote: > The TLS Raw Public Keys (RPK) draft RFC does not require clients to > retry failed negotiations. If it should, we had better fix it very > soon, because it is a single approval from publication. I think that's OK. It is just DANE authentication "RPK" clients that need to be aware of the potential reduction in "usable" TLSA RRs when negotiating "RPK" and either avoid negotiating "RPK" when authentication might fail, or be willing to retry without "RPK". Therefore, this seems like a rather DANE-specific issue, to be defined in a DANE document for interoperability with "RPK", so it is not obvious that the DANE-specific issues need to be explicitly stated in the "oob mechanism" independent RPK docuemnt. There are also timing subtleties, are TLSA records located before the TLSA handshake or during the handshake once the server provides key material. If the latter (which I don't recommend for reasons that are TMI for this thread), then the client can only retry, it is too late to suppress RPK in the TLS HELLO. The short version is of course that for clients capable of X.509 server gymnastics, if the TLSA lookup is delayed, then the client might discover complete lack of any "3 1 X" (or whatever compatible U/S/M applies) RRs, and will have to retry without RPK simply because the lookup is too late. Assuming clients that support both certs and RPK are not silly about TLSA record lookup timing, the issue becomes moot if there is a new published requirement on servers to ensure that every U/S/M combination contains some record that matches the server's current chain. I assume there'll be some further discussion about the merits and sufficiency of such a requirement on servers to obviate complications for clients. > Should clients that lack any Trust Anchors never propose PKIX server > certificates? No, because with DANE server certificates are not necessarily PKIX. Usages 2/3 don't require any TAs on the client side. The default Postfix configuration ignores all system provided TAs, and the TA list is empty, and yet we do DANE with "PKIX" certificate chains validated via DANE-TA(2) or DANE-EE(3) TLSA RRs. > Currently, such clients *do* negotiate PKIX and then prompt > the user to validate the certificate that arrived during the PKIX > negotiation. (You can verify this by emptying your browser's list of > trust anchors and then accessing an TLS website.) With DANE, authentication of cert chains is possible without any PKIX CAs. > Should clients that lack any way to validate a RPK never propose RPK? DANE makes it possible to validate RPK via DANE-EE(3)/SPKI(1) associations. However, there are some subtleties we need not repeat the details of when the server TLSA RRset is "mixed". > For > example, a client may not have a preconfigured public key for this > server, but it may have a DNSSEC resolver and DANE support. But when > it starts the TLS session, it will probably not know whether there are > any TLSA records that support Raw Public Keys. The tentative consensus here (DANE WG) appears to be that there is no new TLSA RR type that represents an RPK-specific association. Rather, DANE-EE(3) SPKI(1) MTYPE(0|1|2) is equally usable to match a public key embedded in a certificate or a raw public key. > It sends its server > certificate format options in the very first message in the TLS > exchange. So, to positively know whether TLSA records exist and > support RPK, it would have had to begin and finish a DNSSEC TLSA > lookup, and evaluate the results with an eye toward RPK, before > beginning *every* TLS exchange it initiates. I think we want to avoid > that. The DNS lookup is necessary, but the results can be cached for the TTL in any local resolver, or the application, or both. Postfix caches TLSA RRs in the application (for the shorter of the TTL, 100 seconds, or the lifetime of the SMTP delivery agent). > Restating, the situation in question is when the client supports > DNSSEC and DANE, has TLS software support for both PKIX and RPK, and so > does the server, but the published TLSA records may not offer a way to > verify the RPK that the server sends. [ Or in some corner cases, the client might not be able to tell whether the server can be authenticated with RPK, unless we place new requirements on the server. We can for now collapse this into the above case. ] > In such a situation, Viktor proposes (if I understand his messages) > that the client should offer support for PKIX and RPK server > certificates; No, that's not my proposal. I am proposing that the client should have the TLSA records on hand *before* the handshake, it will always need them after, and doing the lookup (with whatever caching is applicable) earlier makes things much easier. Therefore, I am also proposing that the client in fact NOT offer RPK to the server, if success to authenticate the servers TLSA RRset with RPK is a proper subset of case in which it succeeds had it negotiated PKIX certs instead. Alternatively, (don't know why this is attractive) the client might be willing to reconnect and retry. Finally, if we define server TLSA RRsets that put clients into this position as "misconfiguration", then perhaps we can relieve clients of the burden. > This proposal adds a retry requirement that currently does > not exist in either the TLS RFC or the TLS RPK RFC. I am not at all fond of retries. I am guessing you're not either. > My proposal to handle this situation is that the client should offer > support for PKIX and RPK server certificates; that the server should > select PKIX and send a PKIX certificate chain, the client should then > do the TLSA lookup, and that then the client should then validate the > certificate chain using the TLSA records. You're saying that the server should know the sorry state of its DNS TLSA RRs as seen by the client. This is likely impractical. Servers just have key material and do TLS handshakes they are DNSSEC/DANE agnostic. They have no idea what mechanism if any the client is planning to use to authenticate the server's keys/certs. > If > the server will choose to negotiate RPK but does not have a TLSA > record published that can validate RPK, it is misconfigured. The sentiment is well motivated, but this is likely rather impractical. > Clients > are not required to retry in order to attempt to bypass server > misconfiguration. Again, at the moment, the problem cases are NOT server misconfiguration, we'd have to define new server configuration requirements to make it so. Requirements that burden the server with knowing what authentication mechanisms clients might be using and with knowing how their DANE TLSA records are configured, ... are I think not realistic. Requirements on the content of the TLSA RRs as published are an option. I am planning to write up said server requirements as strong recommendations, but for the moment at least, also publish client recommendations that scale back "opportunistic RPK" (use of RPK when either RPK or PKIX are options) when it doubt. This avoids retries, and has little impact on use of RPK (in most cases servers will have either no or only RPK-compatible TLSA RRs). "Opportunistic RPK" clients should perform TLSA lookups before the handshake. > Persistent client failure will (eventually) alert > the server operator to their error, and they will either fix the > TLS server to not offer a RPK, or will fix the domain to include TLSA > records that authenticate the server's RPK. Perhaps, though initially the volume of clients failing will be rather low, and server operators will blame the bleeding-edge clients (it works for everyone else). -- Viktor. From nobody Thu Jun 5 16:59:29 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428C31A032D for ; Thu, 5 Jun 2014 16:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUrOgsj1s2K7 for ; Thu, 5 Jun 2014 16:59:24 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA9C1A0307 for ; Thu, 5 Jun 2014 16:59:24 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4449A2AAB4F; Thu, 5 Jun 2014 23:59:16 +0000 (UTC) Date: Thu, 5 Jun 2014 23:59:16 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140605235915.GR27883@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/F5Im8Ye-Z-p779_-YPkbqxrmoVM Subject: [dane] RPK use-case high level problem statement X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 23:59:26 -0000 Perhaps we can at least agree on the high-level problem statement: 1. Some clients will support both X.509 and RPK TLS handshakes, and will opportunistically negotiate RPK as an optimization. 2. Some subset of those clients with use DANE authentication to authenticate whichever of X.509 or RPK is negotiated. 3. Some subset of servers will have TLSA RRsets during transition states, not currently defined as "misconfigured", such that X.509 DANE TLSA authentication works, but RPK DANE TLSA authentication fails, because the RPK-compatible TLSA RRs match only past or future keys. 4. Somebody (client, server or both) should do something to avoid unnecessary application failure under the above conditions. 5. We should probably write-up the potential problem cases, and spell out client and server responsibilities and strategies to avoid the problem cases. Either client is conservative and avoids opportunistic RPK, or server avoids publishing potentially problematic RRsets or both. We should probably not recommend "retries" see [Footnote], but for some clients retries might be a viable strategy. -- Viktor. Footnote: Client retries will typically be futile, because a DANE authentication failure with RPK for past/future keys cannot be distinguished from other reasons for the server keys not matching. Clients that retry will often fail to authenticate even after negotiating the use of X.509 keys. Retries are also difficult to hide in client libraries, because often connection management is done by the application, while the TLS protocol engine is handled by a suitable library. Thus applications will have to be willing to retry, and somehow know to tell the library to avoid RPK the second time around. Connection setup can be expensive, and reconnection difficult. -- Viktor. From nobody Thu Jun 5 17:21:56 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5EC11A036E for ; Thu, 5 Jun 2014 17:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxsqz0XfhOv4 for ; Thu, 5 Jun 2014 17:21:52 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D30FE1A0369 for ; Thu, 5 Jun 2014 17:21:52 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id s560LiBT019821; Thu, 5 Jun 2014 17:21:44 -0700 Message-Id: <201406060021.s560LiBT019821@new.toad.com> To: Olafur Gudmundsson In-reply-to: <08E92113-6C1F-4BD3-8846-4B117FA1AC1E@ogud.com> References: <201405290805.s4T85HBT008757@new.toad.com> <08E92113-6C1F-4BD3-8846-4B117FA1AC1E@ogud.com> Comments: In-reply-to Olafur Gudmundsson message dated "Tue, 03 Jun 2014 22:19:20 -0400." Date: Thu, 05 Jun 2014 17:21:44 -0700 From: John Gilmore Archived-At: http://mailarchive.ietf.org/arch/msg/dane/pWZDgfaw2DS8Dn4Q22Gi_SNTC4k Cc: dane@ietf.org Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 00:21:53 -0000 > Sorry for the top posting of our main arguments. > RFC7250 has shipped, please do not hold up the publication. > We need a quick turnaround to address the issues you identified below. > > As Wes Hardaker commented in a later message we have an “Dane uses and fixes” document in the > queue and adding this to it is appropriate. (dane-ops) Today I read the dane-ops-03 document. The latest is from February, which seems rather old. Also, it is designed to be a Best Current Practice, and it does not update the DANE TLSA RFC 6698. It has been argued by an RFC 6698 co-author that only an RFC which "Updates: 6698" and goes through "the IETF community" and the DANE WG can amend the strong statements in RFC 6698 that invalidate any DANE protocol use that doesn't involve PKIX. He said: > Under no circumstances should RFC 6698 be updated in the fashion > that John suggests below. The IETF community did not have an > opportunity to review the proposed changes, the draft in question > never mentioned that it would update RFC 6698, and the DANE WG was > only informed of this during AUTH48. > > The authors could, and should, simply do a short Internet Draft that > updates RFC 6698. Many / most of us would support that. The Dane-Ops Draft doesn't meet these criteria. So, either that co-author would have to recant his previously expressed stance in order to resolve the "TLSA for raw public keys" issue in the Dane-Ops Draft; or else Dane-Ops would have to become a standards-track protocol spec, not a BCP. Perhaps if the WG agrees with this co-author, the only thing is to ignore Dane-Ops and instead write a new 2-page Internet-Draft. Also, various people in the DANE WG have different ideas on how to represent Raw Public Keys (RPKs) in TLSA records, what operational constraints to put on TLSA records involving RPKs, and even how the TLS protocol itself should evolve to require retries when using RPKs. It seems a bit too early to say, "just release RFC 7250, it won't need any more changes" when these issues have not been resolved, nor even extensively explored. I thought that we had consensus that just publishing a "3 1 x" key would suffice, but it has become clear that others have very different ideas, including "4 1 x" records, "1 1 x" records, etc. I think that the real stumbling block here is the attitude that "DANE is only for PKIX", which some WG participants came in with, which was embedded into what became the primary DANE RFC (TLSA RFC 6698), and which some continue to argue for. Until and unless that attitude is definitively repudiated by the WG in toto, I suspect that we will continue to have problems reaching consensus whenever any IETF member tries to use DNSSEC for a protocol (like Raw Public Keys) that does not use PKIX certificates. John From nobody Thu Jun 5 18:11:35 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713691A037C for ; Thu, 5 Jun 2014 18:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWSoiYc8akLQ for ; Thu, 5 Jun 2014 18:11:29 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1EC1A037A for ; Thu, 5 Jun 2014 18:11:29 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 37EFF2AAB4F; Fri, 6 Jun 2014 01:11:21 +0000 (UTC) Date: Fri, 6 Jun 2014 01:11:21 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140606011121.GS27883@mournblade.imrryr.org> References: <201405290805.s4T85HBT008757@new.toad.com> <08E92113-6C1F-4BD3-8846-4B117FA1AC1E@ogud.com> <201406060021.s560LiBT019821@new.toad.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201406060021.s560LiBT019821@new.toad.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/NKqb74qxeB6v7ef2ClJAXSM7Yg8 Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 01:11:34 -0000 On Thu, Jun 05, 2014 at 05:21:44PM -0700, John Gilmore wrote: > Today I read the dane-ops-03 document. The latest is from February, > which seems rather old. Also, it is designed to be a Best Current > Practice, and it does not update the DANE TLSA RFC 6698. Indeed, sorry about that, since just before London, we've focused primarily on the SMTP draft, to the detriment of progress on the ops draft. Cycles were limited. This is about to change... In particular the ops draft will shortly be revived from limbo, changed to standards track and will update 6698. > Also, various people in the DANE WG have different ideas on how to > represent Raw Public Keys (RPKs) in TLSA records, what operational > constraints to put on TLSA records involving RPKs, and even how the > TLS protocol itself should evolve to require retries when using > RPKs. It seems a bit too early to say, "just release RFC 7250, it > won't need any more changes" when these issues have not been resolved, > nor even extensively explored. You'll find that there is little support for RPK formats other than "3 1 X", despite a small number of suggestions to the contrary. A consensus around "3 1 X" is I think a safe bet. It is also not clear that "RPK" is fundamentally dependent on an extant definition of how it is to be used with out of band DANE authentication. The base specification it seems is mechanism neutral. So the specifics of associated TLSA RR formats are only an issue for DANE clients, thus not unreasonably defined in a related new DANE WG document. > I think that the real stumbling block here is the attitude that "DANE > is only for PKIX", That may be true of some past history, but I've seen very little of that here in the last year a bit that I've been active in this group. DANE is not only for PKIX, but RFC 6698 as it stands does not currently describe associations to objects other than X.509 certificates. We'll address extending the definition to RPK in the ops draft, or a separate document if there's a strong preference for that. Since some of the content would overlap with related material in the ops draft, I'd prefer to not split this out. > Until and unless that attitude > is definitively repudiated by the WG in toto, I suspect that we will > continue to have problems reaching consensus whenever any IETF member > tries to use DNSSEC for a protocol (like Raw Public Keys) that does > not use PKIX certificates. We should not confuse the circumscribed scope of 6698, which looks today to be more a matter of caution to not overreach, rather than any specific bias in favour of a particular key management approach. There could have been some players who during the development of 6698 had an agenda in one direction or another, but the document itself is at worst too narrow, rather than biased. It also does not consider the opportunistic use-case and various other issues that would probably have further delayed adoption. RPK via "3 1 X" is a natural extension of 6698 to include in a 6698 update. If new certificate usages are needed in the future for more radically different use-cases, these can be added in separate documents or in any future comprehensive updates. Bottom line, I've not run into any difficulties agenda-driven conspiracies here yet. I'd like to add RPK support to Postfix at some point, once code for this is available (in OpenSSL). You'll likely find more resistance to RPK from some of the various toolkit maintainers (of OpenSSL, NSS, GnuTLS, ...) than on the DANE WG, where I expect RPK has a decent body of support. Like RPK DANE TLSA is a departure from the established order, and the two share common use-cases. -- Viktor. From nobody Thu Jun 5 18:22:53 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3CD1A0379 for ; Thu, 5 Jun 2014 18:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1mdFuhe0kD7 for ; Thu, 5 Jun 2014 18:22:50 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6BB31A0378 for ; Thu, 5 Jun 2014 18:22:50 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id s561MhBT021525 for ; Thu, 5 Jun 2014 18:22:43 -0700 Message-Id: <201406060122.s561MhBT021525@new.toad.com> To: dane@ietf.org In-reply-to: <20140605192533.GN27883@mournblade.imrryr.org> References: <20140602172922.GS27883@mournblade.imrryr.org> <20140603130839.GY27883@mournblade.imrryr.org> <20140604025535.GJ27883@mournblade.imrryr.org> <4e941a7fe4be00884d43cf848b30bec228883452@8b5064a13e22126c1b9329f0dc35b8915774b7c3.invalid> <20140605151145.GA27883@mournblade.imrryr.org> <20140605182415.GM27883@mournblade.imrryr.org> <20140605192533.GN27883@mournblade.imrryr.org> Comments: In-reply-to Viktor Dukhovni message dated "Thu, 05 Jun 2014 19:25:33 -0000." Date: Thu, 05 Jun 2014 18:22:43 -0700 From: John Gilmore Archived-At: http://mailarchive.ietf.org/arch/msg/dane/-_qH9rcAsL8LHMqP8mn2_tvtQG8 Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 01:22:51 -0000 > The safe version of the reverse change looks like: [I believe he's referring to upgrading a site from a TA-certified key to an end-entity-certified key.] > > Initial: > > IN TLSA 2 0 1 {legacy TA blob} > > Intermediate: > > IN TLSA 3 1 1 {EE association for legacy TA issued chain} > IN TLSA 3 1 1 {future EE blob} > > [switch keys] > > Final: > > IN TLSA 3 1 1 {new EE blob} > > Had the intermediate listed the original "2 0 1" for the legacy > chain, "oob" clients would lose. I don't understand this assertion. Viktor, why would "oob" (RPK) clients lose (fail?) if the domain name also included a TLSA 2 0 1 record? My belief is that the RPK client would ignore that 2 0 1 record, either because the client doesn't implement PKIX, or because the client is in the middle of an RPK TLS transaction and that record is not relevant to that transaction. This seems to be the central puzzle in trying to understand your concerns with mixing RPK and PKIX TLSA records, so if you could clearly explain why you think this case fails, it would help. John From nobody Thu Jun 5 18:30:21 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B092F1A037A for ; Thu, 5 Jun 2014 18:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TI_3hT6fPWHv for ; Thu, 5 Jun 2014 18:30:19 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D1EA1A0379 for ; Thu, 5 Jun 2014 18:30:19 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id s561UBBT021673 for ; Thu, 5 Jun 2014 18:30:11 -0700 Message-Id: <201406060130.s561UBBT021673@new.toad.com> To: dane@ietf.org In-reply-to: <20140605232509.GQ27883@mournblade.imrryr.org> References: <20140602022733.GK27883@mournblade.imrryr.org> <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> <20140602172922.GS27883@mournblade.imrryr.org> <20140603130839.GY27883@mournblade.imrryr.org> <20140604025535.GJ27883@mournblade.imrryr.org> <201406052227.s55MREBT016220@new.toad.com> <20140605232509.GQ27883@mournblade.imrryr.org> Comments: In-reply-to Viktor Dukhovni message dated "Thu, 05 Jun 2014 23:25:09 -0000." Date: Thu, 05 Jun 2014 18:30:11 -0700 From: John Gilmore Archived-At: http://mailarchive.ietf.org/arch/msg/dane/uJu1r4xja-puBjt2qzlyV2b_1MY Subject: Re: [dane] Servers which offer RPK but have no TLSA records for that key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 01:30:19 -0000 > You're saying that the server should know the sorry state of its > DNS TLSA RRs as seen by the client. This is likely impractical. > Servers just have key material and do TLS handshakes they are > DNSSEC/DANE agnostic. They have no idea what mechanism if any the > client is planning to use to authenticate the server's keys/certs. I agree that the server software should not be trying to figure out "TLSA RRs as seen by the client". The server may not have access to the same DNS servers as the client. The best that we can ask is that the system administrator of the server "keeps in mind" the public configuration of the TLSA records that relate to the server. I would be surprised to hear anyone in this group claiming that the TLS server can be configured completely independently of the TLSA records published in its domain. In particular, the keys used in the TLSA records and in the TLS server have to be coordinated so that they match. If they are not coordinated, DANE will never work with that TLS server. So, given that the people who configure the server must already know whether their domain is publishing TLSA records that authenticate their PKIX certificate, why is it such a stretch for the people who configure the server to also know whether their domain is publishing TLSA records that authenticate an RPK used by the server? John From nobody Thu Jun 5 18:41:05 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411A41A0382 for ; Thu, 5 Jun 2014 18:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJpUBEczmATn for ; Thu, 5 Jun 2014 18:41:02 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0459A1A0380 for ; Thu, 5 Jun 2014 18:41:02 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id s561esBT021883 for ; Thu, 5 Jun 2014 18:40:54 -0700 Message-Id: <201406060140.s561esBT021883@new.toad.com> To: dane@ietf.org In-reply-to: <20140605151145.GA27883@mournblade.imrryr.org> References: <20140602022733.GK27883@mournblade.imrryr.org> <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> <20140602172922.GS27883@mournblade.imrryr.org> <20140603130839.GY27883@mournblade.imrryr.org> <20140604025535.GJ27883@mournblade.imrryr.org> <4e941a7fe4be00884d43cf848b30bec228883452@8b5064a13e22126c1b9329f0dc35b8915774b7c3.invalid> <20140605151145.GA27883@mournblade.imrryr.org> Comments: In-reply-to Viktor Dukhovni message dated "Thu, 05 Jun 2014 15:11:45 -0000." Date: Thu, 05 Jun 2014 18:40:54 -0700 From: John Gilmore Archived-At: http://mailarchive.ietf.org/arch/msg/dane/_umKqDdYPeOYYsyfHBzJjRV15QE Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 01:41:03 -0000 > Finally, the WG could decide that servers which publish U/S/M > combinations in their TLSA RRset that contain only future or only > past keys are "misconfigured", and that servers SHOULD NOT do that. I don't understand how any crypto protocol can succeed when it authenticates only past or future keys, not the keys in present use. Can you explain why you think such a server is NOT misconfigured? Or perhaps you will agree that this is misconfiguration, but you think that for some reason that you can state, many people will foolishly misconfigure their servers this way, such that the protocol should gracefully handle that "common misconfiguration" case? Struggling to understand, John From nobody Thu Jun 5 18:54:17 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5571A0397 for ; Thu, 5 Jun 2014 18:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-aj8mdumC_x for ; Thu, 5 Jun 2014 18:54:15 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5CB01A0395 for ; Thu, 5 Jun 2014 18:54:15 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id s561s8BT022125 for ; Thu, 5 Jun 2014 18:54:08 -0700 Message-Id: <201406060154.s561s8BT022125@new.toad.com> To: dane@ietf.org In-reply-to: <20140605232509.GQ27883@mournblade.imrryr.org> References: <20140602022733.GK27883@mournblade.imrryr.org> <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> <20140602172922.GS27883@mournblade.imrryr.org> <20140603130839.GY27883@mournblade.imrryr.org> <20140604025535.GJ27883@mournblade.imrryr.org> <201406052227.s55MREBT016220@new.toad.com> <20140605232509.GQ27883@mournblade.imrryr.org> Comments: In-reply-to Viktor Dukhovni message dated "Thu, 05 Jun 2014 23:25:09 -0000." Date: Thu, 05 Jun 2014 18:54:08 -0700 From: John Gilmore Archived-At: http://mailarchive.ietf.org/arch/msg/dane/nyUQhQnZe4LAioCzO-CeFFBUKq0 Subject: Re: [dane] Servers which offer RPK but have no TLSA records for that key X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 01:54:16 -0000 > There are also timing subtleties, are TLSA records located before > the TLSA handshake or during the handshake once the server provides > key material. If the latter (which I don't recommend... It is my belief that the reason we have no web browsers that support DANE is because it would likely reduce the latency of web transactions that involve https. Browser vendors compete on how quickly they can go from the user typing "eff.org" to showing the EFF home page. They use all kinds of tricks (like doing DNS lookups on the part before the first slash, while the user is still typing the rest of the URL; or matching on the URLs of previous visits from this browser), to reduce that latency. If clients that support DANE and RPK require that a full DNSSEC TLSA lookup begins and ends before the client can start any TLS negotiation -- even to sites that are not using raw public keys -- then this latency will increase. Which means even less chance of practical adoption of DANE (and less chance of practical adoption of RPK) in the real world web browsers. That's why I am trying to avoid such a requirement. DANE is a good idea, but to the extent that we require them to be slower than the currently widespread TLS implementations, DANE may never be adopted in realtime clients that have a user watching them run. John From nobody Thu Jun 5 19:13:33 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3044D1A03B6 for ; Thu, 5 Jun 2014 19:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVcWv0eoOyNb for ; Thu, 5 Jun 2014 19:13:31 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5656C1A03B5 for ; Thu, 5 Jun 2014 19:13:31 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id s562DOBT022813 for ; Thu, 5 Jun 2014 19:13:24 -0700 Message-Id: <201406060213.s562DOBT022813@new.toad.com> To: dane@ietf.org In-reply-to: <20140605235915.GR27883@mournblade.imrryr.org> References: <20140605235915.GR27883@mournblade.imrryr.org> Comments: In-reply-to Viktor Dukhovni message dated "Thu, 05 Jun 2014 23:59:16 -0000." Date: Thu, 05 Jun 2014 19:13:24 -0700 From: John Gilmore Archived-At: http://mailarchive.ietf.org/arch/msg/dane/srGavItSr5Lcdv4m5oqXc1mkT-M Subject: Re: [dane] RPK use-case high level problem statement X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 02:13:32 -0000 > Perhaps we can at least agree on the high-level problem statement: > > 1. Some clients will support both X.509 and RPK TLS handshakes, > and will opportunistically negotiate RPK as an optimization. Agreed. > 2. Some subset of those clients with use DANE authentication to > authenticate whichever of X.509 or RPK is negotiated. Agreed (s/with/will/). > 3. Some subset of servers will have TLSA RRsets during transition > states, not currently defined as "misconfigured", such that > X.509 DANE TLSA authentication works, but RPK DANE TLSA > authentication fails, because the RPK-compatible TLSA RRs > match only past or future keys. I do not agree with this and am still awaiting a communication from you about why you think this will occur. Normally, key transitions are done by moving from publishing "current" keys, to "current/future" keys by adding the future keys. Those then become "past/current" keys when the server's key itself changes, and then are moved to "current" keys by dropping the past keys. At no point do the TLSA records in a key rollover include only "past/future" keys. TLS would fail if they did so. > 4. Somebody (client, server or both) should do something to avoid > unnecessary application failure under the above conditions. Disagree, based on not seeing why 3 is anything but a mistake made by naive or unskilled administrators. > 5. We should probably write-up the potential problem cases, > and spell out client and server responsibilities and strategies > to avoid the problem cases. Either client is conservative > and avoids opportunistic RPK, or server avoids publishing > potentially problematic RRsets or both. We should probably > not recommend "retries" see [Footnote], but for some clients > retries might be a viable strategy. I thought we had already done that by explaining in detail how to do key rollovers. See Appendix A.4 of RFC 6698. If you try to change keys and you do it wrong, your service will become inaccessible. The cure is to do it right, not to contort the protocol. PS- you do the same rollover process when changing the "A" record of your server. This is not specific to TLSA, DANE, DNSSEC, or RPK. Would you argue that the protocol should somehow accommodate administrators who, while trying to change their A record from 1.2.3.4 to 5.6.7.8, somehow foolishly publish 1.2.3.4 and 9.10.11.12? Of course when the server at 1.2.3.4 goes down, all attempts to connect will be broken. The server at 5.6.7.8 will be sitting there ready, but nobody will connect to it. There is no recovery until the "A" records are corrected. The TLSA situation is directly analogous. John From nobody Thu Jun 5 19:31:25 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317D51A03BF for ; Thu, 5 Jun 2014 19:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ez3BupBxBVlF for ; Thu, 5 Jun 2014 19:31:22 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88DFE1A03BD for ; Thu, 5 Jun 2014 19:31:22 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id AB1E12AAB4F; Fri, 6 Jun 2014 02:31:14 +0000 (UTC) Date: Fri, 6 Jun 2014 02:31:14 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140606023114.GT27883@mournblade.imrryr.org> References: <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> <20140602172922.GS27883@mournblade.imrryr.org> <20140603130839.GY27883@mournblade.imrryr.org> <20140604025535.GJ27883@mournblade.imrryr.org> <4e941a7fe4be00884d43cf848b30bec228883452@8b5064a13e22126c1b9329f0dc35b8915774b7c3.invalid> <20140605151145.GA27883@mournblade.imrryr.org> <201406060140.s561esBT021883@new.toad.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201406060140.s561esBT021883@new.toad.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/uVmO7AjIkK_LDGhjWdWuD0MVduo Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 02:31:24 -0000 On Thu, Jun 05, 2014 at 06:40:54PM -0700, John Gilmore wrote: > > Finally, the WG could decide that servers which publish U/S/M > > combinations in their TLSA RRset that contain only future or only > > past keys are "misconfigured", and that servers SHOULD NOT do that. > > I don't understand how any crypto protocol can succeed when it > authenticates only past or future keys, not the keys in present use. Not *only*, rather concurrently both present and either past or future keys (possibly all three, but that's generally unnecessary). > Can you explain why you think such a server is NOT misconfigured? During administrative changes in the TLSA RRset, given the asynchronous nature of DNS data propagation, one needs to insert future data before removing present data. Once the new keys are in place, one can remove past data. At various stages clients see one of: * (old) present * (old) present + (new) future * (old) past + (new) present * (new) present No *proper* subset of the TLSA RRs is currently mandated to contain a record matching the server chain. Only the *complete* RRset of a correctly configured server must contain *at least one* matching record. If the usage/selector/mtype combinations for "old" and "new" chains are not identical (one to one correspondence) then a client that employs a proper subset of the TLSA RRs (say because RPK is only capable of matching "3 1 X"), then it might be that this subset contains only past or only future keys and authentication fails. > Or > perhaps you will agree that this is misconfiguration, but you think > that for some reason that you can state, many people will foolishly > misconfigure their servers this way, such that the protocol should > gracefully handle that "common misconfiguration" case? No it is not misconfiguration as currently defined. We could publish operational requirements that make it a misconfiguration or at least a violation of best practice. Is that enough for clients to throw caution to the wind and assume consistent BCP TLSA RR practices on the server side? Perhaps it is safer for the client to forgo an optimization and just negotiate X.509 in some edge cases that will be rare, but not unlikely enough to not cause people real support issues. The best example for PRK is a transition from a current "2 0 1" TLSA RRs to future "3 1 1" RR. The administrator needs to know to do: Initial: IN TLSA 2 0 1 {old TA} Intermediate: IN TLSA 3 1 1 {switch to old leaf} IN TLSA 3 1 1 {new leaf} Final: IN TLSA 3 1 1 {new leaf} rather than the more naively obvious: Initial: IN TLSA 2 0 1 {old TA} Intermediate: IN TLSA 2 0 1 {old TA} IN TLSA 3 1 1 {new leaf} Final: IN TLSA 3 1 1 {new leaf} because here, until the new leaf is deployed after the original TTL expires, PRK clients might conclude that it is safe to use PRK, but it is not because the server's current (old) key can't be matched via an EE SPKI association. Asking the server operator to disable PRK (which be negotiated automatically in some toolkit whenever the client asks just because the server also has the feature) when the published TLSA records might not be PRK friendly is I think a greater burden than asking for care in how DNS records are updated. This is an operational issue for both client and server, someone has to do the heavy lifting. I think the client should not be entirely off the hook, because PRK for clients that support both X.509 and PRK is an optional optimization. The impact will be low, because servers that support "3 1 X" will most often only support "3 1 X", and the "mixed" RRsets will be very rare. -- Viktor. From nobody Thu Jun 5 19:37:39 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66EF81A03D9 for ; Thu, 5 Jun 2014 19:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uz4wF6jdLGnw for ; Thu, 5 Jun 2014 19:37:26 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B942E1A0435 for ; Thu, 5 Jun 2014 19:37:25 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EC2292AAB4F; Fri, 6 Jun 2014 02:37:18 +0000 (UTC) Date: Fri, 6 Jun 2014 02:37:18 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140606023718.GU27883@mournblade.imrryr.org> References: <20140605235915.GR27883@mournblade.imrryr.org> <201406060213.s562DOBT022813@new.toad.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201406060213.s562DOBT022813@new.toad.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/0mYcaaKlPhw3qO6HqHhusAdc-tY Subject: Re: [dane] RPK use-case high level problem statement X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 02:37:29 -0000 On Thu, Jun 05, 2014 at 07:13:24PM -0700, John Gilmore wrote: > > 3. Some subset of servers will have TLSA RRsets during transition > > states, not currently defined as "misconfigured", such that > > X.509 DANE TLSA authentication works, but RPK DANE TLSA > > authentication fails, because the RPK-compatible TLSA RRs > > match only past or future keys. > > I do not agree with this and am still awaiting a communication from > you about why you think this will occur. Normally, key transitions > are done by moving from publishing "current" keys, to "current/future" > keys by adding the future keys. Those then become "past/current" keys > when the server's key itself changes, and then are moved to "current" > keys by dropping the past keys. Done under separate cover. Some key rotation scenarios involve changes from TA issued keys to self-issued keys or the converse. Or sometimes even simply a change from "3 0 1" with old keys to a deliberate "3 1 1" with new keys (to make them RPK compatible). > At no point do the TLSA records in a key rollover include only > "past/future" keys. TLS would fail if they did so. The total set of TLSA RRs indeed always contains present keys when the server is not misconfigured. But there is (today) no guarantee that the "3 1 X" subset of the TLSA RRset contains any present keys. I am proposing to document this issue. We've not yet agreed on who's responsible for the work-around (client, server, both). -- Viktor. From nobody Thu Jun 5 23:56:42 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2681A02F5 for ; Thu, 5 Jun 2014 23:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQ_Pudwl5uhr for ; Thu, 5 Jun 2014 23:56:37 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 528BC1A0276 for ; Thu, 5 Jun 2014 23:56:37 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 118911DDEC; Fri, 6 Jun 2014 06:56:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1402037787; bh=+zJKxKVPIcxMUWzfLPjz7BKZ6bHTsyLz/C2W6yQ+MUk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ffygvvm1sU8mZ2hb1W3F4XEH/EniFqIuhc3nDkWXr+VJpIRZKJ8gMI1GJ/Eor21Vj leMaTGo0Nsw/12H3lNdJb1EXYxdZB+mUQJ6ZqarMWCtbNBMJQHFgy5+Y10dcWzv7es u/nCwsNp/EksZG8ezv3iCin5OvnMKS4Z2C+HVc38= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 2FE766001E; Fri, 6 Jun 2014 06:54:01 +0000 (UTC) From: James Cloos To: Viktor Dukhovni In-Reply-To: <20140605235915.GR27883@mournblade.imrryr.org> (Viktor Dukhovni's message of "Thu, 5 Jun 2014 23:59:16 +0000") References: <20140605235915.GR27883@mournblade.imrryr.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 06 Jun 2014 02:54:01 -0400 Message-ID: Lines: 44 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140606:viktor1dane@dukhovni.org::J94t9AO4dcM3rAaP:000000000000000000000000000000000000MPmBn X-Hashcash: 1:30:140606:dane@ietf.org::GxMpRXnTYojU3Qcl:000LYrGL Archived-At: http://mailarchive.ietf.org/arch/msg/dane/xuCOlBkAunAgdrhPhWlfVdLgF-g Cc: dane@ietf.org Subject: Re: [dane] RPK use-case high level problem statement X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 06:56:39 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> 3. Some subset of servers will have TLSA RRsets during transition VD> states, not currently defined as "misconfigured", such that VD> X.509 DANE TLSA authentication works, but RPK DANE TLSA VD> authentication fails, because the RPK-compatible TLSA RRs VD> match only past or future keys. Now I see why/where we disagree. In the case where the server's current key cannot be verified by a RPK- compatible TLSA, and where the server publishes TLSA at all, it is a mis-configuration to permit the server to negotiate RPK. Just because a client sends the RPK extension does not mean that the server must or will agree. If the admin knows that no published RPK-compatible TLSA will verify the key which the server currently would send to an RPK client, said admin SHOULD configure the server to refuse the RPK extension. Servers which expect their RPK clients to authenticate the SPKI via LDAP or pre-shared knowledge SHOULD NOT publish TLSA which cannot verify the current SPKI without also publishing TLSA which can do so. (This is why the last paragraph is only a SHOULD rather than a MUST.) Servers which expect their RPK clients to authenticate the SPKI via TLSA MUST publish at least one TLSA which can verify the current SPKI. It seems extremely unlikely to me that, as RPK support is added to the various TLS libraries, that it will be enabled by default. It is vastly more likely that explicit configuration will be required by any server software to enable support for RPK. Perhaps even requiring that the SPKI to be sent to RPK clients be in a file outside of any 509 container, rather than auto-extracted as needed. The likelyhood, therefore, of servers suddenly negotiating RPK unbeknownst to their admins is negligible. Admins who want to enable RPK and want to support DANE verification of the bare SPKIs should be expected always to include a suitable record in their TLSA set. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Fri Jun 6 04:56:21 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DB21A004A for ; Fri, 6 Jun 2014 04:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zbgSfRd0WBK for ; Fri, 6 Jun 2014 04:56:18 -0700 (PDT) Received: from proxima.lp0.eu (proxima.lp0.eu [IPv6:2001:8b0:ffea:0:205:b4ff:fe12:530]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6781A0439 for ; Fri, 6 Jun 2014 04:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=arlott.org; s=exim; h=Content-Transfer-Encoding:Content-Type:MIME-Version:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=XKrXSTTStlA6MCPNwDTQexIneimmQzijJZ2tGPnLxo8=; b=XX0OsocD8YJ/b0Fvs1B7Jr3zLe3zyJ2f40aWSQs/9tBK8mrqsLc6z55mSef4rZI/yQiqsX48Hlgfaz/yE7oVK3NgfuIOSWU2gVSssj6vNl2FXzOamigFNwlhZHCLMObZNxor+dB05ct/4aIgFaysh4MoWyIaaKpcDl4k8FkwJ4WeQAd6IDFV0envLPSKGDTPOPao4VBSZrErSP9NQwwSpD0V2woloExYb2biS4eOF5Y00V5Sj38/PsmlM1LW1/gpmlRD7ZlbzPofqEDplKIF6++4uq2LAF2C1/GZe8blyq87Ak7j2Nz3o8yNkJrTOC9BNkhDWH9bo9FmTrPUS2sk8Q==; Received: from lp0_webmail by proxima.lp0.eu with local id 1Wsskh-0004HJ-EA for dane@ietf.org; Fri, 06 Jun 2014 12:56:08 +0100 Received: from simon by proxima.lp0.eu with https; Fri, 6 Jun 2014 12:56:07 +0100 Message-ID: <31f4893c1034c6032e2ef9a09108c2f696fb34de@8b5064a13e22126c1b9329f0dc35b8915774b7c3.invalid> In-Reply-To: <20140606023718.GU27883@mournblade.imrryr.org> References: <20140605235915.GR27883@mournblade.imrryr.org> <201406060213.s562DOBT022813@new.toad.com> <20140606023718.GU27883@mournblade.imrryr.org> Date: Fri, 6 Jun 2014 12:56:07 +0100 From: "Simon Arlott" To: dane@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/dane/tQOU2dXqFYLsG4f1mgQqV-Xr8V4 Subject: Re: [dane] RPK use-case high level problem statement X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 11:56:20 -0000 On Fri, June 6, 2014 03:37, Viktor Dukhovni wrote: > On Thu, Jun 05, 2014 at 07:13:24PM -0700, John Gilmore wrote: >> At no point do the TLSA records in a key rollover include only >> "past/future" keys. TLS would fail if they did so. > > The total set of TLSA RRs indeed always contains present keys when > the server is not misconfigured. But there is (today) no guarantee > that the "3 1 X" subset of the TLSA RRset contains any present > keys. I am proposing to document this issue. We've not yet agreed > on who's responsible for the work-around (client, server, both). If a server operator is moving from RPK-only to PKIX-only then they MUST (with all the necessary TTL considerations for each step): 1. Add support for PKIX on the server and in the TLSA RRs 2. Remove support for RPK in the TLSA RRs 3. Remove support for RPK on the server In my opinion the server operator is responsible. They also MUST NOT provide support for RPK unless they have configured SPKI TLSA RRs, otherwise a PKIX+RPK client will prefer RPK and fail. -- Simon Arlott From nobody Fri Jun 6 07:52:18 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114931A0496 for ; Fri, 6 Jun 2014 07:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z91PhlILTr3Q for ; Fri, 6 Jun 2014 07:52:14 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73CEE1A049E for ; Fri, 6 Jun 2014 07:52:14 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 25D572AB20C; Fri, 6 Jun 2014 14:52:07 +0000 (UTC) Date: Fri, 6 Jun 2014 14:52:07 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140606145207.GW27883@mournblade.imrryr.org> References: <20140605235915.GR27883@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.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/L6RtSRq11YZWVU5r1rBp5vDGxeI Subject: Re: [dane] RPK use-case high level problem statement X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 14:52:17 -0000 On Fri, Jun 06, 2014 at 02:54:01AM -0400, James Cloos wrote: > >>>>> "VD" == Viktor Dukhovni writes: > > VD> 3. Some subset of servers will have TLSA RRsets during transition > VD> states, not currently defined as "misconfigured", such that > VD> X.509 DANE TLSA authentication works, but RPK DANE TLSA > VD> authentication fails, because the RPK-compatible TLSA RRs > VD> match only past or future keys. > > Now I see why/where we disagree. > > In the case where the server's current key cannot be verified by a RPK- > compatible TLSA, and where the server publishes TLSA at all, it is a > mis-configuration to permit the server to negotiate RPK. > > Just because a client sends the RPK extension does not mean that the > server must or will agree. Indeed I was/am expecting some TLS implementations to automatically negotiate RPK and use keys extracted from the leaf certificate (far simpler in mixed environments than configuring separate bare SPKI objects). If RPK only gets enabled: * Toolkit implements RPK, off by default * Application enables RPK support, off by default * Administrator enables RPK (when not in conflict with TLSA, ...) Then it will take quite some time before there's any noticeable RPK deployment even in the presence of DANE TLSA records than can authenticate RPK. The alternative model is: * Toolkit implements RPK, on by default in servers. * Application may be updated to allow disabling of RPK support. * Server administrator publishes "3 1 X" TLSA RRs. * Client sees "pure" "3 1 X" TLSA RRset, enables RPK, and off we go. The extension deploys itself "organically" as implementations are adopted. However, if that's the model, then TLSA RRset transitions need to be managed with care, or clients should be cautious when automaticaly enabling RPK or better yet both. I am planning to *recommend* a server BCP of "make sure each and every U/S/M matches a current keyset" strategy anyway, there are non-RPK reasons to do that anyway. So the question with respect to RPK is whether it is: * The server's responsibility to only enable it while publishing compatible TLSA records (assuming the server publishes TLSA records), leading to much slower RPK deployment, but closing the "mixed TLSA" exposure. OR * The server's responsibility to carefully publish TLSA records in such a way that no U/S/M subset is purely past/future, also closing the exposure. OR * The client's responsibility to be cautious in the face of "mixed" TLSA records. If the consensus is that PRK enablement in server applications needs to be explicit, and it needs to be off by default, then this should I think be published in the new RPK RFC. Toolkit implementors adding server-sie code for the extension need to know that it is not safe to enable by default. > It seems extremely unlikely to me that, as RPK support is added to the > various TLS libraries, that it will be enabled by default. It is vastly > more likely that explicit configuration will be required by any server > software to enable support for RPK. Perhaps even requiring that the > SPKI to be sent to RPK clients be in a file outside of any 509 container, > rather than auto-extracted as needed. I don't want to rely on happy accidents, if it is not spelled out, all bets are off. -- Viktor. From nobody Fri Jun 6 08:25:40 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060FE1A011D for ; Fri, 6 Jun 2014 08:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzCYgOaDP62G for ; Fri, 6 Jun 2014 08:25:35 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 097D01A00F6 for ; Fri, 6 Jun 2014 08:25:34 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D9394800C9 for ; Fri, 6 Jun 2014 11:25:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1402068326; bh=oM2lrpZq0rDbMIy4AGckKJmr+220t8lvg5SCsyu6Fgk=; h=Date:From:To:Subject:In-Reply-To:References; b=q5mqbRQcEnqhqeXVSoXKf554Jmr5YfYn7LCFnJZcg+g4NdQuGR5D2rzXRXIvpkEcr AFHSxK8BDL8y2p5LTGcCx6G6eiX/3WIm4FJp9jyFGg/pZEPHDQVutVyq58+A7vL7LK 31SlSOtwZKpzCScYI8llnVWIlSw1q/OU3LH1UxWw= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s56FPQwt019911 for ; Fri, 6 Jun 2014 11:25:26 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 6 Jun 2014 11:25:26 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20140606011121.GS27883@mournblade.imrryr.org> Message-ID: References: <201405290805.s4T85HBT008757@new.toad.com> <08E92113-6C1F-4BD3-8846-4B117FA1AC1E@ogud.com> <201406060021.s560LiBT019821@new.toad.com> <20140606011121.GS27883@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Rs3v6cIsC-CCYbXTHJ_JE19Sq0w Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 15:25:37 -0000 On Fri, 6 Jun 2014, Viktor Dukhovni wrote: > You'll find that there is little support for RPK formats other than > "3 1 X", despite a small number of suggestions to the contrary. A > consensus around "3 1 X" is I think a safe bet. It is not a safe bet. We only need one external requirement, like PCI-DSS or the EV consortium to start dictating one has to publish and match a full certificate to get their goodies like a green url bar. Then you would need a mix of TLSA types to support both the PKIX/CABforum/EV universe and raw public keys. And by not allowing that, or by stating a mixed TLSA RRset means sacrificing raw public keys, the result would force everyone to be stuck with full PKIX validation. In other words, your 'optimization' can be harmful. You're still welcome to code that into your software. But you can't standardize it. Paul From nobody Fri Jun 6 08:35:13 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53A21A01E0 for ; Fri, 6 Jun 2014 08:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igu4bzngt7UP for ; Fri, 6 Jun 2014 08:35:11 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1FB41A01CC for ; Fri, 6 Jun 2014 08:35:11 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A2FDE800C9 for ; Fri, 6 Jun 2014 11:35:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1402068904; bh=YNn0HKduYUr71u2Z6dBKOQgvmSBcCo00k+kTSnPRMk4=; h=Date:From:To:Subject:In-Reply-To:References; b=Y7c6UT7owIM8P0oe2uHqyYSHp7nFVfaRekhmGNJlvpbsPHcq4Z22g4FpneOmxupT/ a88LQu31hQChnzJiNw0jfMAk/QgJ1x6KgrgmQhes9FW1SA94LPQRSjfGz3o4IpqcN8 v1ylNA/dRoj+xJSaKApbFrc/mcpdcZ32VsFjo5WU= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s56FZ4mv020136 for ; Fri, 6 Jun 2014 11:35:04 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 6 Jun 2014 11:35:04 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20140606023114.GT27883@mournblade.imrryr.org> Message-ID: References: <538C86C7.8000805@cs.tcd.ie> <20140602145215.GP27883@mournblade.imrryr.org> <20140602172922.GS27883@mournblade.imrryr.org> <20140603130839.GY27883@mournblade.imrryr.org> <20140604025535.GJ27883@mournblade.imrryr.org> <4e941a7fe4be00884d43cf848b30bec228883452@8b5064a13e22126c1b9329f0dc35b8915774b7c3.invalid> <20140605151145.GA27883@mournblade.imrryr.org> <201406060140.s561esBT021883@new.toad.com> <20140606023114.GT27883@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/W7fdhaa_Uc_SyO9-qEDTG20V3yA Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 15:35:13 -0000 On Fri, 6 Jun 2014, Viktor Dukhovni wrote: > The best example for PRK is a transition from a current "2 0 1" TLSA > RRs to future "3 1 1" RR. The administrator needs to know to do: > > Initial: > IN TLSA 2 0 1 {old TA} > > Intermediate: > IN TLSA 3 1 1 {switch to old leaf} > IN TLSA 3 1 1 {new leaf} > > Final: > IN TLSA 3 1 1 {new leaf} > > rather than the more naively obvious: > > Initial: > IN TLSA 2 0 1 {old TA} > > Intermediate: > IN TLSA 2 0 1 {old TA} > IN TLSA 3 1 1 {new leaf} > > Final: > IN TLSA 3 1 1 {new leaf} > > because here, until the new leaf is deployed after the original > TTL expires, PRK clients might conclude that it is safe to use PRK, > but it is not because the server's current (old) key can't be > matched via an EE SPKI association. Okay, I understand this example now and your desire to not mixup TLSA types. However, the operations document could simply advise not to combine a key rollover with a usage/type/selector rollover at once, which seems more appropriate than banning all other valid scenario's that mixup type such as: IN TLSA 2 0 1 {current TA} IN TLSA 3 1 1 {current leaf} Paul From nobody Fri Jun 6 08:44:29 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D921A00F6 for ; Fri, 6 Jun 2014 08:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkMW_CRnRWof for ; Fri, 6 Jun 2014 08:44:24 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E1231A01DE for ; Fri, 6 Jun 2014 08:44:24 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 494BE2AAB4F; Fri, 6 Jun 2014 15:44:17 +0000 (UTC) Date: Fri, 6 Jun 2014 15:44:17 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140606154417.GY27883@mournblade.imrryr.org> References: <201405290805.s4T85HBT008757@new.toad.com> <08E92113-6C1F-4BD3-8846-4B117FA1AC1E@ogud.com> <201406060021.s560LiBT019821@new.toad.com> <20140606011121.GS27883@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.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/4LzCkxJYuDjMBBJkmqphMBUQBLk Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 15:44:26 -0000 On Fri, Jun 06, 2014 at 11:25:26AM -0400, Paul Wouters wrote: > On Fri, 6 Jun 2014, Viktor Dukhovni wrote: > > >You'll find that there is little support for RPK formats other than > >"3 1 X", despite a small number of suggestions to the contrary. A > >consensus around "3 1 X" is I think a safe bet. A safe bet that this becomes the standard encoding of RPK TLSA records. > It is not a safe bet. We only need one external requirement, like PCI-DSS > or the EV consortium to start dictating one has to publish and match a > full certificate to get their goodies like a green url bar. Which little bearing on how to publish the RPK records. > Then you > would need a mix of TLSA types to support both the PKIX/CABforum/EV > universe and raw public keys. Encoded as "3 1 X" which was the limited scope of that comment. > And by not allowing that, or by stating > a mixed TLSA RRset means sacrificing raw public keys, the result would > force everyone to be stuck with full PKIX validation. That's a separate question than the one under discussion. The hypothetical seems rather conspiratorial. In a conspiracy more likely these various actors, if they were acting to thwart DANE adoption, would simply erect barriers to all use of DANE TLSA. (Perhaps they're doing that already). Just preventing use of RPK seems like a rather modest goal if DANE "3 0 1" and "2 0 1" are are left standing and become popular. You can at least relax in my case, I am not part of any X.509 cospiracy. :-) Rather, I just work to be sure that things actually work in all cases, including the corner ones. > In other words, your 'optimization' can be harmful. You're still welcome > to code that into your software. But you can't standardize it. Just to be clear I see RPK as an optimization, and my suggested suppression of RPM with mixed TLSA RRs as forgoing the optimization. However, we should tackle this point in the new thread I started, after refocusing the arguement, it seems to be making better progress. -- Viktor. From nobody Fri Jun 6 09:00:16 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FA21A009C for ; Fri, 6 Jun 2014 09:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jID2JzY0ouzf for ; Fri, 6 Jun 2014 09:00:12 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E78691A0080 for ; Fri, 6 Jun 2014 09:00:11 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B682F2AAB4F; Fri, 6 Jun 2014 16:00:03 +0000 (UTC) Date: Fri, 6 Jun 2014 16:00:03 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140606160003.GZ27883@mournblade.imrryr.org> References: <20140602172922.GS27883@mournblade.imrryr.org> <20140603130839.GY27883@mournblade.imrryr.org> <20140604025535.GJ27883@mournblade.imrryr.org> <4e941a7fe4be00884d43cf848b30bec228883452@8b5064a13e22126c1b9329f0dc35b8915774b7c3.invalid> <20140605151145.GA27883@mournblade.imrryr.org> <201406060140.s561esBT021883@new.toad.com> <20140606023114.GT27883@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.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/fWmagrSudxOQAqnZqQAo6-DWbIY Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 16:00:13 -0000 On Fri, Jun 06, 2014 at 11:35:04AM -0400, Paul Wouters wrote: > Okay, I understand this example now and your desire to not mixup TLSA > types. However, the operations document could simply advise not to > combine a key rollover with a usage/type/selector rollover at once, > which seems more appropriate than banning all other valid scenario's > that mixup type such as: > > IN TLSA 2 0 1 {current TA} > IN TLSA 3 1 1 {current leaf} I am not suggesting to ban mixed TLSA RRs. Rather, I was suggesting that clients encountering mixed TLSA RRs might want to avoid RPK, but we'll handle that question in the other thread. To your point about transitions and changing one thing at a time, yes that's the right high-level description of the BCP TLSA RRset change strategy. Keep all other things fixed and apply one of: * Add future keys presented with the same U/S/M combinations as existing keys. * Remove all U/S/M combinations for legacy keys leaving only current keys. * Add new U/S/M combinations that match the same keys as existing U/S/M combinations. * Remove all records with a given U/S/M combination. * Or combine the two previous and replace one U/S/M combination with another, while still matching the same set of keys. The required invariant is that at all times each currently published, or not yet expired from DNS caches, U/S/M combination comtains at least one record that matches the current server keys. Whether or not client RPK behaviour includes any work-arounds for "mixed" TLSA RRsets, the above should be a BCP for server TLSA RRset management. -- Viktor. From nobody Sat Jun 7 02:05:29 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA011A032C for ; Sat, 7 Jun 2014 02:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ld34LYsA8_hh for ; Sat, 7 Jun 2014 02:05:24 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB4DA1A0329 for ; Sat, 7 Jun 2014 02:05:24 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 571DB1DEED; Sat, 7 Jun 2014 09:05:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1402131915; bh=6chrVqS4IaMYW+HboWzU5hz8EvwOaVD3rRR2fDu6tK0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=GnSNwMTZE95xhX7+JFtwaJX3nDDONVBccXVKw4NrMQI3mhBiTPnfIRbJyR29lsFse QpbvkhVFTX22vTSGHx1nblNgG5cNx8uNZITuGwEzuRa4JVbkUapHzbxaDcgwlffVTW 60ujGKSxKcctJUEFJ3IJfHKhLBRdiFn8U1A2hsnk= Received: by carbon.jhcloos.org (Postfix, from userid 500) id A75CD6001E; Sat, 7 Jun 2014 09:01:58 +0000 (UTC) From: James Cloos To: Viktor Dukhovni In-Reply-To: <20140606145207.GW27883@mournblade.imrryr.org> (Viktor Dukhovni's message of "Fri, 6 Jun 2014 14:52:07 +0000") References: <20140605235915.GR27883@mournblade.imrryr.org> <20140606145207.GW27883@mournblade.imrryr.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sat, 07 Jun 2014 05:01:58 -0400 Message-ID: Lines: 41 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140607:viktor1dane@dukhovni.org::JepGv4W0B/NapMku:00000000000000000000000000000000000035pAu X-Hashcash: 1:30:140607:dane@ietf.org::FFEYwwKfXh4Gbvxm:0000B2DG Archived-At: http://mailarchive.ietf.org/arch/msg/dane/JaJXLKHPf5sH4nSA2VxFwzL5APo Cc: dane@ietf.org Subject: Re: [dane] RPK use-case high level problem statement X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 09:05:27 -0000 >>>>> "VD" == Viktor Dukhovni writes: VD> Indeed I was/am expecting some TLS implementations to automatically VD> negotiate RPK and use keys extracted from the leaf certificate (far VD> simpler in mixed environments than configuring separate bare SPKI VD> objects). I tend to expect crypto authors to be more conservative in enabling new extensions by default. Heartbleed, of course, demonstrates that such conservatism isn't always there.... If it does get added to the libs enabled by default, w/o the need for application buy in, things will be radically different than what I expected. VD> I am planning to *recommend* a server BCP of "make sure each and VD> every U/S/M matches a current keyset" strategy anyway, there are VD> non-RPK reasons to do that anyway. Such a recomendation is most welcome. VD> So the question with respect to RPK is whether it is: VD> * The server's responsibility to carefully publish TLSA records VD> in such a way that no U/S/M subset is purely past/future, also VD> closing the exposure. That would be my preference. VD> If the consensus is that PRK enablement in server applications VD> needs to be explicit, and it needs to be off by default, I wasn't advocating either way. Just anticipating that lib and app authors would be conservative about the new extension. And I doubt any will care whether an rfc demands by default or only when configured. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Sat Jun 7 09:54:48 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152441A00FD for ; Sat, 7 Jun 2014 09:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqBTdGfT7bHY for ; Sat, 7 Jun 2014 09:54:45 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CAE31A00FA for ; Sat, 7 Jun 2014 09:54:45 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id ECF842AB221; Sat, 7 Jun 2014 16:54:36 +0000 (UTC) Date: Sat, 7 Jun 2014 16:54:36 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140607165436.GB27883@mournblade.imrryr.org> References: <20140605235915.GR27883@mournblade.imrryr.org> <20140606145207.GW27883@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.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/3rB2sPFEVdNwNaaNDqR8IWtE9XU Subject: Re: [dane] RPK use-case high level problem statement X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 07 Jun 2014 16:54:47 -0000 On Sat, Jun 07, 2014 at 05:01:58AM -0400, James Cloos wrote: > VD> Indeed I was/am expecting some TLS implementations to automatically > VD> negotiate RPK and use keys extracted from the leaf certificate (far > VD> simpler in mixed environments than configuring separate bare SPKI > VD> objects). > > I tend to expect crypto authors to be more conservative in enabling new > extensions by default. Heartbleed, of course, demonstrates that such > conservatism isn't always there.... > > If it does get added to the libs enabled by default, w/o the need for > application buy in, things will be radically different than what I > expected. I was expecting at least some implementations to be on by default on the server, and off by default on the client. Then, when the client asks, and the server is capable, RPK would be used. If no specification requires any particular default mode of operation, then likely neither you nor I have any rational basis for our expectations. > VD> * The server's responsibility to carefully publish TLSA records > VD> in such a way that no U/S/M subset is purely past/future, also > VD> closing the exposure. > > That would be my preference. OK, when I get a chance, I'll write up the desired invariant and strategies for ensuring it is met in the "ops" draft. Is there anyone who now or still supports my original suggestion that clients ought to be cautious in the face of "mixed" TLSA records? Should the above server TLSA record update strategy be a BCP or a mandate (RECOMMENDED vs. SHOULD)? > VD> If the consensus is that PRK enablement in server applications > VD> needs to be explicit, and it needs to be off by default, > > I wasn't advocating either way. Just anticipating that lib and app > authors would be conservative about the new extension. > > And I doubt any will care whether an rfc demands by default or only when > configured. Whether or not toolkit implementors "care" (I am guessing they would), I think stating the requirement (if it is to be a requirement) is necessary. So what is the view of the WG re: server RPK support? On by default OK? Required off by default, unless enabled by server administrator? -- Viktor. From nobody Tue Jun 10 08:54:27 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5031A01B6 for ; Tue, 10 Jun 2014 08:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJHbwyv01yc8 for ; Tue, 10 Jun 2014 08:54:22 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84ABC1A01A6 for ; Tue, 10 Jun 2014 08:54:22 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id r20so6437182wiv.15 for ; Tue, 10 Jun 2014 08:54:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=jQ/z3wuuQSr3cl8BUCBIwxYCm+fTXwOPbuDF/xfX+Iw=; b=GZS2dIPs7muTE0cI0jViNy78DWnNLTCpDz+mB9tVqLbdEf8jZYln9Na4zZUcW6kKsp vhPtAgnvaFwgqv3MsCRmMR2W/S1n6QaGcpXENNy74qaV/kdNeyvbrJwldwKWHp2QoQgs pWHMKTkQloP4LU4UAX4mZs70iwj/UWTP5c8EGXAUpQfqtfSNFn7T5MT5v2cQ6lq2wyGn YW4RW9p5fkCgNzbpb8tBibkRQ+AzPa1waLNTBJAbGWBJNdYeYvtt1JzvHlzBYR11HyxA qsBX517fR0gknebEK1Hin2GSucBRvgJCGktb10sjfSBRl393LXWhgKc9F7JhWD8Q8kd7 4QJQ== X-Gm-Message-State: ALoCoQnlKgYxDJKZcjahpWlKY1LS8ns9c+jIpbrtWR+Gno477/94xM90CT9kX4b3GIQ52eGZTl9f MIME-Version: 1.0 X-Received: by 10.194.22.100 with SMTP id c4mr15696950wjf.89.1402415660515; Tue, 10 Jun 2014 08:54:20 -0700 (PDT) Received: by 10.194.248.233 with HTTP; Tue, 10 Jun 2014 08:54:20 -0700 (PDT) Date: Tue, 10 Jun 2014 08:54:20 -0700 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/C8_5V7kstKW39MwqnRwDrTa9RLk Subject: [dane] Agenda for Toronto. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 15:54:24 -0000 Hi there, The Toronto meeting is approaching. Based upon last times attendance, etc we have requested a 2 hour slot. If you'd like some time on the agenda, please let us know soon, or you might not get a slot. W From nobody Tue Jun 10 16:06:23 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6DC1A0109; Tue, 10 Jun 2014 16:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfvo_Q2LqFcq; Tue, 10 Jun 2014 16:06:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38DFD1A028F; Tue, 10 Jun 2014 16:06:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140610230618.16781.98646.idtracker@ietfa.amsl.com> Date: Tue, 10 Jun 2014 16:06:18 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/jeDbX-VFUGX3S9lG2HqrshBsqu8 Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-srv-06.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 23:06:20 -0000 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 : Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records Authors : Tony Finch Matthew Miller Peter Saint-Andre Filename : draft-ietf-dane-srv-06.txt Pages : 13 Date : 2014-06-10 Abstract: The DANE specification (RFC 6698) describes how to use TLSA resource records in the DNS to associate a server's host name with its TLS certificate, where the association is secured with DNSSEC. However, application protocols that use SRV records (RFC 2782) to indirectly name the target server host names for a service domain cannot apply the rules from RFC 6698. Therefore this document provides guidelines that enable such protocols to locate and use TLSA records. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-srv/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-srv-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-srv-06 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 nobody Tue Jun 10 18:24:33 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD35C1A0285 for ; Tue, 10 Jun 2014 18:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72pvm_DXkyl1 for ; Tue, 10 Jun 2014 18:24:31 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 436381A0252 for ; Tue, 10 Jun 2014 18:24:31 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 928F940332; Tue, 10 Jun 2014 19:24:30 -0600 (MDT) Message-ID: <5397AFCE.8070303@stpeter.im> Date: Tue, 10 Jun 2014 19:24:30 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dane/qNAMult4PhQFLrk8Q7JEVN9xX1k Subject: [dane] dane-srv questions for the WG X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jun 2014 01:24:33 -0000 Matt Miller and I submitted a new version of draft-ietf-dane-srv today. We have a few questions for the WG... 1. In Section 4.1, we discuss how to proceed if there are no TLSA records, only SRV records. This section assumes that the presented certificate is a "traditional" PKIX cert. Therefore we do not take into account raw public keys as specified in draft-ietf-tls-oob-pubkey. Do folks here think we need to address, or at least mention, the raw keys case? 2. Also in Section 4.1, we say: ### SRV is secure: The reference identifiers SHALL include both the service domain and the SRV target server host name (e.g., include both "im.example.com" and "xmpp23.hosting.example.net"). The target server host name is the preferred name for TLS SNI or its equivalent. In the latter case, the client will accept either identity to ensure compatibility with servers that support this specification as well as servers that do not support this specification. ### Remember that the reference identifiers are what the client uses when determining if the certificate is acceptable (cf. RFC 6125). The reasoning here is that if the client allows only the target server host name as a reference identifier then it won't be able to connect to older servers that don't yet support dane-srv, whereas if it allows only the source domain as a reference identifier then it won't be able to connect to newer servers that support only dane-srv. For the sake of interoperability, supporting both seems like the best approach. Does that justify the SHALL here? And is this the best place in the document for this information? Thanks! Peter From nobody Tue Jun 10 21:11:47 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A781B1A0338 for ; Tue, 10 Jun 2014 21:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpWCsdl2OI9d for ; Tue, 10 Jun 2014 21:11:43 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8B81A035D for ; Tue, 10 Jun 2014 21:11:42 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DC62D2AB09B; Wed, 11 Jun 2014 04:11:40 +0000 (UTC) Date: Wed, 11 Jun 2014 04:11:40 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140611041140.GP27883@mournblade.imrryr.org> References: <5397AFCE.8070303@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5397AFCE.8070303@stpeter.im> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/z_9CZOYDrBceJSt2eZLEUkFZ3wM Subject: Re: [dane] dane-srv questions for the WG X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jun 2014 04:11:44 -0000 On Tue, Jun 10, 2014 at 07:24:30PM -0600, Peter Saint-Andre wrote: > Matt Miller and I submitted a new version of draft-ietf-dane-srv today. Thanks. A few comments: Section 2: The reference to "secure", "insecure", "bogus", "indeterminate" was changed to refer to RFC 4033, from 4035, but in fact it is 4035 that gives the intended definition of "indeterminate" (failure to determine, a lookup error). See the SMTP draft, section 2.1.1 Section 3.1: If a particular response is "bogus" or "indeterminate" according to DNSSEC validation, the client MUST ignore that target server host name. This glosses over two distinct cases: * The SRV RRset is "bogus", "indeterminate" (or some other lookup error, feel free to borrow/steal section 2.1.1 from the SMTP draft). In this case NONE of the SRV server names, if any were actually obtained, can be used. * The SRV RRset is secure, but downstream lookups for A or TLSA records fail... The quoted comment more properly applies to the second case, but you've not yet reached that point in the discussion. The immediately preceding text is about the initial SRV lookup, and if that fails, ALL the SRV records are bad, and the service is unreachable. So it seems that the original text was more appropriate: Section 4.1: This section is confusing because it is not clear that the opening paragraph established preconditions for the rest of the section. The first paragraph should say something like: "In this section we consider the case that, ... The case with TLSA usable/secure records is considered in the next section, ..." > We have a few questions for the WG... > 1. In Section 4.1, we discuss how to proceed if there are no TLSA records, > only SRV records. This section assumes that the presented certificate is a > "traditional" PKIX cert. Therefore we do not take into account raw public > keys as specified in draft-ietf-tls-oob-pubkey. Do folks here think we need > to address, or at least mention, the raw keys case? Without TLSA records any out of band authentication of "RPK" material is not via DANE, it is not clear whether anything generally useful can be said about this. However, even without RPK, opportunistic TLS clients may simply skip authenticating the server entirely (as with SMTP), and so a general requirement to authenticate is too strong. Rather I think you should specify which reference identifiers to use *IF* the client is using PKIX, without mandating the use of PKIX. > 2. Also in Section 4.1, we say: > > SRV is secure: The reference identifiers SHALL include both the > service domain and the SRV target server host name (e.g., include > both "im.example.com" and "xmpp23.hosting.example.net"). The > target server host name is the preferred name for TLS SNI or its > equivalent. > > In the latter case, the client will accept either identity to ensure > compatibility with servers that support this specification as well as > servers that do not support this specification. > > Remember that the reference identifiers are what the client uses when > determining if the certificate is acceptable (cf. RFC 6125). The reasoning > here is that if the client allows only the target server host name as a > reference identifier then it won't be able to connect to older servers that > don't yet support dane-srv, whereas if it allows only the source domain as a > reference identifier then it won't be able to connect to newer servers that > support only dane-srv. For the sake of interoperability, supporting both > seems like the best approach. Does that justify the SHALL here? And is this > the best place in the document for this information? I think the requirement is justified, provided the client is doing PKIX. I have no concrete opinion about document organization. The document still feels a bit "raw" overall, if you have cycles to re-read it with care, and polish it further, it would likely help. -- Viktor. From nobody Tue Jun 10 22:31:54 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F181A0384 for ; Tue, 10 Jun 2014 22:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JB9uqGLGreka for ; Tue, 10 Jun 2014 22:31:52 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42F7D1A0377 for ; Tue, 10 Jun 2014 22:31:52 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 600391E5B7; Wed, 11 Jun 2014 05:31:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1402464710; bh=HCrirQ/rFeSeYjR1wtbkO1a1MRrc/QqTemDnKZfaiTs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mtZgUwB1kIbO7G5wRClEfX4C+E82NBssrqk3vK6H7K/ahMnPoRFB620NkK0z/gfRg lOXNfElSZ77BtXFE+PC9FXaXH/9tNtHm46+dr6/0OO3+mOY/Gkpwe5tfxJyPKDFZN9 pIdrcQgWZPtg+esh4huh30PIXZXwi9xwqynbSets= Received: by carbon.jhcloos.org (Postfix, from userid 500) id C68A36001E; Wed, 11 Jun 2014 05:24:07 +0000 (UTC) From: James Cloos To: Peter Saint-Andre In-Reply-To: <5397AFCE.8070303@stpeter.im> (Peter Saint-Andre's message of "Tue, 10 Jun 2014 19:24:30 -0600") References: <5397AFCE.8070303@stpeter.im> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Wed, 11 Jun 2014 01:24:07 -0400 Message-ID: Lines: 13 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140611:stpeter@stpeter.im::mWGjD1/sbcKWwSrK:000000000000000000000000000000000000000000z8uAK X-Hashcash: 1:30:140611:dane\@ietf.org\::J97KJ89MWgKLsjkx:0iBB0n X-Hashcash: 1:30:140611:dane@ietf.org::I4dIbNqD8bhSFy40:000vRmpT Archived-At: http://mailarchive.ietf.org/arch/msg/dane/-z6HLASX6mk2FcSuzo_8iX7uCcI Cc: "" Subject: Re: [dane] dane-srv questions for the WG X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jun 2014 05:31:54 -0000 >>>>> "PS" == Peter Saint-Andre writes: PS> For the sake of interoperability, supporting both [target server PS> hostname and source domains as a reference identifier] seems like PS> the best approach. Does that justify the SHALL here? Specifying that clients SHALL consider both the source domain and the target server hostname when the SRV RR is secure looks like an accept- able compromise between the optimal case and the pre-dane legacy. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Wed Jun 11 08:21:35 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E1D1A0163 for ; Wed, 11 Jun 2014 08:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQOlAbfAf6qJ for ; Wed, 11 Jun 2014 08:21:32 -0700 (PDT) Received: from mail.zash.se (ip66.hethane.riksnet.nu [85.11.25.66]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3902D1A0150 for ; Wed, 11 Jun 2014 08:21:31 -0700 (PDT) Received: from [IPv6:2001:470:28:68f::] (carcharodon.zash.se [IPv6:2001:470:28:68f::]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: zash) by mail.zash.se (Postfix) with ESMTPSA id 6058C6145A; Wed, 11 Jun 2014 17:21:25 +0200 (CEST) Message-ID: <539873F2.2070202@zash.se> Date: Wed, 11 Jun 2014 17:21:22 +0200 From: Kim Alvefur User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Peter Saint-Andre , "" References: <5397AFCE.8070303@stpeter.im> In-Reply-To: <5397AFCE.8070303@stpeter.im> X-Enigmail-Version: 1.6 OpenPGP: id=B67AD329; url=http://zash.se/~zash/pubkey.asc Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xaGdMTdf5EBrj68kPhDQSIR7wlgai6fX6" Archived-At: http://mailarchive.ietf.org/arch/msg/dane/v1-mRloJkywXVGlzi4znCeWmOOQ Subject: Re: [dane] dane-srv questions for the WG X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jun 2014 15:21:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xaGdMTdf5EBrj68kPhDQSIR7wlgai6fX6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-06-11 03:24, Peter Saint-Andre wrote: > Matt Miller and I submitted a new version of draft-ietf-dane-srv today.= Why does the text it Section 3 say to do queries in parallel when section 3.2 says that one has to do A/AAAA lookups and validation (which depend on SRV) before deciding to do TLSA lookups? And what does the security status of A/AAAA records matter if you have a secure reference to the certificate you see? Unless of course if you get bogus, then aborting the connection to that target is sane. >=20 > SRV is secure: The reference identifiers SHALL include both the > service domain and the SRV target server host name (e.g., include= > both "im.example.com" and "xmpp23.hosting.example.net"). The > target server host name is the preferred name for TLS SNI or its > equivalent. In XMPP, sending to=3D'xmpp123.hosting.example.net' instead of to=3D'example.com' does not seem sensible to me. The server should know which cert to present for each domain, or probably just shows the same for all if it is a multi-tenant hosting service. And I don't think one should look too hard at the name in a certificate if you have a matching TLSA record. -- Kim "Zash" Alvefur --xaGdMTdf5EBrj68kPhDQSIR7wlgai6fX6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTmHPyAAoJEK3tmne2etMp/IgP/jG/wKGfFnmMwX6dn/hxEGoU BTZmYTr8fy3R9F3LBlR4eIwbUf7V0PfL326lZOCIf2Ec+HPOESpOz+S1lxQh69+K +5OzPoXPqsEzbQaUMkW5WXPUT2TjHbKlivhEEVxLWKrKUoKMTjHglBS77wX3/P3E MzVtcfUWfCV3IRXZxoJ7dljiXAVBM8LEwO+mC+jDP3Y2fN0sJGcEcLEuMupC6UZy AzuZAMsCk+nqogcs4nolwhN0EajiIrMvIAjwt2i1bjx9Hp9/LDtTDxfcvh9pi7eo ahwFzwkmQp4d8UPtecJwY4eSXuWWj3LN1kfntPRHqG6tg9wCzoJJ5ALbKLZ+XLnl mXSQJv4P9eEDw4ujeWAlMZN9H5gzSpCkK3jCGYSxq/0zlmQfMTOuh4B5uI1AsTlB gQFKQzuf2jp23zPsDRmvaf2pTGSRRl7tSlieC4ksg1D1Odrp5+9RzcZG2LusNVPX 9OkhqEORc4Y6NtmT5z8UVZYOWUamFs2p29Va2UxdOZGkPFpygKdijiAD/eul7YIj LhUsGEuk1hKXwIy1tryMQ7VFhXVBse9UxxwvECVYbmK/rfC2Lz9xn3lmxNdQX6Jm UtyWAuYAKrQlgsgRuFKZz8gmZ4ay9BnpVSm7SUKWnr5+j1PGtPiMBEoylMFzSLw9 +9WGV/kEVYzwv9B41gHH =r4j6 -----END PGP SIGNATURE----- --xaGdMTdf5EBrj68kPhDQSIR7wlgai6fX6-- From nobody Wed Jun 11 08:46:14 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742621A018A for ; Wed, 11 Jun 2014 08:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrbcqreZAWkq for ; Wed, 11 Jun 2014 08:46:08 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E2011A061D for ; Wed, 11 Jun 2014 08:45:54 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8AEC52AB25D; Wed, 11 Jun 2014 15:45:53 +0000 (UTC) Date: Wed, 11 Jun 2014 15:45:53 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140611154553.GV27883@mournblade.imrryr.org> References: <5397AFCE.8070303@stpeter.im> <539873F2.2070202@zash.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <539873F2.2070202@zash.se> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/-gStsBxZXvpMdG6pyqEB5auBJ9s Subject: Re: [dane] dane-srv questions for the WG X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jun 2014 15:46:11 -0000 On Wed, Jun 11, 2014 at 05:21:22PM +0200, Kim Alvefur wrote: > On 2014-06-11 03:24, Peter Saint-Andre wrote: > > Matt Miller and I submitted a new version of draft-ietf-dane-srv today. > > Why does the text it Section 3 say to do queries in parallel when > section 3.2 says that one has to do A/AAAA lookups and validation (which > depend on SRV) before deciding to do TLSA lookups? It says "where possible". As I see it the only sensible opportunity for parallel lookup is to find the A or AAAA records of the subset of the SRV hosts with the highest (untried) priority, then among those that actually have an IP address, one can choose a randomized server based on the weight, at which point I would only retrieve TLSA records for that host. Generally, all the SRV hosts are up and it is sufficient to try one connection, so there is no benefit in performing multiple TLSA lookups for clients that make long-lived infrequent connections. In summary I think that while some clients may decide to parallelize some DNS lookups, this is an implementation decision that is perhaps out of scope for the DANE SRV specification. > And what does the security status of A/AAAA records matter if you have a > secure reference to the certificate you see? Unless of course if you > get bogus, then aborting the connection to that target is sane. See Section 2.2.2 of the SMTP draft, which provides the rationale: http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-10.html#rfc.section.2.2.2 > > SRV is secure: The reference identifiers SHALL include both the > > service domain and the SRV target server host name (e.g., include > > both "im.example.com" and "xmpp23.hosting.example.net"). The > > target server host name is the preferred name for TLS SNI or its > > equivalent. > > In XMPP, sending to='xmpp123.hosting.example.net' instead of > to='example.com' does not seem sensible to me. The server should know > which cert to present for each domain, or probably just shows the same > for all if it is a multi-tenant hosting service. This suggestion breaks cross-domain hosting: _service.example.org. IN SRV 0 0 12345 server.example.net. The server.example.net hosting provider can obtain certs for its own name, managing certs from each hosted domain is a significant burden. > And I don't think one should look too hard at the name in a certificate > if you have a matching TLSA record. You're not thinking about TA certificate usages PKIX-TA(0) and DANE-TA(2) which absolutely require name checks. Even PKIX-EE(1) requires name checks as part of the PKIX validation. -- Viktor. From nobody Wed Jun 11 12:37:48 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233001A0240 for ; Wed, 11 Jun 2014 12:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ogg6aGkgWY2 for ; Wed, 11 Jun 2014 12:37:43 -0700 (PDT) Received: from mail.zash.se (ip66.hethane.riksnet.nu [85.11.25.66]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ED721A025F for ; Wed, 11 Jun 2014 12:37:42 -0700 (PDT) Received: from [IPv6:2001:470:28:68f::] (carcharodon.zash.se [IPv6:2001:470:28:68f::]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: zash) by mail.zash.se (Postfix) with ESMTPSA id 9C18661715 for ; Wed, 11 Jun 2014 21:37:38 +0200 (CEST) Message-ID: <5398B000.6000705@zash.se> Date: Wed, 11 Jun 2014 21:37:36 +0200 From: Kim Alvefur User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dane@ietf.org References: <5397AFCE.8070303@stpeter.im> <539873F2.2070202@zash.se> <20140611154553.GV27883@mournblade.imrryr.org> In-Reply-To: <20140611154553.GV27883@mournblade.imrryr.org> X-Enigmail-Version: 1.6 OpenPGP: id=B67AD329; url=http://zash.se/~zash/pubkey.asc Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gKs3kGBa8v2ODoX6tvf0FffQkoGFMe0Hb" Archived-At: http://mailarchive.ietf.org/arch/msg/dane/7yyAYvh9mHQF3UDQnYIoOs9CY64 Subject: Re: [dane] dane-srv questions for the WG X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jun 2014 19:37:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gKs3kGBa8v2ODoX6tvf0FffQkoGFMe0Hb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2014-06-11 17:45, Viktor Dukhovni wrote: > On Wed, Jun 11, 2014 at 05:21:22PM +0200, Kim Alvefur wrote: >=20 >> On 2014-06-11 03:24, Peter Saint-Andre wrote: >>> Matt Miller and I submitted a new version of draft-ietf-dane-srv toda= y. >> >> Why does the text it Section 3 say to do queries in parallel when >> section 3.2 says that one has to do A/AAAA lookups and validation (whi= ch >> depend on SRV) before deciding to do TLSA lookups? >=20 > It says "where possible". As I see it the only sensible opportunity > for parallel lookup is to find the A or AAAA records of the subset > of the SRV hosts with the highest (untried) priority, then among > those that actually have an IP address, one can choose a randomized > server based on the weight, at which point I would only retrieve > TLSA records for that host. >=20 > Generally, all the SRV hosts are up and it is sufficient to try > one connection, so there is no benefit in performing multiple TLSA > lookups for clients that make long-lived infrequent connections. >=20 > In summary I think that while some clients may decide to parallelize > some DNS lookups, this is an implementation decision that is perhaps > out of scope for the DANE SRV specification. That's what I was aiming for. >=20 >> And what does the security status of A/AAAA records matter if you have= a >> secure reference to the certificate you see? Unless of course if you >> get bogus, then aborting the connection to that target is sane. >=20 > See Section 2.2.2 of the SMTP draft, which provides the rationale: >=20 > http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-10.h= tml#rfc.section.2.2.2 Perhaps a reference to that then? >>> SRV is secure: The reference identifiers SHALL include both the >>> service domain and the SRV target server host name (e.g., inclu= de >>> both "im.example.com" and "xmpp23.hosting.example.net"). The >>> target server host name is the preferred name for TLS SNI or it= s >>> equivalent. >> >> In XMPP, sending to=3D'xmpp123.hosting.example.net' instead of >> to=3D'example.com' does not seem sensible to me. The server should kn= ow >> which cert to present for each domain, or probably just shows the same= >> for all if it is a multi-tenant hosting service. >=20 > This suggestion breaks cross-domain hosting: >=20 > _service.example.org. IN SRV 0 0 12345 server.example.net. >=20 > The server.example.net hosting provider can obtain certs for its > own name, managing certs from each hosted domain is a significant > burden. Then how is server.example.net supposed to know that you want to talk to example.org? "its equivalent" is said to be the stream addressing earlier which makes this weird. >> And I don't think one should look too hard at the name in a certificat= e >> if you have a matching TLSA record. >=20 > You're not thinking about TA certificate usages PKIX-TA(0) and > DANE-TA(2) which absolutely require name checks. Even PKIX-EE(1) > requires name checks as part of the PKIX validation. >=20 Right, of course. -- Kim "Zash" Alvefur --gKs3kGBa8v2ODoX6tvf0FffQkoGFMe0Hb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTmLAAAAoJEK3tmne2etMpY2kP/RMayAPzE6p2q1c5n71x+iQs hH12t3L+62zwx1ViYjtGo6tz83rZ+ZCXFYuz/ri0OaSn65inDmXK59KlE2idaq99 ejAx8HvG+LHBmx11S7XeEunbGvkOOneYAM6v9ZM3hQX0C8fP6vLwd70/um0ZJlNE ulbbxiXHtKfFNvbiUdwPAzYY34ZMHmd+cgO3HCyP30BIOZrgmQEU6cw0fL5HpxPO R27WVGlaxw4kGbSfIDQQtO5qzEzaA/Tnt0o86oLHxgrasPCPXMaLU+zp5KQwUF1P rf5gSFXwT3zoBwIsVw8lLInlQmHeZnFJhd6fwG4eP+rra4SbgWCWyn5MUtrlE6lv K51Dnm+tnod/iyA/hDAVy6PJQIoqEifV1Kr7ad9x40VDMcwt8OfexRRoaZ0tJMvv K++d+GhkkqS3vV4BIgPToehuFA2fwEmljdhe4EtZ0GFtvkFvd9/PpFMZzDMP0+BY IfEcwQGke8wREwxDE5kkPXlD9que2nuMXQMZQVnDYijesLVwqe8gl0QpH8DOqzO0 oUj/1zzwfDRxyicSTwEsFfL8xVe/ne9jK7e5wSbEh0+mzA8AAJzfReqVslMjBnLN 5XknPJYTM7fBix5AyEiKBN417TgF+C+GwE+NjcyZA/RctmGINKhjLD48oY7nKZVx OYGpECbTzrK523BdAdN3 =+zW8 -----END PGP SIGNATURE----- --gKs3kGBa8v2ODoX6tvf0FffQkoGFMe0Hb-- From nobody Wed Jun 11 12:44:20 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E223A1B2850 for ; Wed, 11 Jun 2014 12:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYlLGb84OQsS for ; Wed, 11 Jun 2014 12:44:18 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4843C1A0299 for ; Wed, 11 Jun 2014 12:44:18 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 619252AB25D; Wed, 11 Jun 2014 19:44:16 +0000 (UTC) Date: Wed, 11 Jun 2014 19:44:16 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140611194416.GQ8358@mournblade.imrryr.org> References: <5397AFCE.8070303@stpeter.im> <539873F2.2070202@zash.se> <20140611154553.GV27883@mournblade.imrryr.org> <5398B000.6000705@zash.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5398B000.6000705@zash.se> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/TX9AzzKLLsDfFG_7Zd749lvNZtU Subject: Re: [dane] dane-srv questions for the WG X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 11 Jun 2014 19:44:20 -0000 On Wed, Jun 11, 2014 at 09:37:36PM +0200, Kim Alvefur wrote: > > This suggestion breaks cross-domain hosting: > > > > _service.example.org. IN SRV 0 0 12345 server.example.net. > > > > The server.example.net hosting provider can obtain certs for its > > own name, managing certs from each hosted domain is a significant > > burden. > > Then how is server.example.net supposed to know that you want to talk to > example.org? "its equivalent" is said to be the stream addressing > earlier which makes this weird. In-band signalling. "Host:" headers with HTTP, "RCPT TO:" with SMTP, user login with IMAP, ... Demultiplexing at the application layer is rather common. -- Viktor. From nobody Fri Jun 13 09:34:23 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3B91A05CB; Fri, 13 Jun 2014 09:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOfH4M0sn7C4; Fri, 13 Jun 2014 09:34:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A021B293F; Fri, 13 Jun 2014 09:34:18 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140613163418.19464.92042.idtracker@ietfa.amsl.com> Date: Fri, 13 Jun 2014 09:34:18 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/9-l9SJnW6jWh3NGHDf_yThniVkM Cc: dane WG Subject: [dane] WG Action: Rechartered DNS-based Authentication of Named Entities (dane) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 16:34:21 -0000 The DNS-based Authentication of Named Entities (dane) working group in the Security Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. DNS-based Authentication of Named Entities (dane) ------------------------------------------------ Current Status: Active WG Chairs: Warren Kumari Olafur Gudmundsson Secretaries: Matt Lepinski Assigned Area Director: Stephen Farrell Mailing list Address: dane@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dane Archive: http://www.ietf.org/mail-archive/web/dane/ Charter: DANE is a set of mechanisms and techniques that allow Internet applications to establish cryptographically secured communications by using information made available in DNS. By binding the key information to a domain name and protecting that binding with DNSSEC, applications can easily discover authenticated keys for services. Objective: The DANE WG will specify how to incorporate DANE and DANE-like functionality into protocols. The WG will specify the use of DANE for protocols that use SRV to express service location. The WG will specify DANE use for SMTP, SMIME, OPENPGP, IPSEC and other base electronic mail protocols such as (IMAP or POP). The DANE WG shall also produce a set of implementation guidance for operators and tool developers. When work on currently chartered documents is complete the WG may re-charter if sufficiently pressing new work is identified. DANE is not intended to be a long-lived catch-all WG for all public key distribution in DNS issues and so will generally not adopt new work items without re-chartering. Problem Statement: The DANE working group has developed a framework for securely retrieving keying information from the DNS [RFC6698]. This framework allows secure storing and looking up server public key information in the DNS. This provides a binding between a domain name providing a particular service and the key that can be used to establish encrypted connection to that service. By requiring DNSSEC protection for the lookup of the public key information, DANE leverages the integrity protection provided by DNSSEC to enable secure discovery of keying information. Operators wanting to take advantage of DANE for their services must turn on DNSSEC signing on the zones used in finding the services. Using DNS this way, bindings of keys to domains are asserted by the entities that operate the DNS for that domain, not by external entities. The DANE mechanisms provide flexibility in how the keying information is presented. DANE supports both Certificates and raw keys. Furthermore, the keys (raw or imbedded in certificates) can be full keys or a hashes of keys. The group will work on documenting the different approaches to use DANE keying, and the security implication of each. In addition the WG may develop a framework(s) to facilitate the lookup "client" DANE records for authorization/authentication purposes. The group may also create documents that describe how protocol entities can discover and validate these bindings in the execution of specific applications. This work would be done in coordination with the IETF Working Groups responsible for the protocols. The group may in addition encourage interoperability testing and document the results of such testing. Milestones: Jun 2014 - Advance DANE SRV document to IESG Jun 2014 - Advance DANE SMTP document to IESG Aug 2014 - Advance DANE SMIME document to IESG Aug 2014 - Advance DANE OPENPGP document to IESG Sep 2014 - Advance DANE operational guidance/errata document to IESG Jan 2015 - Advance DANE security model document to IESG May 2015 - Advance DANE IPSEC document to IESG Jun 2015 - Advance DANE reverse binding (server to client) document to IESG Sep 2015 - Advance DANE RFC6698 and DANE SRV RFC to Internet Standard Nov 2015 - Recharter or close down From nobody Sat Jun 14 04:35:50 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB381B28F6 for ; Sat, 14 Jun 2014 04:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whqpgC1_u6dT for ; Sat, 14 Jun 2014 04:35:19 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C4A1B28F8 for ; Sat, 14 Jun 2014 04:35:19 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id B6D751E00B; Sat, 14 Jun 2014 11:35:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1402745718; bh=z2p/4nYKNblvi9c2ehFGaUUfaiALF0CwC8JK2fAJ6Xk=; h=From:To:Subject:Date:From; b=EaCI86x6V/Z+CxR4mv/lr/u3HFnPUHhj7mjw7FQe7cxWW8C0sPvR9GyR09MjveKTU ZCqFae3RFWkJgbnh626ACnAlY9uTakOFnCxdkIU9HoH3cOoE7thk/W/Kt45yT5Xr3L NDMudSK576EZaB4brg2ASOkQMvuSydLVK5zDlID4= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 580F36001E; Sat, 14 Jun 2014 11:34:29 +0000 (UTC) From: James Cloos To: dane@ietf.org User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sat, 14 Jun 2014 07:34:29 -0400 Message-ID: Lines: 15 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140614:dane@ietf.org::F22zw+k8RgH62QZZ:0007ToU9 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Eno9gDeRUhJUs_dNmULwrWjWo5I Subject: [dane] _25._tcp.mail.ietf.org gone X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jun 2014 11:35:42 -0000 I noticed that postfix logged my mail yesterday to ietf as Untrusted rather than Verified. That is due to the removal of _25._tcp.mail.ietf.org. My log includes (times are UTC): Jun 11 05:31:52 ore postfix/smtp: Verified TLS connection established to mail.ietf.org Jun 11 23:35:01 ore postfix/smtp: Untrusted TLS connection established to mail.ietf.org Does anyone know why the tlsa was removed? -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Sat Jun 14 07:23:27 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06F11B287E for ; Sat, 14 Jun 2014 07:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FSErEoOR9wf for ; Sat, 14 Jun 2014 07:23:24 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16F491B2853 for ; Sat, 14 Jun 2014 07:23:23 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n3so2142401wiv.9 for ; Sat, 14 Jun 2014 07:23:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oDBxCs/6uGNuBxboI1FmGSS8nsharg4/7/efBxyta1k=; b=ZtJw1RLz6zA5OdfpOfF6/sUxa0Ke71oUtOJsos1qf688QV/kp/nxoi9ZO6ofWjpHAp x2FPJGlh3FIUwykTwG90ZppF4rYbsEIazs1ThddqBUvhdg7mJAcTklMwNZlU3vmegKXy IZeMWui4jfS8XEeXYZ1JY9IG6OEFkGnt1/59URVF/BawzW32pc4dPGSA6e4QOAqsEKql /HskL9SaGDimPYiDSS9D58KbqfYAfljfDwKPnwXS+ggrG9wWiBBsuRYcY6Bl4JVhm4Y5 t63bdN6MFQ74UqwhP/F0VJHa99rqHpUfoXy1dWQdlxm7u7gpo6HnkjU4U1XuNAabnD7G 7tfA== X-Gm-Message-State: ALoCoQns8BYBorVF1ey7F2EnmH/Iu+7UWJkgj6uB2VGLYXZRxerHLC2wNoFyIJ6y2s7tjQGO4FRl MIME-Version: 1.0 X-Received: by 10.194.86.164 with SMTP id q4mr3518243wjz.88.1402755802500; Sat, 14 Jun 2014 07:23:22 -0700 (PDT) Received: by 10.194.248.233 with HTTP; Sat, 14 Jun 2014 07:23:22 -0700 (PDT) In-Reply-To: References: Date: Sat, 14 Jun 2014 10:23:22 -0400 Message-ID: From: Warren Kumari To: James Cloos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/wrSoYUGfy5MHV6zvO63f304BpWU Cc: "" Subject: Re: [dane] _25._tcp.mail.ietf.org gone X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jun 2014 14:23:26 -0000 On Sat, Jun 14, 2014 at 7:34 AM, James Cloos wrote: > I noticed that postfix logged my mail yesterday to ietf as Untrusted > rather than Verified. > > That is due to the removal of _25._tcp.mail.ietf.org. > > My log includes (times are UTC): > > Jun 11 05:31:52 ore postfix/smtp: Verified TLS connection established to mail.ietf.org > Jun 11 23:35:01 ore postfix/smtp: Untrusted TLS connection established to mail.ietf.org > > Does anyone know why the tlsa was removed? Nope. At first I assumed that they had failed over to the "backup" server (there is only one MX record), and had removed the TLSA because the backup didn't do STARTTLS -- but that doesn't seem to be it... So, I've sent the relevant folk mail and will let y'all know when I hear back. Oh, I've been traveling the past few weeks (just got back from Toronto last night - the hotel looks nice!, and head of to Manchester (NH!) and London before returning to Toronto for IETF), so apologies for some outstanding mail... W > > -JimC > -- > James Cloos OpenPGP: 0x997A9F17ED7DAEA6 > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane From nobody Sat Jun 14 10:01:04 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1136A1B2964 for ; Sat, 14 Jun 2014 10:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlbuBqWSchYl for ; Sat, 14 Jun 2014 10:01:00 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45B361A0522 for ; Sat, 14 Jun 2014 10:01:00 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F24DB2AB211; Sat, 14 Jun 2014 17:00:57 +0000 (UTC) Date: Sat, 14 Jun 2014 17:00:57 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140614170057.GB8358@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.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/AuMGFjabyN877bBQ1aITiMR1Yvw Subject: Re: [dane] _25._tcp.mail.ietf.org gone X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 14 Jun 2014 17:01:02 -0000 On Sat, Jun 14, 2014 at 10:23:22AM -0400, Warren Kumari wrote: > > Jun 11 05:31:52 ore postfix/smtp: Verified TLS connection established to mail.ietf.org > > Jun 11 23:35:01 ore postfix/smtp: Untrusted TLS connection established to mail.ietf.org > > > > Does anyone know why the tlsa was removed? > > Nope. > At first I assumed that they had failed over to the "backup" server > (there is only one MX record), and had removed the TLSA because the > backup didn't do STARTTLS -- but that doesn't seem to be it... > > So, I've sent the relevant folk mail and will let y'all know when I hear back. I just tried it, and it is back: $ dig +noall +comment +ans +ad -t tlsa _25._tcp.mail.ietf.org. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25795 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 0 ;; ANSWER SECTION: _25._tcp.mail.ietf.org. 1758 IN TLSA 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B566 64C5D3D6 $ posttls-finger -c -Lsummary ietf.org posttls-finger: Verified TLS connection established to mail.ietf.org[4.31.198.44]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) -- Viktor. From nobody Fri Jun 20 21:25:06 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989881A01BB for ; Fri, 20 Jun 2014 21:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywcjTVkrUl4Z for ; Fri, 20 Jun 2014 21:25:03 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812671A0168 for ; Fri, 20 Jun 2014 21:25:03 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id s5L4P2eo001257; Fri, 20 Jun 2014 21:25:02 -0700 Message-Id: <201406210425.s5L4P2eo001257@new.toad.com> To: dane@ietf.org, gnu@toad.com Date: Fri, 20 Jun 2014 21:25:02 -0700 From: John Gilmore Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Yp30GbaGMkUoCiXrYyP8A_KGDkM Subject: [dane] New I-D on Authenticating Raw Public Keys with DANE TLSA X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 04:25:04 -0000 In an effort to nudge along the process of standardizing the use of DANE with TLS's use of raw public keys, I have written a short Internet-Draft that defines how these keys can be authenticated by using TLSA records. Name: draft-gilmore-dane-rawkeys Revision: 00 Title: Authenticating Raw Public Keys with DANE TLSA Document date: 2014-06-20 Group: Individual Submission Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-gilmore-dane-rawkeys-00.txt Status: https://datatracker.ietf.org/doc/draft-gilmore-dane-rawkeys/ Htmlized: http://tools.ietf.org/html/draft-gilmore-dane-rawkeys-00 Abstract: This document standardizes how the Domain Name System can authenticate Raw Public Keys. Transport Level Security now has the option to use Raw Public Keys, but they require some form of external authentication. The document updates RFC 6698 to allow the Domain Name System to standardize the authentication of more types of keying material. The TLS extension for raw public keys, which inspired this work, is currently very late in the IETF publication process, but not quite published, here: "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)" https://www.rfc-editor.org/authors/rfc7250.txt John From nobody Mon Jun 23 03:16:13 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0295D1B2A78 for ; Mon, 23 Jun 2014 03:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVQkpsAqqM2o for ; Mon, 23 Jun 2014 03:16:08 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6BA1B2988 for ; Mon, 23 Jun 2014 03:16:04 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so3860046wib.11 for ; Mon, 23 Jun 2014 03:16:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=39mU6pWNt+wTSWxcff+9mJml+ODE8fPO2ETMsAF/3hM=; b=R+76Tx/QuMxEO2jByP78pnhsQIZekZ8rrhkJAEcMWfp1h9nzBRrUKnykTXhx3xBRKi mzcIhRaXqxaJSYkdP4avHisZvmBgGJsc4apKVin53QXkDg00X5mKgCRp/75+TGkZxj1l DDXAEtBc/lVgTiu/L+6NMbVwvGL0NOFfDFt+Z9Tp+mCQDzr6Y7ZaHSWs+Tjqax/2hg3a xhnkYvPQlpexQm5Tif0a9/gClCMPf/qUMuRfNJMrYneANWsCXRNdXdWxBwLR9M1jjSo/ NAZgYt2MP6t9J0D0OF7h0eezayMTKF0W4QqqzAk3o3rrHpY/0VivUQT1vmB70B6jzYPD 0LeQ== X-Gm-Message-State: ALoCoQnrd8PZQ7I7QrcxpL8N7swbaEhPRgtpSI8E4wK4LB9myeDqVAtkHjO/kihkZv8TgHLa9oS/ MIME-Version: 1.0 X-Received: by 10.194.62.5 with SMTP id u5mr25526590wjr.46.1403518561309; Mon, 23 Jun 2014 03:16:01 -0700 (PDT) Received: by 10.194.248.233 with HTTP; Mon, 23 Jun 2014 03:16:01 -0700 (PDT) Date: Mon, 23 Jun 2014 06:16:01 -0400 Message-ID: From: Warren Kumari To: "" , draft-gilmore-dane-rawkeys-00@tools.ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Qy7Md2CaPHp2N3DKBmwb_3uTn30 Subject: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 10:16:11 -0000 Dear DANE WG, This starts a Call for Adoption for draft-gilmore-dane-rawkeys-00. The draft is available here: https://datatracker.ietf.org/doc/draft-gilmore-dane-rawkeys-00/ This document was written in response to a request, and so we are compressing the more traditional 2 week call for adoption to instead be a single week. Please let us know clearly if you *object* to this document being adopted, with a clear explanation of why. Please also indicate if you are willing to contribute text, review, etc. This call for adoption ends Monday 07-Jul-2014. Thanks, Warren Kumari (as DANE WG co-chair) From nobody Mon Jun 23 03:16:46 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEB91B2A6F for ; Mon, 23 Jun 2014 03:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pf5Ap-XuBc7 for ; Mon, 23 Jun 2014 03:16:42 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAA0F1B2A88 for ; Mon, 23 Jun 2014 03:16:37 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hi2so3901984wib.4 for ; Mon, 23 Jun 2014 03:16:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Yumyn+Je3riVq2EKXlPnUfoWwI52NfvOjn7scAiWH0Y=; b=f+9RWgT5mNKMX7rNltHKzWBhHMlv21uJLLnCItxpjdVb9Bws7jIx+ZVS4KNnZBC6eI aA3soxoNpddVhcJtJGG4a19UFrRhfoENgrj8w/WZU4DwGN1twYfqZs3peJc4fuk5mnav /y7ML1wd5tKgTd677875E+2hyZ7e9Xe1fVMcozce/vyOJ+uck4+0w3Sb1sl1ET0+G/pa f5iYnTIytSG5D6pV5yZkNVILM/2K+Rqqz/jtR4aqKarpnfjsYmeyzwFs+7s76+IXKLpS L0IZOdIP7ZEs3wMFVFDLQuZjM5FWmLKNC6NZLT9jAvs+7rNiSrtWut/einuHa3QcLPIr F9HA== X-Gm-Message-State: ALoCoQlIy699Zo2qH3vGbt69gkR6Ro4zy8I7FQc+a3Ok72DR1VP+v1fSIphBTzkcJAfibF756Rx2 MIME-Version: 1.0 X-Received: by 10.194.62.5 with SMTP id u5mr25530730wjr.46.1403518593373; Mon, 23 Jun 2014 03:16:33 -0700 (PDT) Received: by 10.194.248.233 with HTTP; Mon, 23 Jun 2014 03:16:33 -0700 (PDT) Date: Mon, 23 Jun 2014 06:16:33 -0400 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/uyGSokQq8WU877qJAH3Y1rNPxIc Subject: [dane] IPR check on draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 10:16:44 -0000 Dear DANE WG, Be not alarmed. The authors of draft-gilmore-dane-rawkeys-00 have asked for it to be adopted as a DANE document -- we would like to check whether any claims of Intellectual Property Rights (IPR) on the document have not yet been disclosed. Are you personally aware of any IPR that applies to draft-gilmore-dane-rawkeys-00? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) If you are a document author or listed contributor on this document, please reply to this email regardless of whether or not you are personally aware of any relevant IPR. If you are on the DANE WG email list but are not an author or listed contributor for this document, you are reminded of your opportunity for a voluntary IPR disclosure under BCP 79. Please do not reply unless you want to make such a voluntary disclosure. Online tools for filing IPR disclosures can be found at . We will be doing this all again when (and if) the document goes to WGLC. Thanks, Warren Kumari (as DANE WG co-chair, with the process hat on!) From nobody Mon Jun 23 03:23:00 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B321B28BE for ; Mon, 23 Jun 2014 03:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UHRTq0AWckz for ; Mon, 23 Jun 2014 03:22:57 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D46551A035B for ; Mon, 23 Jun 2014 03:22:56 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id n15so3867073wiw.5 for ; Mon, 23 Jun 2014 03:22:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=1slMlOgcL3KRJ+eSWac4OK5bfmB3wAmxaeNIYLatAmc=; b=eg4GCHAdJk87FCcyuHZlwO+GiAYENYLxDfTcgnbhzXTJRgh0DKo8H8Vnj6EpzsX6fg Jq62sJUb9TfjzqoFsi/tW37Dcx7AifA2e2OZy6Q1lVLsv/zuhUkcITcncBu7IevrWxvm rQkDap1bfogkq/6C978i3n26ZhkxNCBy2MzZnz7dfnB7VYkIjuYjya9qmI3gA6aNwoZQ C+MGP0rXi1WRAU7AK1AatXOdnnIds9W/HsvI0XhMWIGg3Y/do3jfA+aLNiXdpralg8R8 WtUKfmgll7ATCG/dfBiNPU7CO0ZzaItjOaX9LKp32cR3sQStorNg5hewJ2YqyZATlTAJ JUUw== X-Gm-Message-State: ALoCoQnnNk6PR5q3CiCTNNa4HAD5Om4TnOaIPy2VIczaVDKEmh91XLd2gKDlazvjTVCtFuSfAeS2 MIME-Version: 1.0 X-Received: by 10.180.103.228 with SMTP id fz4mr24711114wib.4.1403518974107; Mon, 23 Jun 2014 03:22:54 -0700 (PDT) Received: by 10.194.248.233 with HTTP; Mon, 23 Jun 2014 03:22:54 -0700 (PDT) Date: Mon, 23 Jun 2014 06:22:54 -0400 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Z0QtC8RSNXGQNTTVTBAhJqZ4tjI Subject: [dane] Call for agenda items. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 10:22:58 -0000 Hi there DANEites, We still have free agenda time for the upcoming London meeting. Please let us know if you would like some... The sooner you request time, the more likely you are to get some... Remember, we give priority to documents that have open issues than would benefit from in person discussion. W From nobody Mon Jun 23 03:56:59 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028431B29F5 for ; Mon, 23 Jun 2014 03:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEui67Lnz5c2 for ; Mon, 23 Jun 2014 03:56:56 -0700 (PDT) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2665B1B29B6 for ; Mon, 23 Jun 2014 03:56:55 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id k48so6729650wev.34 for ; Mon, 23 Jun 2014 03:56:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=umphYlJWN++lhMZJAvZ33AkbsRpiPi2gpN8fhYg2rxo=; b=X/Dqq2TUmXzklS/gKxL4kHH4GOeXeMdX68axDMS9/lOdadCMz2i+Mg5IN0CNWdi1fh al4Q9VNpnftZLHzdOB7dUXWh5tX9LHQNboFBjqquUcTBNqt+TXNYanJuUEo5AHDpHio1 hEwy16xjPo22UG3RmRrYxZuZQ8BzUYeRIgdQ/BXPeDBOLepFcvImLSs/slOizyo8Kxem POxMDdKKtPRgFbr90TUAn+77YGjDYh888IJ+ZDjEyEsP8FWJEaqupQkVZ0CMmVQq/IQh 1R1yaEuBADrat7qpfmzSIIVSqba36CL2/V8IwwExdxmRzEC4tfIfvhy1ADGILXLkaK91 jugQ== X-Gm-Message-State: ALoCoQl1tEi09grhbK0pvFQYuZrNRKmhBuJ+mSO3zDwR6UWt3j+7Bm1zTHVeh0SIJOI5tOPP851P MIME-Version: 1.0 X-Received: by 10.180.74.9 with SMTP id p9mr25303486wiv.39.1403521011661; Mon, 23 Jun 2014 03:56:51 -0700 (PDT) Received: by 10.194.248.233 with HTTP; Mon, 23 Jun 2014 03:56:51 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 Jun 2014 06:56:51 -0400 Message-ID: From: Warren Kumari To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ocmbbhCaPLSiNLSQQD0QKFCXJbE Subject: Re: [dane] Call for agenda items. X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 10:56:58 -0000 On Mon, Jun 23, 2014 at 6:22 AM, Warren Kumari wrote: > Hi there DANEites, > > We still have free agenda time for the upcoming London meeting. Doh! s/London/Toronto/ No idea why I keep thinking we are meeting in London again. W (Written from the ICANN Tech Day meeting in the Hilton Metropole in, yup, London. Really London...) > Please > let us know if you would like some... > > The sooner you request time, the more likely you are to get some... > > Remember, we give priority to documents that have open issues than > would benefit from in person discussion. > > W From nobody Mon Jun 23 04:14:39 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F361B28ED for ; Mon, 23 Jun 2014 04:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vp1NZ9LpvYEG for ; Mon, 23 Jun 2014 04:14:23 -0700 (PDT) Received: from office.denic.de (office.denic.de [81.91.160.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149251ABB90 for ; Mon, 23 Jun 2014 04:14:17 -0700 (PDT) Received: from x27.adm.denic.de (x28.fra2.if.denic.de [10.122.64.17]) by office.denic.de with esmtp id 1Wz2CU-0006VE-IS; Mon, 23 Jun 2014 13:14:14 +0200 Received: from localhost by x27.adm.denic.de with local id 1Wz2CU-0004gD-ES; Mon, 23 Jun 2014 13:14:14 +0200 Date: Mon, 23 Jun 2014 13:14:14 +0200 From: Peter Koch To: dane@ietf.org Message-ID: <20140623111414.GE8868@x28.adm.denic.de> Mail-Followup-To: dane@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Archived-At: http://mailarchive.ietf.org/arch/msg/dane/bmo-UmdT9BPsONzK9c7m571l-fk Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 11:14:30 -0000 On Mon, Jun 23, 2014 at 06:16:01AM -0400, Warren Kumari wrote: > This document was written in response to a request, and so we are > compressing the more traditional 2 week call for adoption to instead > be a single week. > > Please let us know clearly if you *object* to this document being > adopted, with a clear explanation of why. I'd expect the next thing for the IETF is to introduce an objection fee ... > This call for adoption ends Monday 07-Jul-2014. ? I've read the draft but not any preceding discussion. Publishing (not "authenticating", please) raw keys in the DNS makes a lot of sense IMHO, but it's not obvious to me why the TLSA RR type is the right one. The document does not explain why the expansion of the usage "3" is backwards compatible, i.e., not confusing old clients. -Peter From nobody Mon Jun 23 08:02:17 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DDB1B2965 for ; Mon, 23 Jun 2014 08:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.2 X-Spam-Level: X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIpbthE3vnOt for ; Mon, 23 Jun 2014 08:02:12 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 287E21B2AFF for ; Mon, 23 Jun 2014 08:02:00 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EF8AC2AB0B4; Mon, 23 Jun 2014 15:01:58 +0000 (UTC) Date: Mon, 23 Jun 2014 15:01:58 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140623150158.GE17723@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.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/AdCECTWxe8DY5SVx1prxSOqqmIQ Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2014 15:02:16 -0000 On Mon, Jun 23, 2014 at 06:16:01AM -0400, Warren Kumari wrote: > This starts a Call for Adoption for draft-gilmore-dane-rawkeys-00. > The draft is available here: > https://datatracker.ietf.org/doc/draft-gilmore-dane-rawkeys-00/ I am a day or two away from essentially compatible language in the next (04) revision of draft-ietf-dane-ops. I have no major objections to the substance of the new draft, we'll mostly just need to decide how it relates to the revised ops draft, which is now a 6698 update. We should be able to merge the best parts of the two parallel treatments, and either expand the coverage of raw public keys in the ops draft, or shrink it, moving all coverage of this issue to the new draft. My technical issue with the new draft was that it seemed to suggest that any DANE-EE(3) TLSA RR can be used to match raw public keys, while in fact only DANE-EE(3) SPKI(1) matches raw public keys. The new draft operates at two layers, on the one hand concretely extending 6698 to support raw public keys, and on the other hand generalizing the approach to arbitrary "key material" (conceptually beyond even raw public keys). My best guess is that were some other kind of "key material" to be used with TLS, that is not in SPKI format, the draft is trying to suggest that we'd use DANE-EE(3) anyway (but likely with a new selector value, though this is not stated). I would for now not try to generalize beyond SPKI. It is not clear what those generalizations will really entail or whether any are likely to happen in the near future. Since I think "adoption" is not final approval of the content, but rather agreement that there is useful and relevant material to build on, while the draft is not done, I support adoption. -- Viktor. From nobody Mon Jun 23 09:01:04 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4B81B2BE5 for ; Mon, 23 Jun 2014 09:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wy5NrPsgDyDM for ; Mon, 23 Jun 2014 09:00:57 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B2E21B2B71 for ; Mon, 23 Jun 2014 08:58:03 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AA6DB82CCB for ; Mon, 23 Jun 2014 11:58:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1403539080; bh=0MdLiNKCk6AAqAb+2J/fEy97/1HqVyuVkenjLn2vYvg=; h=Date:From:To:Subject:In-Reply-To:References; b=qHMjqPefPlnBmsLw3mwSZ7uo1FSBno9aVKOZ9GM558GgHnn2f0fFr6QJz6ukmxTvB 4CbbvGbCwtXJFRqaDhMTUGpJOyW9Q0YjrA9TJeavLqvd1+6rjKZ/ltICui5gajdHxI eHvvX19cVW+Eux395emBUOmpHpwi9MecRE0kGjR0= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s5NFw0bg005370 for ; Mon, 23 Jun 2014 11:58:00 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 23 Jun 2014 11:58:00 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20140623150158.GE17723@mournblade.imrryr.org> Message-ID: References: <20140623150158.GE17723@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/NoEn75O4vc2mDE7r__HdDfckbcQ Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 16:01:02 -0000 On Mon, 23 Jun 2014, Viktor Dukhovni wrote: > The new draft operates at two layers, on the one hand concretely > extending 6698 to support raw public keys, and on the other hand > generalizing the approach to arbitrary "key material" (conceptually > beyond even raw public keys). My best guess is that were some > other kind of "key material" to be used with TLS, that is not in > SPKI format, Please note that this is to support non-TLS scenarios where the public key might not be transfered in-band like in the TLS case. That is, the draft extends 6698 to support publishing any kind of public key in SPKI format for verification. It does not suggest non-SPKI formats. > the draft is trying to suggest that we'd use DANE-EE(3) > anyway (but likely with a new selector value, though this is not > stated). Actually, the intend is to NOT introduce a new selector, especially for the TLS case to ease migration from PKIX certificate to raw public key. > I would for now not try to generalize beyond SPKI. I don't think it is? > It > is not clear what those generalizations will really entail or > whether any are likely to happen in the near future. Note that these kind of statements during 6698 discussion is what got us here to begin with. The reluctance of types not involving "PKIX certification". It would be very ironic to make that mistake twice. > Since I think "adoption" is not final approval of the content, but > rather agreement that there is useful and relevant material to > build on, while the draft is not done, I support adoption. That's right. And for the record, I support WG adoption of this document as well. Paul From nobody Mon Jun 23 09:03:12 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729711B2BFA for ; Mon, 23 Jun 2014 09:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5uj_-xIOhop for ; Mon, 23 Jun 2014 09:03:04 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03E291B2B69 for ; Mon, 23 Jun 2014 08:59:13 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4485C82CCB; Mon, 23 Jun 2014 11:59:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1403539152; bh=C4wbI4nWScTN1LhFzUbDQdV3Hf56kOVGFOTwstHqAo0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=dUSI16UUSiu9o9g4XPoeGyDU7mD/l5YNTZNeqvVYXB9rZ5UZAfQuk3LmDAf7b3Ser 8V88eB4aQjUQ0w9smuTZm2GKKGl646zLT/d1gRe4Sd8N1tofLACiJuB8HWjJv87Qpf bOVuCbPTCzLeLdMuVmUzl3dfEHBL78+MjJ2UuN1M= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s5NFxBa3005692; Mon, 23 Jun 2014 11:59:12 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 23 Jun 2014 11:59:11 -0400 (EDT) From: Paul Wouters To: Peter Koch In-Reply-To: <20140623111414.GE8868@x28.adm.denic.de> Message-ID: References: <20140623111414.GE8868@x28.adm.denic.de> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/17z5GjnW-HSSisxN96GegShf8_s Cc: dane@ietf.org Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 16:03:10 -0000 On Mon, 23 Jun 2014, Peter Koch wrote: > I've read the draft but not any preceding discussion. Publishing (not > "authenticating", please) raw keys in the DNS makes a lot of sense IMHO, > but it's not obvious to me why the TLSA RR type is the right one. > The document does not explain why the expansion of the usage "3" > is backwards compatible, i.e., not confusing old clients. old clients that did not support bare public key could not even use TLSA, so how can extending support break older clients? Paul From nobody Mon Jun 23 10:11:16 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8911A03BA for ; Mon, 23 Jun 2014 10:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.252 X-Spam-Level: X-Spam-Status: No, score=-1.252 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fITgyjxiMCzO for ; Mon, 23 Jun 2014 10:11:05 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 585791B2B81 for ; Mon, 23 Jun 2014 10:08:44 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 308171E03E; Mon, 23 Jun 2014 12:57:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1403543321; bh=3VIsNztkqjA94ow91LsFj5aw1tml/1etF1i0YEUOoTw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=nWJpOY7wcKbQyCSO3lLL1kECUQ/QPCLKEYWqVbMcBXGAXXwHhc8xLuaBrUKDGSuAV 3s2DehcdT8MXO1HDZaoYt2WcaQUx4CTDXro8w9aPCpj60mhYhaNjr6viaa24p1UYEp AXOM2SH1U9Abg4OvgUSR68eO9KHJphawYPWvKQhg= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 70CB76001E; Mon, 23 Jun 2014 12:50:56 +0000 (UTC) From: James Cloos To: Warren Kumari In-Reply-To: (Warren Kumari's message of "Mon, 23 Jun 2014 06:16:01 -0400") References: User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 23 Jun 2014 12:51:21 +0000 Message-ID: Lines: 15 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140623:warren@kumari.net::Hckld8eUtJFruPCW:0000000000000000000000000000000000000000000MxzIS X-Hashcash: 1:30:140623:dane\@ietf.org\::rtGaiekUtfcLIE+a:0814pc X-Hashcash: 1:30:140623:dane@ietf.org::Bdig+iVC8gXXMoI3:000JKYh8 X-Hashcash: 1:30:140623:draft-gilmore-dane-rawkeys-00@tools.ietf.org::Wku2M6fe86iMLylh:00000000000000006usRm Archived-At: http://mailarchive.ietf.org/arch/msg/dane/KRasavY36lj4u1wYtmfr2LzqFYE Cc: draft-gilmore-dane-rawkeys-00@tools.ietf.org, "" Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 17:11:11 -0000 >>>>> "WK" == Warren Kumari writes: WK> This starts a Call for Adoption for draft-gilmore-dane-rawkeys-00. For an intial draft, the document reasonably covers the issues. The wg should adopt it. WK> Please also indicate if you are willing to contribute text, review, etc. I am. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Mon Jun 23 10:34:40 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352741B2BA0 for ; Mon, 23 Jun 2014 10:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoYHCFd9_65l for ; Mon, 23 Jun 2014 10:34:36 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FADE1B2B9F for ; Mon, 23 Jun 2014 10:34:36 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BC4782AB298; Mon, 23 Jun 2014 17:34:34 +0000 (UTC) Date: Mon, 23 Jun 2014 17:34:34 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140623173434.GK17723@mournblade.imrryr.org> References: <20140623150158.GE17723@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.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/5MV7MxAs1s0ZGR407GKccNNx-Pc Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2014 17:34:38 -0000 On Mon, Jun 23, 2014 at 11:58:00AM -0400, Paul Wouters wrote: > >The new draft operates at two layers, on the one hand concretely > >extending 6698 to support raw public keys, and on the other hand > >generalizing the approach to arbitrary "key material" (conceptually > >beyond even raw public keys). My best guess is that were some > >other kind of "key material" to be used with TLS, that is not in > >SPKI format, > > Please note that this is to support non-TLS scenarios where the public > key might not be transferred in-band like in the TLS case. That is, > the draft extends 6698 to support publishing any kind of public key > in SPKI format for verification. It does not suggest non-SPKI formats. This was not clear. So the "TLSA" (does not stand for anything) acronym is not supposed to be understood to apply just to TLS (and by extension DTLS)? So for example, would it apply to publishing KDC public keys for cross-realm pkinit? Does it matter whether the lookup key for the RRDATA would likely not be "_port._proto.domain", or would that make the Kerberos cross-realm key use-case fall outside this update to 6698. In other words does the new draft only apply to some kind of transport layer security (lower case to distinguish from TLS) where the end-point identity is necessarily _port._proto, with with a TLSA-like RRDATA format? Recall that we've added a charter goal of defining something for client authentication, which is likely to reuse RFC 6698 RRDATA, but will probably carry a different lookup key. So if the scope of RFC 6698 is not TLS, is it just any application where the 6698 RRDATA format seems to be useful? -- Viktor. From nobody Mon Jun 23 10:58:20 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F081B27CD for ; Mon, 23 Jun 2014 10:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.598 X-Spam-Level: * X-Spam-Status: No, score=1.598 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_BRBL_LASTEXT=1.449, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uN3OB8_ivXpQ for ; Mon, 23 Jun 2014 10:58:17 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD251B29C9 for ; Mon, 23 Jun 2014 10:58:14 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id s5NHwAeo028474 for ; Mon, 23 Jun 2014 10:58:10 -0700 Message-Id: <201406231758.s5NHwAeo028474@new.toad.com> To: dane@ietf.org In-reply-to: <20140623173434.GK17723@mournblade.imrryr.org> References: <20140623150158.GE17723@mournblade.imrryr.org> <20140623173434.GK17723@mournblade.imrryr.org> Comments: In-reply-to Viktor Dukhovni message dated "Mon, 23 Jun 2014 17:34:34 -0000." Date: Mon, 23 Jun 2014 10:58:10 -0700 From: John Gilmore Archived-At: http://mailarchive.ietf.org/arch/msg/dane/WSfgpsEnHdY1a1S18xUNPbM9iuM Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 17:58:20 -0000 > So if the scope of RFC 6698 is not TLS, is it just any application > where the 6698 RRDATA format seems to be useful? "What is the scope of the TLSA record?" is a great question to ask ourselves. (We may not ultimately need to answer it clearly; we may agree to hold different opinions.) My goals in the draft were, first, to enable the use of DNSSEC/DANE with TLS raw public keys; second, to repeal the statements in RFC 6698 that prevent the use of the TLSA record with keys that aren't in PKIX certificates. I only took on the second goal because it was required to enable the first goal. But once we have opened the door to raw public keys for TLS (at port numbers where TLS is used), I saw no reason to add restrictive language preventing anyone from using raw public keys at other ports or for other protocols. The name-prefixed design of the TLSA record tends to prevent such other uses from causing any problems to its main use with TLS. I see the goal of IETF standards as enabling interoperability. Where restrictions on user choices are needed to enable interoperability, we restrict them (e.g. with MUSTs or MUST NOTs). Where interoperability is not threatened, we need not and should not restrict users to only the usages and protocols that we have in mind today. > So for example, would it apply to publishing KDC public keys for > cross-realm pkinit? Does it matter whether the lookup key for the > RRDATA would likely not be "_port._proto.domain", or would that > make the Kerberos cross-realm key use-case fall outside this update > to 6698. In other words does the new draft only apply to some > kind of transport layer security (lower case to distinguish from > TLS) where the end-point identity is necessarily _port._proto, > with with a TLSA-like RRDATA format? When I was working on Kerberos many years ago, the KDC was running on a particular, standardized port (UDP port 88). So it probably would fit into the TLSA scheme at _88._udp.example.com if we wanted it to. A larger issue with Kerberos at that time was the protocol's insistence that Kerberos "realms" are not "domain names". To emphasize that distinction, the Kerberos documentation and common usage tended to make realms names UPPERCASE. At the time, that seemed to me to be a relatively useless distinction, but I was a newcomer to Kerberos. At Cygnus, we evolved the Kerberos software such that if you chose to make your realm name match your domain name, the software would do useful things by default, that would require pre-configuration if your realm name did not match your domain name. I do not know if that usage has caught on. In the Raw Public Keys draft, I had no intent to change the TLSA requirement for a _port._proto prefix, so if Kerberos realm authentication with TLSA ultimately ends up requiring such a change, the future DANE Kerberos draft itself will probably have to relax that requirement. John From nobody Mon Jun 23 14:05:54 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C33C1B2C72 for ; Mon, 23 Jun 2014 14:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, J_CHICKENPOX_25=0.6, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEIppIg-8Q5W for ; Mon, 23 Jun 2014 14:05:49 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40FAE1B2C03 for ; Mon, 23 Jun 2014 14:05:49 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s5NL5hRM009311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Jun 2014 23:05:43 +0200 (MEST) In-Reply-To: To: Paul Wouters Date: Mon, 23 Jun 2014 23:05:42 +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: <20140623210543.031891AD5E@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/dane/iGD3hrbCUNV8ipZ2TdOMlzlshfE Cc: Peter Koch , dane@ietf.org Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 23 Jun 2014 21:05:52 -0000 Paul Wouters wrote: > Peter Koch wrote: > >> I've read the draft but not any preceding discussion. Publishing (not >> "authenticating", please) raw keys in the DNS makes a lot of sense IMHO, >> but it's not obvious to me why the TLSA RR type is the right one. >> The document does not explain why the expansion of the usage "3" >> is backwards compatible, i.e., not confusing old clients. > > old clients that did not support bare public key could not even use > TLSA, so how can extending support break older clients? To me this looks like you're talking past each other. The Selector Type 1 "SubjectPublicKeyInfo" is already defined (Section 7.3) and explained (Appendic A.1.2.2) in rfc6698: https://tools.ietf.org/html/rfc6698#section-7.3 https://tools.ietf.org/html/rfc6698#appendix-A.1.2.2 Existing TLSA/DANE-aware TLS clients will (silently) assume, that this selector refers to a public key that is embedded in a more-or-less regular X.509 certificate, and that this certificate will appear in the (PKIX) certification path that the TLS client came up with for certificate path verification. The newly envisoned usage scenario seems to be for use by TLS peers with bare public keys (i.e. that do not exchange any certificates at all and do not, or not necessarily manage such keys with an X.509 cert wrapper/container. In theory, this looks like TLSA/DANE aware clients might get confused, assuming that they will be able to locate a cert in the computed (or server-supplied) certificate chain, and fail DANE validation if they cannot match. In practice, a guidance for the server admin to supply cert-based TLSA records might be sufficient, whenever interop with clients that do not support bare public is desired. To be usable with bare public keys at all, both, client and server will have to support bare public keys, and the client will have to offer their use in ClientHello through a TLS extension and the server will have to agree using it. The server does not (currently) learn whether the client is DANE/TLSA-aware, but certainly knows whether the client supports and is willing to accept a bare server key in the TLS handshake. One common case where the SPKI selector may help in traditional PKIX is in CrossCA / Bridged PKI scenarios, or the backward-compatibility-hack usage scenarios used by a few public CAs these days -- where the current PKI is normally operated with a 2048-bit self-signed RootCA certificate, but that new self-signed RootCA cert might not be known to older TLS clients, and therefore many servers are sending out a crossCA certificate in the forward certification path of the Server's Certificate TLS handshake message for the new 2048-bit root that is signed by the old 1024-bit root that is known to old TLS clients. One common example is the VeriSign/Symantec CN=VeriSign Class 3 Public Primary Certification Authority - G5 which exists as a self-signed rootCA cert and as a crossCA cert signed by the 1024-bit RSA key of the old OU=Class 3 Public Primary Certification Authority And of that latter old VeriSign Root, there exist two different (three if one includes the jan-2004 expired root in the count) certs with the same public key (i.e. SubjectPublicKeyInfo) in them: serial (md2RSA sig): 70 ba e4 1d 10 d9 29 34 b6 38 ca 7b 03 cc ba bf serial (sha1RSA sig): 3c 91 31 cb 1f f6 d0 1b 0e 9a b8 d0 44 bf 12 be -Martin From nobody Mon Jun 23 14:42:44 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E312D1B2D0D for ; Mon, 23 Jun 2014 14:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.5 X-Spam-Level: X-Spam-Status: No, score=-100.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBuz9vJAf7Op for ; Mon, 23 Jun 2014 14:42:40 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55CA1B2D1A for ; Mon, 23 Jun 2014 14:42:24 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EBD1E2AB298; Mon, 23 Jun 2014 21:42:22 +0000 (UTC) Date: Mon, 23 Jun 2014 21:42:22 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140623214222.GM17723@mournblade.imrryr.org> References: <20140623210543.031891AD5E@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140623210543.031891AD5E@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/CxSDtEOzd1cm9khmDuG_QnIMrUg Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2014 21:42:43 -0000 On Mon, Jun 23, 2014 at 11:05:42PM +0200, Martin Rex wrote: > The Selector Type 1 "SubjectPublicKeyInfo" is already defined (Section 7.3) > and explained (Appendic A.1.2.2) in rfc6698: > > https://tools.ietf.org/html/rfc6698#section-7.3 > https://tools.ietf.org/html/rfc6698#appendix-A.1.2.2 > > Existing TLSA/DANE-aware TLS clients will (silently) assume, that this > selector refers to a public key that is embedded in a more-or-less regular > X.509 certificate, Hence the 6698 update. If the service is in fact a TLS service, clients using X.509 handshakes will not see anything new, because they won't use the new extension to negotiate use of raw public keys. > and that this certificate will appear in the > (PKIX) certification path that the TLS client came up with for > certificate path verification. DANE-EE(3) is not PKIX and has no PKIX path. > The newly envisoned usage scenario seems to be for use by TLS peers > with bare public keys (i.e. that do not exchange any certificates at > all and do not, or not necessarily manage such keys with an X.509 cert > wrapper/container. Many clients will support both, and servers even more so may be willing to use the same public either adorned in X.509v3 finery, or bare (with or without the emperor's new clothes). > In theory, this looks like TLSA/DANE aware clients might get confused, The underlying meaning of "DANE-EE(3) SPKI(1) ?" is unchanged, it matches a leaf SPKI object in either form. There is no confusion. -- Viktor. From nobody Mon Jun 23 15:01:23 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611EE1B2D2B for ; Mon, 23 Jun 2014 15:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkeDJ2DObDif for ; Mon, 23 Jun 2014 15:01:14 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCDC71B2D30 for ; Mon, 23 Jun 2014 15:00:29 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s5NM0Rpm010062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 24 Jun 2014 00:00:27 +0200 (MEST) In-Reply-To: <20140623214222.GM17723@mournblade.imrryr.org> To: dane@ietf.org Date: Tue, 24 Jun 2014 00:00:27 +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: <20140623220027.2C6AE1AD5E@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/dane/S6zQzBTnab3c5FMuPAhRUu7B9uE Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 23 Jun 2014 22:01:19 -0000 Viktor Dukhovni wrote: > > The underlying meaning of "DANE-EE(3) SPKI(1) ?" is unchanged, it > matches a leaf SPKI object in either form. There is no confusion. It will not be possible to use DANE only for bare keys and traditional PKIX _without_ DANE for certificate-based authentication, because DANE/TLSA-aware clients, that do not support bare keys in TLS, would encounter a DANE validation failure with the PKIX cert they get from the server. -Martin From nobody Mon Jun 23 15:13:22 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9F61B2D09 for ; Mon, 23 Jun 2014 15:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9Y-xkaCIlUe for ; Mon, 23 Jun 2014 15:13:16 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F821B2B23 for ; Mon, 23 Jun 2014 15:13:16 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id AE6D42AB298; Mon, 23 Jun 2014 22:13:14 +0000 (UTC) Date: Mon, 23 Jun 2014 22:13:14 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140623221314.GN17723@mournblade.imrryr.org> References: <20140623214222.GM17723@mournblade.imrryr.org> <20140623220027.2C6AE1AD5E@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140623220027.2C6AE1AD5E@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/JgV41lyGJ4ucuq4DyrCSO67LEoc Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2014 22:13:18 -0000 On Tue, Jun 24, 2014 at 12:00:27AM +0200, Martin Rex wrote: > Viktor Dukhovni wrote: > > > > The underlying meaning of "DANE-EE(3) SPKI(1) ?" is unchanged, it > > matches a leaf SPKI object in either form. There is no confusion. > > It will not be possible to use DANE only for bare keys and > traditional PKIX _without_ DANE for certificate-based authentication, > because DANE/TLSA-aware clients, that do not support bare keys in TLS, > would encounter a DANE validation failure with the PKIX cert they get > from the server. This is simply not the case. The TLSA RRset contains multiple records. If the server is designed to serve clients that employ traditional X.509 handshakes (not just clients that do RPK), then that server's TLSA RRset needs to include at least one TLSA RR that matches the server's chain presented in its TLS "certitificate message". Typically the same TLSA record: _443._tcp.www.example.com. IN TLSA 3 1 1 {SPKI-SHA2-256-digest} is sufficient to match both the bare key and the *same* key embedded in an X.509v3 certificate. If for some reason the "bare" keys are not available in certificate finery, the RRset needs to list multiple values: _443._tcp.www.example.com. IN TLSA 3 1 1 {crt-SPKI-SHA2-256-digest} _443._tcp.www.example.com. IN TLSA 3 1 1 {rpk-SPKI-SHA2-256-digest} Where the first record is for the leaf certificate and the second is for the bare key, repeated as necessary for additional certs and additional bare keys, with the usual transitional states for key rollover. -- Viktor. From nobody Mon Jun 23 15:24:05 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D8B1B2D2B for ; Mon, 23 Jun 2014 15:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bovecuw4z5rF for ; Mon, 23 Jun 2014 15:24:00 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6264F1B2D28 for ; Mon, 23 Jun 2014 15:24:00 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s5NMNvp3020403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 24 Jun 2014 00:23:57 +0200 (MEST) In-Reply-To: <20140623221314.GN17723@mournblade.imrryr.org> To: dane@ietf.org Date: Tue, 24 Jun 2014 00:23:57 +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: <20140623222357.A50B41AD5E@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/dane/8hduUSj6AgNJmJOaa62BezjJbCQ Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 23 Jun 2014 22:24:02 -0000 Viktor Dukhovni wrote: > > is sufficient to match both the bare key and the *same* key embedded > in an X.509v3 certificate. If for some reason the "bare" keys are > not available in certificate finery, the RRset needs to list multiple > values: > > _443._tcp.www.example.com. IN TLSA 3 1 1 {crt-SPKI-SHA2-256-digest} > _443._tcp.www.example.com. IN TLSA 3 1 1 {rpk-SPKI-SHA2-256-digest} > > Where the first record is for the leaf certificate and the second > is for the bare key, repeated as necessary for additional certs > and additional bare keys, with the usual transitional states for > key rollover. Thank your for agreeing with me. :) This is the missing guidance for the server admin that I talked about. You can not make a DANE/TLSA-aware TLS client that does not support bare keys at the TLS protocol level, to *not* try matching SPKI TLSA records to certs exchanged at the TLS protocol level, because it is not possible to mark an SPKI selector as applying only to bare keys. -Martin From nobody Mon Jun 23 16:00:47 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E591B2D33 for ; Mon, 23 Jun 2014 16:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7lPdqGy5sRS for ; Mon, 23 Jun 2014 16:00:40 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14A41B2D31 for ; Mon, 23 Jun 2014 16:00:39 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1A0B72AB298; Mon, 23 Jun 2014 23:00:38 +0000 (UTC) Date: Mon, 23 Jun 2014 23:00:38 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140623230038.GO17723@mournblade.imrryr.org> References: <20140623221314.GN17723@mournblade.imrryr.org> <20140623222357.A50B41AD5E@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140623222357.A50B41AD5E@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/QrYcWCeUI2t2jntxopOaQjLxN7s Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jun 2014 23:00:45 -0000 On Tue, Jun 24, 2014 at 12:23:57AM +0200, Martin Rex wrote: > Viktor Dukhovni wrote: > > > > is sufficient to match both the bare key and the *same* key embedded > > in an X.509v3 certificate. If for some reason the "bare" keys are > > not available in certificate finery, the RRset needs to list multiple > > values: > > > > _443._tcp.www.example.com. IN TLSA 3 1 1 {crt-SPKI-SHA2-256-digest} > > _443._tcp.www.example.com. IN TLSA 3 1 1 {rpk-SPKI-SHA2-256-digest} > > > > Where the first record is for the leaf certificate and the second > > is for the bare key, repeated as necessary for additional certs > > and additional bare keys, with the usual transitional states for > > key rollover. > > Thank your for agreeing with me. :) You're welcome. My expectation is that in most cases, servers that support both X.509 certs and bare keys, will simply use the keys embedded in their certs as their bare keys, and the issue will be moot. > This is the missing guidance for the server admin that I talked about. However, explicit guidance would not be out of order. > You can not make a DANE/TLSA-aware TLS client that does not support > bare keys at the TLS protocol level, to *not* try matching SPKI TLSA > records to certs exchanged at the TLS protocol level, because it > is not possible to mark an SPKI selector as applying only to bare keys. Yes, this is intentional. Fortunately, we have a TLSA RRset, rather than a single RR, to work with and it is possible to public simultaneous associations for multiple "key material" objects. -- Viktor. From nobody Mon Jun 23 23:17:07 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C251B2847; Mon, 23 Jun 2014 23:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EImY36Zftys6; Mon, 23 Jun 2014 23:17:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B941B2852; Mon, 23 Jun 2014 23:17:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140624061702.30418.90850.idtracker@ietfa.amsl.com> Date: Mon, 23 Jun 2014 23:17:02 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/6fsVTmr8HZBeYl5tmB8Elrc5qwQ Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-ops-04.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 06:17:06 -0000 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 : Updates to and Operational Guidance for the DANE Protocol Authors : Viktor Dukhovni Wes Hardaker Filename : draft-ietf-dane-ops-04.txt Pages : 27 Date : 2014-06-23 Abstract: This memo clarifies and updates the DANE TLSA protocol based on implementation experience since the publication of the original specification [RFC6698]. It also contains guidance for DANE implementers and operators. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-ops/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-ops-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-ops-04 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 nobody Mon Jun 23 23:23:53 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25ED41B2843 for ; Mon, 23 Jun 2014 23:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUzCldsNHh4z for ; Mon, 23 Jun 2014 23:23:49 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D4591B2800 for ; Mon, 23 Jun 2014 23:23:49 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5259B2AB298; Tue, 24 Jun 2014 06:23:47 +0000 (UTC) Date: Tue, 24 Jun 2014 06:23:47 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140624062346.GW17723@mournblade.imrryr.org> References: <20140624061702.30418.90850.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140624061702.30418.90850.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/bYvN9o5u2_f7LRyBxTNYRDxDktE Subject: Re: [dane] I-D Action: draft-ietf-dane-ops-04.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 24 Jun 2014 06:23:51 -0000 On Mon, Jun 23, 2014 at 11:17:02PM -0700, internet-drafts@ietf.org wrote: > This draft is a work item of the DNS-based Authentication of > Named Entities Working Group of the IETF. > > Title : Updates to and Operational Guidance for the DANE Protocol > Authors : Viktor Dukhovni > Wes Hardaker > Filename : draft-ietf-dane-ops-04.txt > Pages : 27 > Date : 2014-06-23 > > Abstract: > This memo clarifies and updates the DANE TLSA protocol based on > implementation experience since the publication of the original > specification [RFC6698]. It also contains guidance for DANE > implementers and operators. This draft has been on the back-burner for a while, while work on the SMTP draft took precedence. Wes and I have returned our attention to this document, which is now slated to be a standards-track update to 6698. Thus the -04 version is a substantial revision, and very much still a work in progress, a first step on a new journey. If anyone reviewing the document would like to suggest edits, the best mechanism is perhaps a pull-request at: https://github.com/vdukhovni/ietf.git it would I think be useful for the DANE WG to have a more formal git repository. I believe the TLS WG has one now, and perhaps we can follow their example. -- Viktor. From nobody Tue Jun 24 02:53:13 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800661B2833 for ; Tue, 24 Jun 2014 02:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uR1JVhD77V-y for ; Tue, 24 Jun 2014 02:53:06 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2F4D1B28BC for ; Tue, 24 Jun 2014 02:53:03 -0700 (PDT) Received: from [10.143.192.92] ([31.55.26.119]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s5O9qsqB074321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 24 Jun 2014 02:52:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host [31.55.26.119] claimed to be [10.143.192.92] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Paul Hoffman In-Reply-To: Date: Tue, 24 Jun 2014 10:52:53 +0100 Content-Transfer-Encoding: 7bit Message-Id: <41225121-2592-463C-8146-64357F28C94E@vpnc.org> References: To: dane@ietf.org X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/3uMPITALcmzp86yoNQb1JWRedTw Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 09:53:07 -0000 This document seems fine as a start for a WG document. --Paul Hoffman From nobody Tue Jun 24 02:58:08 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCAD81B28CB for ; Tue, 24 Jun 2014 02:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvnO1UWvCA45 for ; Tue, 24 Jun 2014 02:58:04 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C3521B28BC for ; Tue, 24 Jun 2014 02:58:04 -0700 (PDT) Received: from [10.143.192.92] ([31.55.26.119]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s5O9vxg5074409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jun 2014 02:58:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host [31.55.26.119] claimed to be [10.143.192.92] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Paul Hoffman In-Reply-To: Date: Tue, 24 Jun 2014 10:57:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140623150158.GE17723@mournblade.imrryr.org> To: Paul Wouters X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/sYl6dmxlczRZ4rSplj4iprPG6-o Cc: dane@ietf.org Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 09:58:04 -0000 On Jun 23, 2014, at 4:58 PM, Paul Wouters wrote: > Please note that this is to support non-TLS scenarios where the public > key might not be transfered in-band like in the TLS case. I see nothing in the draft that suggests that it would update 6698 to = cover any protocol other than TLS and DTLS. If the WG adopts the = document, the document should be clearer that the keying material is = only for TLS and DTLS. Any other use would require a different protocol = document that would use a different RRtype (even if that RRtype uses the = same record format. --Paul Hoffman= From nobody Tue Jun 24 12:35:21 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFA71A00AE for ; Tue, 24 Jun 2014 12:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.598 X-Spam-Level: * X-Spam-Status: No, score=1.598 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_BRBL_LASTEXT=1.449, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBVzCF-GhKMD for ; Tue, 24 Jun 2014 12:35:17 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 375B11A00D3 for ; Tue, 24 Jun 2014 12:35:15 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id s5OJZAeo032289; Tue, 24 Jun 2014 12:35:10 -0700 Message-Id: <201406241935.s5OJZAeo032289@new.toad.com> To: Warren Kumari In-reply-to: References: Comments: In-reply-to Warren Kumari message dated "Mon, 23 Jun 2014 06:16:33 -0400." Date: Tue, 24 Jun 2014 12:35:10 -0700 From: John Gilmore Archived-At: http://mailarchive.ietf.org/arch/msg/dane/1DyCdljyDgKtSbPE_CKdeS8XSO8 Cc: "" Subject: Re: [dane] IPR check on draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 19:35:18 -0000 > Are you personally aware of any IPR that applies to > draft-gilmore-dane-rawkeys-00? I am not aware of any IPR that applies to draft-gilmore-dane-rawkeys-00. (There is little or no invention in the draft; it applies already- standardized formats and procedures in a very slightly different context.) John From nobody Tue Jun 24 13:54:20 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E291B291E for ; Tue, 24 Jun 2014 13:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.598 X-Spam-Level: * X-Spam-Status: No, score=1.598 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_BRBL_LASTEXT=1.449, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiKW81VEi2IZ for ; Tue, 24 Jun 2014 13:54:16 -0700 (PDT) Received: from new.toad.com (new.toad.com [209.237.225.253]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F3171B28CF for ; Tue, 24 Jun 2014 13:52:42 -0700 (PDT) Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id s5OKqdeo003390 for ; Tue, 24 Jun 2014 13:52:39 -0700 Message-Id: <201406242052.s5OKqdeo003390@new.toad.com> To: dane@ietf.org In-reply-to: <20140623173434.GK17723@mournblade.imrryr.org> References: <20140623150158.GE17723@mournblade.imrryr.org> <20140623173434.GK17723@mournblade.imrryr.org> Comments: In-reply-to Viktor Dukhovni message dated "Mon, 23 Jun 2014 17:34:34 -0000." Date: Tue, 24 Jun 2014 13:52:39 -0700 From: John Gilmore Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Nkrnmgp4h2Nb1ENr_IasAnDIt1c Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 20:54:17 -0000 Paul Wouters said: > > Please note that this is to support non-TLS scenarios where the public > > key might not be transferred in-band like in the TLS case. That is, > > the draft extends 6698 to support publishing any kind of public key > > in SPKI format for verification. It does not suggest non-SPKI formats. Paul Hoffman said: > I see nothing in the draft that suggests that it would update 6698 to > cover any protocol other than TLS and DTLS. If the WG adopts the > document, the document should be clearer that the keying material is > only for TLS and DTLS. Any other use would require a different > protocol document that would use a different RRtype (even if that > RRtype uses the same record format. I see two issues mentioned here. One is whether the TLSA record should be deliberately restricted by the WG to never be used by any protocol other than TLS. The second is whether TLS always transfers the public key in-band (thus obviating the need for a way to publish a TLS key in the DNS). On the first issue, we are already having to amend the TLSA RFC to remove deliberate restrictions that were written into it. I have not seen any way that these restrictions improve interoperability; in fact, they detract from interoperability by blocking usages that would work technically. The Raw Public Keys TLS extension would not have needed to amend the TLSA RFC at all, if the TLSA RFC did not contain explicit wording excluding the use of key formats other than a single choice. It could have merely been an add-on extension, if not for those few restrictive sentences. In amending the TLSA RFC for raw public keys, we could remove those deliberate restrictions, and then write new deliberate restrictions. Paul Hoffman's comment above seems to be advocating for that position. Instead, I am advocating for not adding restrictions that have no technical or interoperability rationale. It is not the role of an IETF working group to tell users that they are not allowed to use a protocol that would work for them and that would interoperate cleanly with other users. It's like a WG saying, "You can't use the ssh protocol to implement rsync or git, because ssh is only designed for interactive shells. Each of those applications has to design their own ssh-equivalent protocol", or "The ntpdate program can't use the NTP protocol to get a single estimate of the current time, because the protocol is only designed for doing long-term synchronization among multiple time servers". To quote Dennis Allison, we should be standing on each others' shoulders, not each others' toes. The second issue is the use of the TLSA record to publish a key in its entirety, rather than to merely authenticate the key with a hash value. RFC 7250 (raw public keys) specifies that the server will send its raw public key to the client, in the TLS transaction. So, in the current case, authenticating that key is all that is absolutely required. However, there is a separate TLS WG draft, draft-ietf-tls-cached-info-16.txt, which provides a way to reduce the bandwidth required. It has the client send a hash of the server's raw public key (or cert chain) that it already knows. If the server agrees that that's the public key, it agrees and does not send the server's public key (or certificate chain) in the TLS transaction. This draft is optionally used by CoAP without DANE, using a pre-cached server public key, but its protocol extension can also be used with DANE. When this draft TLS extension is used with DANE, the client has the option to do a TLSA domain lookup first, then, if it receives a full public key in that TLSA RRset, it can hash the public key and send that hash when starting the TLS transaction. If the server agrees that that hash matches its current public key, it sends back agreement and doesn't send another copy of the key. While highly interactive applications like web browsers might not want to serialize the TLSA lookup and the TLS transaction, serializing them to reduce transmitted bytes might be a popular implementation choice for a queued near-realtime application like SMTP, or for a background operation like checking for or downloading software or firmware updates. This is another case (like the ssh example above) where the existing TLSA protocol provides an easy way to do what is needed to use this cached-info TLS protocol variant (authentically publish the whole raw public key). If we were to add more restrictive wording to the TLSA definition (for example, if we restricted TLSA to merely being usable for authentication, never for publication) then that restriction would prevent users from interoperably doing an obvious thing that they wish to do. I suggest that we avoid adding such restrictions. John From nobody Tue Jun 24 16:30:57 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9FB41B29CB for ; Tue, 24 Jun 2014 16:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.753 X-Spam-Level: X-Spam-Status: No, score=-0.753 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJZz_oJSmVPB for ; Tue, 24 Jun 2014 16:30:52 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 701B91B29B6 for ; Tue, 24 Jun 2014 16:30:52 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 40BDE1ED6E; Tue, 24 Jun 2014 23:30:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1403652649; bh=OkNV5LQa/U+/fpxm2sT3CtztxT1eXQXz5e+g9ouaznw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=AemO1mo09NDNemPkTuuY0rhkR7343rta3HozthnP5kkU1MHiMI5QII7I/6w0D5h7+ LaaAX3FDzfvjHr4qJhr6yJ31PNuRDOY9vrEdmim0KHXVYXmDllr5SjO93I1H2SpQ1r AUhJHenQS/va1kLgxboG3okAdjCnJHNhdiofm/EA= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 2390F6001E; Tue, 24 Jun 2014 23:23:26 +0000 (UTC) From: James Cloos To: John Gilmore In-Reply-To: <201406242052.s5OKqdeo003390@new.toad.com> (John Gilmore's message of "Tue, 24 Jun 2014 13:52:39 -0700") References: <20140623150158.GE17723@mournblade.imrryr.org> <20140623173434.GK17723@mournblade.imrryr.org> <201406242052.s5OKqdeo003390@new.toad.com> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 24 Jun 2014 19:23:01 -0400 Message-ID: Lines: 26 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140624:gnu@toad.com::3Znh57zDqfTuzOXP:0000G73y+ X-Hashcash: 1:30:140624:dane@ietf.org::14stGa4McCn8b5m6:000OyiP0 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/xfpfGYxVoa_oH1sLT_8IIwc97hc Cc: dane@ietf.org Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jun 2014 23:30:55 -0000 >>>>> "JG" == John Gilmore writes: JG> In amending the TLSA RFC for raw public keys, we could remove those JG> deliberate restrictions, and then write new deliberate restrictions. JG> Paul Hoffman's comment above seems to be advocating for that position. JG> Instead, I am advocating for not adding restrictions that have no JG> technical or interoperability rationale. On that topic, not only do I agree that language which tries to restrict TLSA records to TLS is undesirable, I cannot discern *any* value in such restrictions. The software for any protocol which uses x.509 certs or which can handle spki-formated transmission of public keys should feel to use tlsa records to authenticate said certs or spkis. Even if it is a protocol which does not listen(2) on a fixed port and therefore would need to search for tlsa records differently than 6698 describes. If an alternate use of a given dns rr would lead to some sort of conflict which would break other uses, there would be valid cause to advocate against such breakage. But I do not see how using tlsa records for non- tls protocols would do that. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Wed Jun 25 19:52:44 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5ED91B2A35 for ; Wed, 25 Jun 2014 19:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJTgh5mgnZ9C for ; Wed, 25 Jun 2014 19:52:39 -0700 (PDT) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E41D1B2A2A for ; Wed, 25 Jun 2014 19:52:39 -0700 (PDT) Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 25 Jun 2014 22:52:37 -0400 Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 25 Jun 2014 22:52:36 -0400 Received: from b01cxnp23033.gho.pok.ibm.com (b01cxnp23033.gho.pok.ibm.com [9.57.198.28]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 8BD6CC90026 for ; Wed, 25 Jun 2014 22:52:28 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by b01cxnp23033.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s5Q2qYJ161669432 for ; Thu, 26 Jun 2014 02:52:34 GMT Received: from d01av02.pok.ibm.com (localhost [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s5Q2qYov002403 for ; Wed, 25 Jun 2014 22:52:34 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.63.10.95]) by d01av02.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s5Q2qYtF002397; Wed, 25 Jun 2014 22:52:34 -0400 In-Reply-To: References: <20140623150158.GE17723@mournblade.imrryr.org> <20140623173434.GK17723@mournblade.imrryr.org> <201406242052.s5OKqdeo003390@new.toad.com> To: James Cloos MIME-Version: 1.0 X-KeepSent: FC41B445:AF39556A-85257D02:007817B1; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0.1 October 14, 2013 From: Tom Gindin Message-ID: Date: Wed, 25 Jun 2014 22:52:32 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 9.0.1FP1HF1|April 25, 2014) at 06/25/2014 22:52:33, Serialize complete at 06/25/2014 22:52:33 Content-Type: multipart/alternative; boundary="=_alternative 000FCB4E85257D03_=" X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14062602-5806-0000-0000-0000253C00F1 Archived-At: http://mailarchive.ietf.org/arch/msg/dane/1FySYhOaw03nLGfU2G637oIF6Sg Cc: dane@ietf.org Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2014 02:52:42 -0000 This is a multipart message in MIME format. --=_alternative 000FCB4E85257D03_= Content-Type: text/plain; charset="US-ASCII" James: Would not SECSH clients in particular be able to benefit from this record type for raw public keys, if supported on an Intranet DNS? Tom Gindin P.S. The above suggestion is mine, and not that of my employer. From: James Cloos To: John Gilmore Cc: dane@ietf.org Date: 06/24/2014 07:31 PM Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 Sent by: "dane" >>>>> "JG" == John Gilmore writes: JG> In amending the TLSA RFC for raw public keys, we could remove those JG> deliberate restrictions, and then write new deliberate restrictions. JG> Paul Hoffman's comment above seems to be advocating for that position. JG> Instead, I am advocating for not adding restrictions that have no JG> technical or interoperability rationale. On that topic, not only do I agree that language which tries to restrict TLSA records to TLS is undesirable, I cannot discern *any* value in such restrictions. The software for any protocol which uses x.509 certs or which can handle spki-formated transmission of public keys should feel to use tlsa records to authenticate said certs or spkis. Even if it is a protocol which does not listen(2) on a fixed port and therefore would need to search for tlsa records differently than 6698 describes. If an alternate use of a given dns rr would lead to some sort of conflict which would break other uses, there would be valid cause to advocate against such breakage. But I do not see how using tlsa records for non- tls protocols would do that. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane --=_alternative 000FCB4E85257D03_= Content-Type: text/html; charset="US-ASCII"         James:
        Would not SECSH clients in particular be able to benefit from this record type for raw public keys, if supported on an Intranet DNS?

               Tom Gindin
P.S.        The above suggestion is mine, and not that of my employer.



From:        James Cloos <cloos@jhcloos.com>
To:        John Gilmore <gnu@toad.com>
Cc:        dane@ietf.org
Date:        06/24/2014 07:31 PM
Subject:        Re: [dane] Compressed Call for Adoption:        draft-gilmore-dane-rawkeys-00
Sent by:        "dane" <dane-bounces@ietf.org>



>>>>> "JG" == John Gilmore <gnu@toad.com> writes:

JG> In amending the TLSA RFC for raw public keys, we could remove those
JG> deliberate restrictions, and then write new deliberate restrictions.
JG> Paul Hoffman's comment above seems to be advocating for that position.
JG> Instead, I am advocating for not adding restrictions that have no
JG> technical or interoperability rationale.

On that topic, not only do I agree that language which tries to restrict
TLSA records to TLS is undesirable, I cannot discern *any* value in such
restrictions.

The software for any protocol which uses x.509 certs or which can handle
spki-formated transmission of public keys should feel to use tlsa records
to authenticate said certs or spkis.  Even if it is a protocol which does
not listen(2) on a fixed port and therefore would need to search for tlsa
records differently than 6698 describes.

If an alternate use of a given dns rr would lead to some sort of conflict
which would break other uses, there would be valid cause to advocate
against such breakage.  But I do not see how using tlsa records for non-
tls protocols would do that.

-JimC
--
James Cloos <cloos@jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6

_______________________________________________
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane
--=_alternative 000FCB4E85257D03_=-- From nobody Wed Jun 25 23:23:03 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666091B2F1F for ; Wed, 25 Jun 2014 23:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meVhmS2eoD9f for ; Wed, 25 Jun 2014 23:23:00 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 966ED1B2EA8 for ; Wed, 25 Jun 2014 23:23:00 -0700 (PDT) Received: from [10.143.194.80] ([109.144.245.193]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s5Q6MuZd095909 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 25 Jun 2014 23:22:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host [109.144.245.193] claimed to be [10.143.194.80] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Paul Hoffman In-Reply-To: <201406242052.s5OKqdeo003390@new.toad.com> Date: Thu, 26 Jun 2014 07:22:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140623150158.GE17723@mournblade.imrryr.org> <20140623173434.GK17723@mournblade.imrryr.org> <201406242052.s5OKqdeo003390@new.toad.com> To: dane@ietf.org X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/xHw7qTMRsWhcUnA9VMH9z81GFS0 Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2014 06:23:01 -0000 Having read the author's message to the mailing list that he intends = this draft to update RFC 6698 to apply to unnamed protocols, not just = TLS, I rescind my support for the draft. I still fully support updating = 6698 to cover "keying material" instead of "certificates" in the manner = discussed in the -00 draft. I would also support a different draft that = says "the TLSA record can be used in the following protocols in the = following fashions". --Paul Hoffman= From nobody Thu Jun 26 08:21:12 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B071B2FA0 for ; Thu, 26 Jun 2014 08:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEHc1cTLfYRB for ; Thu, 26 Jun 2014 08:21:08 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74F121B2F9E for ; Thu, 26 Jun 2014 07:26:49 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5F5D82AAD93; Thu, 26 Jun 2014 14:26:47 +0000 (UTC) Date: Thu, 26 Jun 2014 14:26:47 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140626142647.GZ16666@mournblade.imrryr.org> References: <20140623150158.GE17723@mournblade.imrryr.org> <20140623173434.GK17723@mournblade.imrryr.org> <201406242052.s5OKqdeo003390@new.toad.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/lsCVTt-UwBDvkRXV0PAJ64z5M2E Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2014 15:21:10 -0000 On Thu, Jun 26, 2014 at 07:22:54AM +0100, Paul Hoffman wrote: > Having read the author's message to the mailing list that he > intends this draft to update RFC 6698 to apply to unnamed protocols, > not just TLS, I rescind my support for the draft. I still fully > support updating 6698 to cover "keying material" instead of > "certificates" in the manner discussed in the -00 draft. I would > also support a different draft that says "the TLSA record can be > used in the following protocols in the following fashions". Well, this is not last call, rather a call for adoption. Perhaps we can come to rough consensus on this issue after the draft is adopted? I can, for example, see using TLSA RRDATA (with a different lookup key than _port._proto) for cross-realm kerberos without prior manual keying. Nico may publish a draft for that at some point... Now to Paul's point, there will of course need to be a draft specifying any such use-case. However, there is perhaps little harm in allowing the TLSA RRDATA definition in 6698 to not explicitly exclude other protocols. To me the part that binds TLSA RRs to transport security is _port._proto. The queryname for TLSA RRset is a transport end-point, hence we're doing transport security. If instead the DNS lookup were something like: _pkcross.athena.mit.edu IN TLSA ? then we're not doing transport security. To Paul's point however, it is a bit less obvious that the various per-protocol specs will always keep out of each other's way and avoid lookup key collisions for unrelated services if the RRtype TLSA is SHARED, and only the various _mumble prefixes differentiate distinct use-cases. On balance I think it is reasonable to use TLSA RRDATA in more situations, and support adoption of the draft, which will presumably evolve to match rough consensus. -- Viktor. From nobody Thu Jun 26 09:28:27 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940C71B28CD for ; Thu, 26 Jun 2014 09:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j205hfKAgiVk for ; Thu, 26 Jun 2014 09:28:21 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD9C1B295C for ; Thu, 26 Jun 2014 08:49:53 -0700 (PDT) Received: from [10.143.195.93] ([31.55.12.2]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s5QFnn46040968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 26 Jun 2014 08:49:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host [31.55.12.2] claimed to be [10.143.195.93] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Paul Hoffman In-Reply-To: <20140626142647.GZ16666@mournblade.imrryr.org> Date: Thu, 26 Jun 2014 16:49:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <80011946-F0BD-4E6F-9D23-F374EB737981@vpnc.org> References: <20140623150158.GE17723@mournblade.imrryr.org> <20140623173434.GK17723@mournblade.imrryr.org> <201406242052.s5OKqdeo003390@new.toad.com> <20140626142647.GZ16666@mournblade.imrryr.org> To: dane@ietf.org X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/FVHYW-YOsdLjQljygBxAMuuwImI Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 26 Jun 2014 16:28:22 -0000 On Jun 26, 2014, at 3:26 PM, Viktor Dukhovni = wrote: > On Thu, Jun 26, 2014 at 07:22:54AM +0100, Paul Hoffman wrote: >=20 >> Having read the author's message to the mailing list that he >> intends this draft to update RFC 6698 to apply to unnamed protocols, >> not just TLS, I rescind my support for the draft. I still fully >> support updating 6698 to cover "keying material" instead of >> "certificates" in the manner discussed in the -00 draft. I would >> also support a different draft that says "the TLSA record can be >> used in the following protocols in the following fashions". >=20 > Well, this is not last call, rather a call for adoption. Perhaps > we can come to rough consensus on this issue after the draft is > adopted? Sure. However, when someone publishes a -00, and during the call for = adoption says "and I intend to add a major change that wasn't even = hinted at in the -00", I think it is worth the WG to pause a bit. > I can, for example, see using TLSA RRDATA (with a different lookup > key than _port._proto) for cross-realm kerberos without prior manual > keying. Nico may publish a draft for that at some point... Absolutely. However, if you're talking about changing the lookup = mechanism, then it is no longer a simple change to the the base spec. = Thus, my proposal to collect all non-TLS use of TLSA record in a = different document. > Now to Paul's point, there will of course need to be a draft > specifying any such use-case. However, there is perhaps little > harm in allowing the TLSA RRDATA definition in 6698 to not explicitly > exclude other protocols. RFC 6698 already excludes non-TLS use throughout the document by talking = about TLS as the only applicable protocol. > To me the part that binds TLSA RRs to transport security is > _port._proto. The queryname for TLSA RRset is a transport > end-point, hence we're doing transport security. >=20 > If instead the DNS lookup were something like: >=20 > _pkcross.athena.mit.edu IN TLSA ? >=20 > then we're not doing transport security. To Paul's point however, > it is a bit less obvious that the various per-protocol specs will > always keep out of each other's way and avoid lookup key collisions > for unrelated services if the RRtype TLSA is SHARED, and only the > various _mumble prefixes differentiate distinct use-cases. >=20 > On balance I think it is reasonable to use TLSA RRDATA in more > situations, and support adoption of the draft, which will presumably > evolve to match rough consensus. I'm with you there up to the last bit. It will take much longer to come = to consensus on a catch-all document than it will one that, like = draft-gilmore-dane-rawkeys-00, is just about allowing raw keys for TLSA = for TLS. --Paul Hoffman= From nobody Fri Jun 27 10:56:58 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35F91A04C2 for ; Fri, 27 Jun 2014 10:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2J9svXRxuIPj for ; Fri, 27 Jun 2014 10:56:55 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F24B61A0515 for ; Fri, 27 Jun 2014 10:56:41 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4060AE00E; Fri, 27 Jun 2014 13:56:52 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 34DE863B81; Wed, 25 Jun 2014 08:50:20 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1DAF063AED; Wed, 25 Jun 2014 08:50:20 -0400 (EDT) From: Michael Richardson To: Paul Wouters In-Reply-To: References: <20140623150158.GE17723@mournblade.imrryr.org> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/dane/qBPvGcEHaFWb6TvBYnyutnFthZc Cc: dane@ietf.org Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 17:56:56 -0000 Paul Wouters wrote: >> beyond even raw public keys). My best guess is that were some >> other kind of "key material" to be used with TLS, that is not in >> SPKI format, > Please note that this is to support non-TLS scenarios where the public > key might not be transfered in-band like in the TLS case. That is, > the draft extends 6698 to support publishing any kind of public key > in SPKI format for verification. It does not suggest non-SPKI formats. When you write SPKI, do you mean rfc2692/93? Or something else? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Fri Jun 27 11:02:45 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65821A03B4 for ; Fri, 27 Jun 2014 11:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBfHktL64zdD for ; Fri, 27 Jun 2014 11:02:41 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B87171ACD01 for ; Fri, 27 Jun 2014 11:02:39 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3FDE8E00C for ; Fri, 27 Jun 2014 13:56:52 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3853163B7F; Wed, 25 Jun 2014 08:47:48 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2467F63AED for ; Wed, 25 Jun 2014 08:47:48 -0400 (EDT) From: Michael Richardson To: dane@ietf.org In-Reply-To: <20140623150158.GE17723@mournblade.imrryr.org> References: <20140623150158.GE17723@mournblade.imrryr.org> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Xn84IIQfiVXU0G5W9P2rJCWyhNI Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 18:02:42 -0000 --=-=-= I have read draft-gilmore-dane-rawkeys. I think that some of the goal text in section 4, that explains that this mechanism can be used for both certificate and raw key based TLS, should move much earlier in the document. My impression is that this document does not require any new assigned numbers or protocol values, but rather simply explains how a raw key can be contained in a minimal DER encoded format such that it can be contained in the TLSA record. I found reading the document difficult as it contained too many "extende" statements; likely this is because I have not done a TLSA implementation so I am not sufficiently familiar with the underlying data structures. Mention of a way to validate a key by hash is mentioned, but I'm unclear how that works from my first reading. I support adoption of this document; it needs a co-author. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU6rE84CLcPvd0N1lAQKZEgf9GoeH7z391GY0KU4sUURXIPHdPUJHlZFk KNGFNszE83xGAFJPq+DBUswnPPY73////MkfJlFAFZjpv6VyVgr1dTlxQradomhZ egF/P+hMWrpfGStjHGOcPPn7Hfiwlt9jsBlaijcD8CKiQy2+80k8QITHL0kghRph eyP0LqNIu4TywRlH7nELKLMbxMA6d1/blJHM4fU3jIgPDrYvVflhnqLiNokFCz79 DyT0ksawowZAIC6jI5AxWj9gmqyzFa0IevR88xLyTGy3joCNa7ln8IUPGggOI1jy wIivXfBvutGIRZwC9pVgV1TkdOyYU2H9aO6MWbC4HLIBf8EWU6vscA== =igR7 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 27 11:21:32 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB431B28CE for ; Fri, 27 Jun 2014 11:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eAM3zC2m3hy for ; Fri, 27 Jun 2014 11:21:26 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74F841B28AC for ; Fri, 27 Jun 2014 11:21:26 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D86202AB299; Fri, 27 Jun 2014 18:21:23 +0000 (UTC) Date: Fri, 27 Jun 2014 18:21:23 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20140627182123.GU16666@mournblade.imrryr.org> References: <20140623150158.GE17723@mournblade.imrryr.org> <14997.1403700468@sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14997.1403700468@sandelman.ca> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dane/9Ffxny7eqkNZCaR1IxKG6jVOMws Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jun 2014 18:21:29 -0000 On Wed, Jun 25, 2014 at 08:47:48AM -0400, Michael Richardson wrote: > My impression is that this document does not require any new assigned > numbers or protocol values, but rather simply explains how a raw key can be > contained in a minimal DER encoded format such that it can be contained in > the TLSA record. More typically, the record will hold a digest, not the full key. Matching type Full(0) is not recommended, at least for RSA keys, which are quite large. > Mention of a way to validate a key by hash is mentioned, but I'm unclear how > that works from my first reading. The peer presents the key in-band (TLS handshake, for example). The client checks that the key matches the hash in the TLSA record. The TLSA record is a binding between a DNS name and a public key, so a binding to a key digest (given a strong digest) is just as good. -- Viktor. From nobody Fri Jun 27 12:05:17 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922701B2A00 for ; Fri, 27 Jun 2014 12:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPC0zXxftuvf for ; Fri, 27 Jun 2014 12:05:13 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.23.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 421B01B29FC for ; Fri, 27 Jun 2014 12:05:13 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 20F271DD90; Fri, 27 Jun 2014 19:05:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1403895911; bh=u/qaW8VUBKjsYKuwD7ZwUTdfGyBD3IixQRMcetMy5KE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=AMupyMOFjYT2140ICwtdBsGY8A39VmPVxcuKsfzUkknSeK+ENQhUjSU9462wGm8WF y56QIytEmmtUHNIm4hBiA//9oOaI65KGZSasyefRjQGt5OXL5d9cDODNmMYbeJarJo /FiC36IslKvZ2cKiOsGZl1xEWrvIqIdVWyf0mMw0= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 527246001E; Fri, 27 Jun 2014 18:29:52 +0000 (UTC) From: James Cloos To: Michael Richardson In-Reply-To: <15557.1403700620@sandelman.ca> (Michael Richardson's message of "Wed, 25 Jun 2014 08:50:20 -0400") References: <20140623150158.GE17723@mournblade.imrryr.org> <15557.1403700620@sandelman.ca> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2014 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Fri, 27 Jun 2014 14:29:27 -0400 Message-ID: Lines: 11 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:30:140627:mcr@sandelman.ca::3tPfhZ7SS+QllN9Z:Snxi4 X-Hashcash: 1:30:140627:paul@nohats.ca::GExZeUGKFxMsNrlz:00u6/k0 X-Hashcash: 1:30:140627:dane@ietf.org::tbgesS5/Ux4A14P9:000Ob/Nf Archived-At: http://mailarchive.ietf.org/arch/msg/dane/F7q8bQB-RToBHyvGAaTU8u0_v0A Cc: Paul Wouters , dane@ietf.org Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 19:05:15 -0000 >>>>> "MR" == Michael Richardson writes: MR> When you write SPKI, do you mean rfc2692/93? Or something else? See section 3 of rfc 7250, now that it is released. http://tools.ietf.org/html/rfc7250 -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Fri Jun 27 18:55:20 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9E81A0263 for ; Fri, 27 Jun 2014 18:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1dr0G73Zx6g for ; Fri, 27 Jun 2014 18:55:18 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 436B01A0261 for ; Fri, 27 Jun 2014 18:55:18 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 898B88008E for ; Fri, 27 Jun 2014 21:55:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1403920516; bh=J8qhgsfWU6Iplv6ZgjYIY9UpvJGZINIi43wca3bTXYY=; h=Date:From:To:Subject:In-Reply-To:References; b=g2HJ+oFJAK0MUH1xIBG2xzB2cGf5JMCDbK0YGtV6y6BHOPkVAswgjK0lnQGuklo+m BLroJCIL8QTWZmgtJoDErepiMRIMxp41Bsajbsar3/tWiOw7FpqShBL6/3YhAC5t5z t3BYtsxqYaV11CZ0p7vD0jyF0i8CAu/iDRkBKGOg= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s5S1tFQB014043 for ; Fri, 27 Jun 2014 21:55:16 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 27 Jun 2014 21:55:15 -0400 (EDT) From: Paul Wouters To: dane@ietf.org In-Reply-To: <20140627182123.GU16666@mournblade.imrryr.org> Message-ID: References: <20140623150158.GE17723@mournblade.imrryr.org> <14997.1403700468@sandelman.ca> <20140627182123.GU16666@mournblade.imrryr.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ly_cZM_CuDmET-DnVO9OrLeWS2M Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 01:55:19 -0000 On Fri, 27 Jun 2014, Viktor Dukhovni wrote: > On Wed, Jun 25, 2014 at 08:47:48AM -0400, Michael Richardson wrote: > >> My impression is that this document does not require any new assigned >> numbers or protocol values, but rather simply explains how a raw key can be >> contained in a minimal DER encoded format such that it can be contained in >> the TLSA record. > > More typically, the record will hold a digest, not the full key. That's one use - not the exclusive use. A TLSA record can also be sed to securely publish public keys. > Matching type Full(0) is not recommended, at least for RSA keys, > which are quite large. Perhaps for use with TLS yes, because the public key is transfered within TLS already. That might not be true of other protocols that would like to lookup a public key structure with DANE/DNSSEC. >> Mention of a way to validate a key by hash is mentioned, but I'm unclear how >> that works from my first reading. > > The peer presents the key in-band (TLS handshake, for example). > The client checks that the key matches the hash in the TLSA record. > The TLSA record is a binding between a DNS name and a public key, > so a binding to a key digest (given a strong digest) is just as > good. That's right. Paul From nobody Fri Jun 27 18:57:25 2014 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920601A0264 for ; Fri, 27 Jun 2014 18:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSvHZCDH5cra for ; Fri, 27 Jun 2014 18:57:22 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A9541A0266 for ; Fri, 27 Jun 2014 18:57:22 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C087F8008E; Fri, 27 Jun 2014 21:57:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1403920641; bh=Cj5h7Jy/pTplKTrskPjQTR8UNTLWSgH1I8p1fYbsVWg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=P40+oqLFZ8TM+zzIwUuHXoF8LZLI4G8VMQY2ttvTFLcx/tCNC3hhoe5XHAeRYRvdo c9CbLV5Tj7B7ZjH1sUOTavF2qEl6hZDv1qw0ODGQyI2CABnDXd/WC8vJBDiuJTNVWu QZ+LIKdzE2iPd3uRD9zBZB+KR/f88PUjrWiln57Y= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s5S1vLbI014537; Fri, 27 Jun 2014 21:57:21 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 27 Jun 2014 21:57:21 -0400 (EDT) From: Paul Wouters To: Michael Richardson In-Reply-To: <14997.1403700468@sandelman.ca> Message-ID: References: <20140623150158.GE17723@mournblade.imrryr.org> <14997.1403700468@sandelman.ca> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dane/uBDWyJ0mxUEkHDiidCW5t5POAx0 Cc: dane@ietf.org Subject: Re: [dane] Compressed Call for Adoption: draft-gilmore-dane-rawkeys-00 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 01:57:23 -0000 On Wed, 25 Jun 2014, Michael Richardson wrote: > I found reading the document difficult as it contained too > many "extende" statements; likely this is because I have not done a TLSA > implementation so I am not sufficiently familiar with the underlying data > structures. I agree. I had proposed some alternative text for John. I'll see if we can figure out a way to make it more readable without the document being a checklist of corrections for another document. Paul